第 13 部
IP 層におけるセキュリティ技術343

第 1章WHIPSWHIPS(WIDE Happy IP Security) 分科会の目的は、「 IPsec 準拠の IP security 機構の実装と検証」である。WHIPS は、1996 年秋の合宿から 1 年間の予定で活動を開始した。発足
当時は、まず 1997 年の春合宿までに IPsec の基本仕様である AH(Authentication Header:
認証ヘッダ ) と ESP(Encapsulating Security Payload:暗号ペイロード ) を実装して相互接続性を検証し 、残りの半年で鍵交換プロトコルの開発に取り組むという計画を立てた。1997
年の春合宿において、計画通り (株) 東芝、ヤマハ (株) 、および 、横河電機 (株) それぞれ独自の AH と EPS の実装に関して相互接続性をテストした。しかしながら、AH と EPSの仕様が変更されたことや相互接続性に若干問題があったことから、残りの半年でも AH
や EPS の相互接続性を検証していく必要がある。
この章では、まず最新の AH と EPS を含めた IPsec の概要を解説し 、次に分科会の成果である 3 つの実装と相互接続性テストの結果について述べる。
1.1

AH と ESP

IPsec はもともと IPv6 用のセキュリティ機構として標準化が始まったが、RFC 1825 〜
1829 として発行されるまでには IPv4 でも利用できる拡張ヘッダ形式に落ち着いた。IPsec
で AH(RFC1826) と ESP(RFC1827) を分割した本質的な理由は、暗号の利用を制限している国でも認証機構だけは利用できるようにという配慮からである。ESP では適切な変換を施せば認証や完全性保護の機能も利用できる。しかしながら、RFC 1829 で定められているように必須の標準の変換 (ESP DES{CBC 変換) には認証や完全性保護の機能は無く、ESP は AH と組み合わせて使うように設計されていた。
その後 IPsec のメーリングリストで、ESP DES{CBC 変換などに暗号の性質に起因した弱点が報告された。たとえば 、ESP DES{CBC 変換を用いて TCP をセッションを保護する場合を考える。このとき、DES{CBC の性質からセッション中の任意の文字列を他の文字列に置き換えることなどが可能である。そこで、暗号の機能を利用する場合は、同時に完全性を保護する必要があること分かった。

ESP で常に完全性を保護するためには、AH と組み合わせて利用するよりも完全性を保護する機能をもった変換を定めた方がよい。そこで、現在では AH は IP ヘッダを認証や
345

346

1996 年度 WIDE 報告書

AH ESP

完全性保護を実現するためのみに用いることになった。さらに、やともにリプレ
イ攻撃から保護するために、通し番号を付加する必要があること分かった。
このような背景のもとに、現在新しいと、そしてそれぞれの変換がインター
ネット・ドラフトとなり議論されている。以下最新のとの書式について説明する。

AH

1.1.1

図

ESP
AH ESP

AH

1.1に最新の AH の書式を示す。各フィールド の意味は以下の通りである。
1

次ヘッダ 引き続くヘッダの種類を示す。 バイト。必須。

AH

4

ペイロード 長の長さを バイト単位で表す。長さには固定長である最初のは含まない。 バイト。必須。

1
SPI Security Parameter Index。4 バイト。必須。

8 バイト

通し番号 対リプレイ攻撃用の通し番号。セキュリティ・アソシエーションが確立された際に に初期化される。数値を使い切った場合は、セキュリティ・アソシエーションを再び確立する。 バイト。選択 必須になる可能性が高い 。

1

4

(

)

4

認証データ 変換で生成される認証データ。 バイトを単位とした可変長。

0

8
次ヘッダ

16
ペイロード長

24

32

予約
SPI

通し番号
認証データ

図

1.1.2

図

1.1: AH の書式

ESP

1.2に最新の ESP の書式を示す。各フィールド の意味は以下の通りである。

SPI Security Parameter Index。4 バイト。必須。

第 13 部

347

IP 層におけるセキュリティ技術

通し番号 対リプレイ攻撃用の通し番号。セキュリティ・アソシエーションが確立された際に に初期化される。数値を使い切った場合は、セキュリティ・アソシエーションを再び確立する。 バイト。選択 必須になる可能性が高い 。

1

4

(

)

1

初期ベクト ル 暗号アルゴリズムなどによって必要とされるデータ領域。 バイトを単位とした可変長。選択。

1

ペイロード 変換を施したペイロード。次ヘッダによって内容が指定される。 バイトを単位とした可変長。必須。
パディング 暗号化する場合は暗号アルゴリズムによって要求されるブロック長に合わせる
ためのデータ領域。暗号化しない場合は、 バイト境界に合わせる。 〜
バイト。
選択。

4

0 255

1

パディング長 パディングの長さ。 バイト。必須。

1

次ヘッダ ペイロード の内容。 バイト。必須。

1

認証データ 変換で生成される認証データ。 バイトを単位とした可変長。選択。

0

8

16

24

32

SPI
通し番号
初期ベクトル
完全性／認証
ペイロード
機密性
パディング
パディング長

次ヘッダ

認証データ

図

1.2

1.2: ESP の書式(株) 東芝の実装

mobile IP

IPsec

東芝では、
と
の協調動作を目指している。このため、容易に修正や変更、拡張が行なえることが望ましかった。また、他のなどへの移植が容易にできるこ

OS

348

1996 年度 WIDE 報告書

1

とも要望の つであった。そこで、機能のほとんどをユーザー空間で動作するアプリケー
ションとして実装した。

1.2.1

東芝の実装の概要

IPv4

東芝では、
を対象としたルは次の通りである。

IPsec を BSD/OS 2.1 上で実装した。対応したプロトコ

AH | Keyed-MD5(RFC1828)、Keyed{SHA1(RFC1852)
ESP | DES-CBC(RFC1829) 、3DES{CBC(RFC1851)
鍵管理プロト コル| SKIP(draft-ietf-ipsec-skip-07.txt)

MD5 は基本的に RFC1321 のコードを使用している。それ以外の暗号／認証関連のアルゴ リズム、すなわち SHA1 、DES および 3DES 、Die-Hellman はオリジナルの実装を使用している。

1.2.2

東芝の実装の制限

現在の実装での制限を以下に示す。

|

モード
トランスポート・モードは実装されていない。したがって、通信当事間の通信
でも新しいヘッダが付加される。
のみを使用するときは、
の次ヘッダ
は
となる。

IPv4

IPv4

AH

AH

keying | 現在の実装では、セキュリティ・アソシエーションをホスト単位 (host-keying)
でしか選択できない。したがって、ユーザごとに (user-keying) 、あるいはセッション
ごとに (session-keying) 鍵を登録／変更できない。また、セキュリティ・アソシエー
ションの登録／削除／変更について、他プロセスとのインターフェイスは用意されていない。
経路

MTU 探索 | 経路 MTU 探索には対応していない。したがって、DF(Don't Fragment)
ビットが立っている IP パケットを転送する際に IPsec でカプセル化する場合には、カプセル化されたパケットが分割されて転送される。本実装をセキュリティ・ゲート
ウェイとして使用したときには、通信当事間のホストが経路探索を実装していたとしても、セキュリティ・ゲートウェイ間では分割が発生する。

MTU

第 13 部
1.2.3

349

IP 層におけるセキュリティ技術

東芝の実装方式

SKIP AH

ESP

鍵管理プロトコル、
およびのカプセル化／カプセル開放はすべてユーザ空間で動作するアプリケーション・プログラムとして実装した。また、カーネルからこの主モジュールへパケットを渡すために、というデバイスを実装した。
ユーザ空間で動く主モジュールは、プロトコル処理部、セキュリティ・アソシエーショ
ン・マネージャ、ポリシー・マネージャの つの部分に分かれる 図。

PCD(Packet Capture Device)3( 1.3)SA
SA

Generator

Policy Manager

SA
Encap

Encap

Encap

Encapsulator

SKIP

AH

ESP

IP

Unknown

Decap

Decap

Decap

Decapsulator

Decap

SA
SA

SA Entry

Protocol Switcher
SA selector

outputSecurity Association Manager
Raw IP図

Packet Captuire Device

1.3: 東芝の実装の概念図

プロトコル処理部は各プロトコルを理解し処理する。この中は大きく受信時に使用されるカプセル開放器と、送信時にパケットを作るために使用されるカプセル格納器に分けれらる。
セキュリティ・アソシエーション・マネージャは、セキュリティ・アソシエーションの登録、削除、選択などを受け持つ。現在の実装では、セキュリティ・アソシエーションには、双方のための鍵、アルゴ リズム等の情報が含まれている。
とを同時に使用するときには同じセキュリティ・アソシエーションを使うようになっている 本来は異なるべきである 。ただし 、のためのを指定して、 同じセキュリティ・アソシエー
ションを使っているが／で異なるを使用できる。
ポリシー・マネージャは送信の際にどのセキュリティ・アソシエーションを使用するかを決定する機構である。ただし 、現在の実装ではしかできないので、のAH ESP)ESP)AH ESP

SPI
SPI

(

host-keying

AH ESP
(

IPsec

350

1996 年度 WIDE 報告書処理を施すパケットに対して、どのゲートウェイのセキュリティ・アソシエーションを使用すればよいかしか判断していない。

IP

IP

パケットが入力されると、それはまずプロトコル処理部に渡される。 プロトコル
処理部は、入力されたパケットがパケットを転送すべきか、 カプセル化するべきか、カプセルを開放すべきかを判断する。

(1)

(3)

(2)

カプセル化する場合は、パケットは発生器に渡される。発生器は、ポリシー・マネージャ
からそのパケットに適切なセキュリティ・アソシエーションを受け取る。次に発生器は、セキュリティ・アソシエーションの内容に従い、パケットをカプセル格納器に渡していく。最後に、カプセル格納器はのカプセル化を行なう。

IPsec

カプセル開放の際は、パケットに付けられているヘッダの順に各プロトコル処理部のカプセル開放器に渡される。 、ではそのカプセル開放器の中でセキュリティ・アソシ
エーション・マネージャから入力されたパケットに合うセキュリティ・アソシエーションを受け取って、その内容に従ってカプセルを開放する。

AH ESP

PCD (図 1.4) は、カーネルが出力するパケットをアプリケーションへ渡すためのデバイスであり、基本的にはトンネル・デバイスを拡張したものである。PCD では BPF(Berkeley
Packet Filter) のようにパケットのコピーを渡すのではなく、パケットを \横取り" でき、ア
プリケーションが取ったパケットは出力されない。

4.4BSD の実装において、IP パケットの出力関数であるip_output() は IP パケットを実際に送信するためにインターフェイスの出力関数を呼ぶ。実際には ifnet{}構造体中のif_output[] に出力関数へのポインタが保存されており、ip_output() はこのif_output[]を参照する。

PCD は、自分がopen() されると、すべてのifnet{}構造体を走査し 、if_output[] の値を PCD 内の配列if_output[] へ保存し 、同時に if_output[] を PCD の出力関数へと変更する。この操作によってインターフェイスに出力されるすべてのパケットは PCD に渡されることになる。

PCD は簡単なパケット・フィルタを持っており、PCD を使うアプリケーションは自分がどのようなパケットを必要としているかをこのフィルタに設定しておく。現在の実装では、始点と終点のアドレスを条件に指定できる。上位層が必要としていないパケットはそのまま、本来出力されるはずであったインターフェイスの出力関数へと渡される。そうでなければ 、内のパケット・キューに入れられる。ユーザ・プロセスがキャラクタ・デ
バイスとしてのから read() すると、このキューからパケットが上位層に渡される。
また、キャラクタデバイスとしてのに write() すると、これは ip_output() を通して出力される。ただし 、に write() されたパケットがもう 度上位層に渡ることがないようになっている。

PCD

PCD

PCD

PCD

1

第 13 部

351

IP 層におけるセキュリティ技術

ifnet
if_output

if_output

if_output

read_function()
output_function()
write_function()
packet filter
Link Interface Driver
if_output[]

output_fuction()

packetqueue

output_fuction()

output_fuction()

Packet Capture Device(Link Interface Driver)
ip_output()

図

1.2.4

1.4: Packet Capture Device

東芝の性能

2

本実装の性能を測定するために、 台のホスト間での1定にはを使用した。テストに使用したホストはである。結果を表に示す。

TCP の転送速度を測定した。測2 台とも BSD/OS 2.1、Pentium

Netperf
1.1
100MHz(1) は、IPsec モジュールを全く使用しない場合の速度である。(2) から (6) は鍵管理プロ
トコル SKIP を使用しない場合、(7) から (11) は SKIP を使用した場合の速度である。(1)と (2) の速度差はかなり大きい。MD5 の計算量はそれほど大きくないことを考えると、速度低下の大部分はおそらくカーネル空間とユーザ空間とのデータ交換のオーバヘッドであろうと考えられる。 〜と〜をそれぞれを比較すると、それほど速度差がない
ことがわかる。
では鍵情報をヘッダ内に埋め込み、これを暗号化2する。そのため、各送受信パケットそれぞれについてを使用することによるオーバヘッドが発生する
が、この結果をみるとこのオーバヘッドはそれほど問題にならないといえる。 〜〜
をみると、暗号化の処理は非常に重く、最終的にこれが転送速度を決定している。

(2) (6) (7) (11)
SKIP
SKIP

(11)

1 URL: http://www.cup.hp.com/netperf/NetperfPage.html
2 本実験では暗号化に Triple-DES を使用した。

(3) (6), (9)3521996 年度 WIDE 報告書

Mbit/sec(1) IP (no IPsec)
8.32(2)
AH(MD5)
3.89(3)
ESP(DES) 2.43
(4)
AH(MD5)+ ESP(DES) 2.24
(5)
ESP(TDES) 1.43
(6)
AH(MD5)+ ESP(TDES) 1.35
(7) SKIP+ AH(MD5)
3.77(8) SKIP+
ESP(DES) 2.42
(9) SKIP+ AH(MD5)+ ESP(DES) 2.25
(10) SKIP+
ESP(TDES) 1.43
(11) SKIP+ AH(MD5)+ ESP(TDES) 1.37
表 1.1: 性能測定の結果
プロトコル

1.2.5

東芝の実装の課題

現在の実装の制限を順次解決していきたい。特に、現在はホスト単位でしかセキュリティ・
アソシエーションを定められないが、セッション／ユーザ単位でのセキュリティ・アソシ
エーションの選択を可能にすべきである。現在提案されているに類似した機構を実装したいと考えている。このため、現在はをサポートするほとんどすべてのモジュールおよびデータがユーザ空間にあるが、この内のいくつかはカーネルに移動しなければならなくなると考えている。また現在我々は、独自にのプロトコルスタックを実装しており、これにもを組み込む予定である。
ではは拡張ヘッダとして定義されているので、アプリケーションとしての実装が難しい。我々には高い移植性という要求があるため、ユーザ／カーネル空間の切り分けについて考えていきたい。

IPsec

IPsec

1.3

Simple IPsec API

IPv6

IPv6

IPsec

ヤマハ (株) の実装

( )

ESP

ISDN
IPv4
IPsec
DES{CBC

MD5

PGP

RT100i RT102i RT200i (RT
AH
Keyed MD5
3DES{CBC 2

ヤマハ 株 では 、
リモート・ルータ／／
以降、と呼ぶ を基にして、用のを試験的に実装した。
の変換には
の
種類、
の変換には
および
の 種類を実装した。また、鍵管理プロトコルは未実装で、鍵の管理は手動である。

1

)

2.1.2

DES は LSI ジャ

なお、
は
バージョン
に付属するフリーのコードを、
パンの森公一郎氏が作成したフリーのコードを改造して利用している。

第 13 部
1.3.1

IP 層におけるセキュリティ技術

353

ヤマハの実装の詳細

RT 上で動いているファームウェアは BSD などの UNIX ベースではなく、まったく独自である。そのため、実装の詳細については図を用いて説明を進めていくこととする。
図はでのパケット処理の概念図である。入力インタフェースから入って来た
パケットはまず入力フィルタを通り、そこで落すべきパケットを落す。
次にルーティング・エンジンを通してパケットの送り先を決定する。この送り先には自らの上位層も含まれている。送り先が外部への出力となった場合、出力フィルタで選別をかけられ、通過したパケットだけが出力インタフェースから出力される。

1.5 RTIP

IP

ルータの上位層

IPルーティング
エンジン
入力フィルタ

出力フィルタ入力
インタフェース

出力
インタフェース

図1.5: RT における IP パケット処理

IPsec

1.6

IP

この構造に
を組み込んだのが図である。 経路制御エンジンの入口にカプセ
ル格納器が、自らの上位層にはカプセル開放器が付加される。カプセル開放器で処理されたパケットはまた、 パケット処理の入口に戻される。

IP

IPSEC
デコード

IPSEC
エンコード

ルータの上位層

IPルーティング
エンジン

入力フィルタ

出力フィルタ入力
インタフェース

出力
インタフェース

図1.6: IPsec モジュールを入れたパケット処理

カプセル格納器は、どのパケットをカプセル化すべきかをフィルタと同じルールにより

354

1996 年度 WIDE 報告書

TCP UDP選別する。これにより、パケットの始点／終点アドレスはもとより、／などのプロトコルやポート番号など 、カプセル化すべきパケットを細かく指定できる。

IPsec

カプセル開放器は、パケットとして妥当なものであればすべてカプセル開放を試みる。ここではどこからパケットが送られてきたかなどは一切考慮しない。必要があれば 、これらを入力フィルタで処理する。

IP

カプセル開放器からのパケットがパケット処理の入口に差し戻されることからも分
かるとおり、の実装ではヘッダごとカプセル化するトンネル・モードが必須となっている。いわゆる
トンネルは実装されていないため、トンネルを用いる必要がある。理由はをルータとしてトンネルを構築することを主眼に実装を進めたためであり、ルータ自らの上位層がを用いて通信することはあまり考えられていないか
らである。

RT

RT

1.3.2

IP

AH

ESP

IPsec
IPsec

ヤマハの実装における AH と ESP の独立性

ESP トンネルが必須となっているため、コードとしても AH は ESP から切り離しては使えないようになっている。これは単に最終的な機能の実現のために余計な部分を削ったためであり、技術的にはのコードをから切り離すことは問題ない。将来
ト
ンネルもサポートするようになれば切り離すべきであろう。ヤマハでは今のところ
以外の実装へは考えていないため、上位層でを使いやすくするように改造する予定は
ない。

AH

ESP

AH
RT

IPsec

1.3.3

ヤマハの実装の特徴

AH

ESP

ヤマハの実装の特徴は単独では使えず、常にを必要とすることである。これは、の用途をトンネルを張ることに限定したためであり、ルータ自身の上位層がの端点となって動作することをほとんど考慮していない。 しかしながら、相互接続テストのために必要となるため、実際にはなどが上で実行できる。

IPsec
IPsec

IPsec

ping

IPsec

(

IPsec
ESP

)

また、フィルタと同様なパケット選択方式を取っているため、を利用するパケットを細かく指定できるのも特徴である。これにより、たとえばメールはで暗号化したいが、は暗号化せず転送速度を低下させないなどの細かい設定が可能である。

WWW

欠点としては、鍵管理プロトコルを実装していないにも関わらず、暗号アルゴ リズムとしてなどの鍵長の短いものしか用意していない点があげられる。鍵長の短いア
ルゴ リズムは暗号化／復号化にかかる時間が短くてすみ、をあまり増加させないことが利点ではあるが、その分解読されやすい。暗号としての強度をあげるためには定期的に鍵を変更する必要があるが、手動での設定は適切ではない。よって、実用化のためには鍵管理プロトコルの実装が必須であると考えられる。

DES{CBC

RTT(Round Trip Time)

第 13 部

1.4

355

IP 層におけるセキュリティ技術

横河電機 (株) の実装

YIPS(Yokogawa IP Security)
YIPS IPsec

IPsec

横河電機の
は、組織間の安全な通信を保証するためのの実装である。
は、
アーキテクチャを採用し 、アドレスとマスク、
ポート番号を元にしたセキュリティ・アソシエーションを作成する。また、プロキシ・アドレ
スを組み合わせることにより、セキュリティ・ゲートウェイとしての動作も可能である。セキュリティ・アソシエーションを構成するセキュリティ・プロトコルとして、変換はを採用3している。さらに、送受信に関するポリシーをシステ
ムに対して設定可能にすることにより、様々なポリシーに対応できる。
は、以上で動作する。
は 、セキュリ
ティ・アソシエーションを管理する部分とセキュリティ・プロトコルを処理する部分に分類できる。

(RFC1825)

ESP(RFC1827)

DES-CBC(RFC1829)

YIPS

1.4.1

BSD/OS 2.1 patch-level 27 libdes 3.2

YIPS

YIPS の制限

YIPS の制限を以下に示す。
IPv4 上での実装である。IPv6 に関しては今後対応するかもしれない。
 ESP トランスポート・モードはサポートしない。セキュリティ・ゲートウェイは、IP

ヘッダさえも機密性を保たなければならない場合がある。トランスポート・モードを実装する手間と、これを採用したときのセキュリティ・ゲートウェイにおける利点を比べて実装しないことにする。ただし 、今後帯域の問題に直面した場合に考慮するかもしれない。

AH はセキュリティ・アソシエーション管理において指定はできるが、カーネルには実装していない。これは実装している途中で、認証が必要な場合は ESP の適切な変換を使用すればよいと判断したためである。ただし 、今後中継認証などの認証のみを必要とする問題に直面した場合に考慮するかもしれない。

 セキュリティ・アソシエーション管理をする方法については手動方式のみをサポートする。その他のセキュリティ・アソシエーション管理の方法については今後考慮しなければならない。
 本実装でのマスクは、連続しているもののみ使用可能とする。

IPSO、QoS については、考慮して マルチキャスト、マルチレベル・セキュリティ、いない。

3 3DES-CBC(RFC1851) も実装したが、アルゴ リズムを正確に理解していなかったため WIDE における相互接続テストに失敗した。今後見直す予定。

356

1996 年度 WIDE 報告書

1.4.2

YIPS のセキュリティ・アソシエーション管理機構

YIPS では、ユーザ空間からセキュリティ・アソシエーションを管理するために、PF KEY4と呼ばれるインターフェイスを採用した。これは、route(4) と同様に RAW ソケットを介してカーネルと通信する機構である。以下に使用可能なメッセージについて説明する。
では以下の様なメッセージが使用できる。

YIPS

SA ADD | カーネルに対し 、新規セキュリティ・アソシエーションの登録を要求する。
SA DELETE | カーネルに対し 、指定したセキュリティ・アソシエーションの削除を要求する。カーネルは対応するセキュリティ・アソシエーションの状態を SA DEAD とするだけである。

SA GET | カーネルに対し 、指定したセキュリティ・アソシエーション情報の返答を要求する。カーネルは、対応するセキュリティ・アソシエーションの情報をユーザへ返す。

SA DUMP | カーネルは、全てのセキュリティ・アソシエーションの情能をユーザへ返す。
SA FLUSH | カーネルは、全てのセキュリティ・アソシエーションを削除する。

PF_KEY socketinterface

Manual Key
Management Application
SA_ADD
SA_DELETE
SA_GET
SA_DUMP
SA_FLUSH

図1.7: 手動のセキュリティ・アソシエーション管理で使用可能なメッセージ(

これらは全て手動のセキュリティ・アソシエーション管理に必要なメッセージである 図。今後動的なセキュリティ・アソシエーション管理 図が必須となるので、以下の様なメッセージも考慮し実装していかなければならない。

1.7)( 1.8)SA GETSPI | カーネルは、システム内で一意な新規 SPI を取得し 、セキュリティ・アソシ
エーションの状態を SA LARVAL としてセキュリティ・アソシエーション管理テーブ

SPI をユーザへ返す。
SA UPDATE | SA GETSPI で取得した SPI を持つセキュリティ・アソシエーションを上書き
ルに登録する。取得した

更新し 、セキュリティ・アソシエーションを使える状態にする。
4 draft-mcdonald-pf-key-v2-00.txt

第 13 部IP 層におけるセキュリティ技術

357

SA ACQUIRE | カーネルが、IPsec を適用するために必要なセキュリティ・アソシエーショ
ンの生成要求をする。

SA REGISTER | SA ACQUIRE を受けるためにカーネルへプロセス ID を登録する。
SA EXPIRE | セキュリティ・アソシエーションの生存期限が切れたことをセキュリティ・
アソシエーション管理プロセスへ知らせる。

SA_ACQUIRE
SA_EXPIRE
PF_KEY socketinterface

Automated Key
Management Application
SA_ADD
SA_DELETE
SA_GET
SA_DUMP
SA_FLUSH
SA_UPDATE
SA_REGISTER

図

1.8: 自動セキュリティ・アソシエーション管理で使用可能なメッセージ

カーネル内では、以下の様なセキュリティ・アソシエーションの状態を管理する。また、これらの関係を図に示す。

1.9

SA SPAWN | カーネル内でセキュリティ・アソシエーションが割り当てられ、初期化時に一時的に存在する状態である。

SA USED | 使用可能または使用中。SA USED 状態のセキュリティ・アソシエーションだけが 、SA GET コマンドに応答する。
SA LARVAL | SPI は割当済みだが、セキュリティ・アソシエーションとしては未完成な状態。
SA ZOMBIE | 期限切れだが、使用可能。
SA DEAD | 削除待状態。
外向きのセキュリティ・アソシエーションは、以下の条件で全て一意に識別される。

/
 始点アドレス/始点マスク
 終点アドレス 終点マスク

 終点ポート 始点ポート358

1996 年度 WIDE 報告書
SA_SPAWN

SA_LARVAL
SA_DELETE

SA_GETSPI
SA_UPDATE

SA_USED

SA_ZONBIE
SA_DELETE

SA_EXPIRE

SA_ADD

SA_DEAD
SA_DELETE

図1.9: セキュリティ・アソシエーションの状態遷移図

 次ヘッダ
内向きのセキュリティ・アソシエーションは、終点アドレス、または終点プロキシ・ア
ドレスが自ホストならばのみで一意となる。それ以外は、外向きのトラフィックと同様である。
アドレス、マスク、上位層プロトコルとポート番号、プロキシ・アドレスを組み合わせる
ことにより、以下ようなセキュリティを提供できる。当然これ以外の組合せも考えられる。

SPI

|

IP

1

 ホスト単位与えられた
アドレス同士の通信に対して、 つのセキュリティ・ア
ソシエーションを割り当てる。

|

IP セッション単位
与えられた
アドレス、上位層プロトコル、ポート番号に対して つのセキュリティ・アソシエーションを割り当てる。

1

 セキュリティ・ゲートウェイ
セキュリティを提供する。
1.4.3| 与えられたサブネットまたはホストの通信に対して、セキュリティ・プロト コル処理部

1.10

処理の概要を図に示す。
送信処理はまず、ip_output() のラベルの直後、分割処理が行なわれる前で
ipsec_output() を呼び出す。ipsec_output() では、ホストに設定されたセキュリティ・
ポリシーを検査し 、それに従い送信処理方法を決定する。アドレスとマスク、ポート番号からセキュリティ・アソシエーションを検索し 、それに従い処理する。
受信処理はまず、ipintr() でホストに設定されたセキュリティ・ポリシーを検査し 、それに従い受信処理方法を決定する。再構成した後、次ヘッダが IPPROTO ESP ならば 、
ipsec_input() を呼び出す。ipsec_input() では、によりセキュリティ・アソシエー

senditSPI

第 13 部IP 層におけるセキュリティ技術

359

socketlayer
pr_output()
ip_output()
protocollayer

pr_output()(sendit)(reassemble)

ipsec_policy()
ipsec_output()(fragment)interfacelayer(ip_p)

ipsec_input()ether_output()

図ipsec_policy()
IF_ENQUEU()

ipintr()ether_input()

1.10: 横河の実装での処理の概要図

ションを検索し 、それに従い処理する。セキュリティ・アソシエーションを取得できない
パケットは破棄し 、icmp_error() を呼び出す。
1.4.4

セキュリティ・ポリシー

システムに以下のポリシーレベルを用意し 、デフォルトの動作を指定可能とする。これ
らは、ip_output() と ipintr() で検査される。

IPSEC LEVEL NONE | 外向きのパケットは IPsec を適用しない。内向きのパケットは無条
件で受信処理を行なう。

IPSEC LEVEL AVAIL | 外向きのパケットに対するセキュリティ・アソシエーションが存在すればこれを使用する。それ以外は IPSEC LEVEL NONE と同様。内向きのパケットは無条件で受信処理を行なう。

IPSEC LEVEL WALL | 外向きのパケットに対するセキュリティ・アソシエーションが存在すればこれを使用する。それ以外は IPSEC LEVEL NONE と同様。内向きのパケットはIPsec の適用を必須とする。つまり IPsec が適用されていないパケットは受信処理を行なわない。

IPSEC LEVEL USE | 外向きのパケットに対するセキュリティ・アソシエーションが存在すればこれを使用する。セキュリティ・アソシエーションが存在しなければセキュリ

3601996 年度 WIDE 報告書
ティ・アソシエーション確立要求5を出し 、確立された後これを使用する。内向きのパケットは無条件で受信処理を行なう。

IPSEC LEVEL REQUIRE | 外向きのパケットに対するセキュリティ・アソシエーションが存在すればこれを使用する。セキュリティ・アソシエーションが存在しなければセキュ
リティ・アソシエーション確立要求を出し 、確立された後これを使用する。内向きのパケットはの適用を必須とする。

IPsec
IPSEC LEVEL UNIQUE | 外向きのパケットに対するセキュリティ・アソシエーションが存在すればこれを使用する。セキュリティ・アソシエーションが存在しなければセキュ
リティ・アソシエーション確立要求を出し 、確立された後これを使用する。さらに、
そのセキュリティ・アソシエーションが他のセッションに使用されないことを保証する。内向きのパケットはの適用を必須とする。

IPsec

以上のセキュリティ・ポリシーは、今後エンド ・ノード のためにソケット単位で設定可能とする予定である。また、ソケット単位のセキュリティ・ポリシーが設定可能となった
場合には、以下のそれも設定可能とする予定である。

IPSEC LEVEL DEFAULT | システムのデフォルトを使用する。
IPSEC LEVEL BYPASS | システムのいかなるセキュリティ・ポリシーをもバイパスする。
セキュリティ・アソシエーション管理デーモンなどの特権アプリケーションにのみ設定可能とする。
1.4.5

YIPS の課題

以下に今後考慮しなければならない大きな問題を列挙する。

 認証と対リプレ イ攻撃を伴った

ESP の変換6 の実装。

 セキュリティ・アソシエーションと鍵の生存時間。
 安全な通信路を確保する準備としてセキュリティ・アソシエーションを交換しなければならない。現状は手動のセキュリティ・アソシエーション管理方式であるが、大規
模なネットワークを考えると動的な管理方式が必須となる。今後はこの方式を検討し実装する必要がある。
 ユーザが独自にセキュリティ・ポリシーを設定できるよう、ソケット単位での設定に対応するべきである。
5 現状のセキュリティ・アソシエーション管理方法は手動方式のみなので、手で設定する必要がある。
6 draft-ietf-ipsec-esp-des-md5-03.txt

第 13 部

361

IP 層におけるセキュリティ技術

 カーネルではセキュリティ・アソシエーションを線形で管理している。管理しなければならないセキュリティ・アソシエーションが増えるにしたがい性能にに影響が出る
はずである。セキュリティ・アソシエーション管理の最適化が必要だろう。

1.5

1996 年 WIDE 春合宿での相互接続実験

1996 年 WIDE 春合宿において、(株) 東芝、ヤマハ (株)、横河電機 (株) からそれぞれ
IPv4 用の IPsec の実装を遠鉄エンパイア・ホテル内の一室に持ち寄り、1996 年 3 月 17 日
から 18 日にかけて相互接続性を検証した。それぞれの実装の概要を表 1.2に示す。
東芝

AH
ESP
鍵管理 備考Keyed MD5 DES-CBC, 3DES-CBC SKIP BSD/OS 2.1 のユーザ

ヤマハ

Keyed MD5 DES-CBC, 3DES-CBC なし

横河なし

DES-CBC, 3DES-CBC なし
表1

3ping traceroutetelnetプログラムとして実装
リモートルータ
独自
に実装
のカーネ
ルに実装

ISDN
( OS)
BSD/OS 2.1

1.2: 実装概要(

PC

RT100i)

接続試験は 台のハブに つの実装 東芝、横河はノート、ヤマハはを接
続し 、お互いに、を用いて接続を確認するという方法で行った。また、東芝と横河の間はでも試験を行った。パケットモニタには全く別の上で動作するを利用した。
接続試験に用いたアルゴ リズムは、
としては
、
としては
と
を試験した。鍵管理プロトコルは東芝しか実装していなかったため、今回は試験の対象外とした。
では 者間で相互に通信できた。
ではヤマハと東芝間で通信できた。
＋
では、ヤマハと東芝間で通信できた。これらの試験結果を表〜 にまとめる。なお、やなどの試験方法
による差はみられなかったので、それらに関する情報は載せていない。
結果的にほとんどの項目で接続を確認できたが、横河とヤマハは試験期間中に相当量のコードを書き直したり書き足したりした。はじめ接続ができなかった原因としては、やアルゴ リズムに対する理解が間違っていたことが挙げられる。東芝はほとんど変更無しであった。
速度に関しては評価してないが、実際にテストした感触ではなしに比べるとかな
り遅くなる。実用上ではいかに速いハードウェア提供できるかが鍵になってくるであろう。

tcpdump

3DES-CBC

PC

AH

Keyed MD5 ESP

DES-CBCESP(DES{CBC) 3
ESP(3DES{CBC)
ESP(DES{CBC) AH(Keyed MD5)
1.3 1.5
ping traceroute

RFC

IPsec

362

1996 年度 WIDE 報告書!
東芝 ヤマハ 横河
東芝
○
○
ヤマハ
○
○
横河
○
○

|

表

|

|

1.3: ESP(DES-CBC)!
東芝 ヤマハ 横河
東芝
○
×
ヤマハ
○
×
横河
×
×

|

表

|

|

1.4: ESP(3DES-CBC)!
東芝 ヤマハ 横河
東芝
○
ヤマハ
○
横河

|
|

表

|
|

|
|
|

1.5: ESP(DES-CBC)+AH(Keyed MD5)