カーネル比較: 2.6カーネルでのネットワーク機能の改善

セキュリティ、電話機能、プライバシーが改善

新しいLinuxカーネルではネットワークに関する多くの領域(トンネリングやファイル・セキュリティの向上から暗号化やプライバシー保護まで)をサポートするようになり、また改善を行っています。この記事ではこうした改善が、Linuxをよりセキュアに、また企業対応にしようとするユーザーの努力に対して、どのような影響を与えるかについて説明します。

Robert Williamson, Software Engineer, Linux Technology Center, IBM

Robbie WilliamsonはIBM Linux Technology CenterのStaff Software Engineerです。2000年にコンピューター・サイエンスの学位でテキサス大学を卒業し、サポート、認証技術者として、またUNIXの各種実装開発の領域で活躍してきました。Linux Test Projectの維持管理者の一人でもあります。



2004年 3月 03日

新しいLinux 2.6カーネルでは2.4バージョンよりも多くの面で改善が行われています。技術的な進歩の一つはカーネルネットワーク・オプションです。行われた改善はネットワーク・オプションに関連したファイルの大部分に及びますが、この記事では特定のファイルよりも、全体に影響するような主な機能改善や追加に焦点を当てることにします。

具体的にこの記事では、ネットワーク・ファイルシステム(Networking File System: NFS)とインターネット・プロトコル・セキュリティ(Internet Protocol Security: IPSec)での改善に焦点を当てます。また、TCP/IPプロトコル・ファミリーの新メンバーの2つ、ストリーム制御通信プロトコル(Stream Control Transmission Protocol: SCTP)とインターネット・プロトコル・バージョン6(IPv6)にも触れます。

ネットワーク・ファイルシステムとセキュリティ

2.6カーネルはネットワーク・ファイルシステム (NFS)バージョン4の採用によって改善されています。新しいバージョンのNFSはよりセキュリティが向上し、より広範なオペレーティング・システムでサポートされ、またサーバー・デーモンのオーバーヘッドを減少しています。

バージョン4のネットワーク・ファイルシステム(NFSv4)が2.6カーネルに含まれたことで、以前のバージョンのNFSでは見られなかったようなセキュリティや機能の改善が行われています。NFSのユーザーはGSS-API(General Security Service API)のリモート・プロシージャー・コール(RPC)実装を使うことで、セキュアなやり取りが行えるようになりました。また複合プロシージャー(compound procedure)の概念も導入されていますが、これは複数のRPCを一つのコールにまとめるものです。コールをまとめることでファイルシステム操作に必要なRPCが少なくてすみ、その結果NFS応答も早くなります。

さらにNFSのオーバーヘッドを減少させるものとして、NFSはファイル・ハンドルからパスへのネーム・マッピング(handle-to-path name mapping: mountd)やバイト範囲ファイル・ロック(byte range file locking: lockd)を処理するようになっており、これによってサーバー側で必要なサポート・デーモンが少なくてすむようになっています。サーバー側での実装を楽にするためNFSv4にはさらに別のファイル・ハンドル・タイプをサポートしており、ファイルやファイルシステム属性が分類できるようになっています。この新しいNFSバージョンはサーバーの移行や複製もサポートしており、クライアントが必要とする時には途切れることなくサーバーを切り替えることができます。最後にNFSv4では、キャッシングの状況下で、(必要な場合には)サーバーがクライアントに対して一定の責任を委譲できるようになっています。

NFS RPCリクエストに対する暗号認証が使えるようになったことで、エンド・ツー・エンドでのNFSセキュリティが保持できます。NFSv4ではRPCSEC_GSSフレームワークを使ってRPCの基本的なセキュリティを拡張しています。このセキュリティ・フレームワークが、NFSv4にクライアントとサーバー間での認証、整合性、プライバシーのための機構を提供しています。クライアントはまたサーバーに対して、(アクセスのためにどの機構を使う必要があるかという視点からの)セキュリティのポリシーを問い合わせることができます。この内部セキュリティ交渉によって、クライアントが安全に、(クライアント、サーバー両者の要求に合致する機構に対する)サーバーのセキュリティ・ポリシーに合致できるようになります。

複合プロシージャー(compound procedures)もNFSのバージョン4に含まれた改善の一つです。これまでのバージョンのNFSではクライアントが複雑な論理ファイルシステムのRPCを構築できる手段はありませんでした。複合プロシージャーを使うことで、クライアントは一つのRPCリクエストの中にLOOKUPOPEN、それにREAD操作を組み合わせ、一つのリクエストでファイルからデータを読むことができます。古いバージョンのNFSではクライアントが、こうした3つの操作それぞれに対してRPCを行う必要がありました。こうした複合リクエストをサーバー側で処理する実装は非常に簡単です。複合リクエストは、サーバーで別々のリクエストのリストに分割されます。サーバーはリストが終わるまで、または失敗するまで、リストにある各操作を繰り返し実行します。その上で、全ての操作を行った結果をクライアントに戻します。

NFSv4ではサーバーに必要とされる非NFSサーバー・プロトコルの数を減らすことで、さらに簡素化を図っています。バージョン4では、NFSコードがファイルハンドルをパス名にマップすることができますが、これは古いバージョンでmountdプロトコルが行っていることです。サーバーは、サーバーがエクスポートするファイルシステム・ツリーの最上部を表す、ルート・ファイルハンドルを提供します。サーバーでは複数のファイルシステムを持つことができますが、これはファイルシステムに(真のファイルシステム間のパス名にある潜在的隙間をカバーする)疑似ファイルシステムを付け加えることで可能になっています。これがグローバルな階層構造名前空間のサポートにつながっています。

さらに、新しいバージョンのNFSプロトコルではバイト範囲ファイル・ロッキング(byte range file locking)をサポートしています。これまでのバージョンではネットワーク・ロック・マネージャーが提供するlockdプロトコルをサポートしていました。ファイル・ロッキングのサポートの変更により、サーバーはリース・ベースのモデル(lease-based model)を使ってファイルのロック状態を維持できます。基本的に、クライアントはサーバーに対してロック・リクエストを出す必要があります。許可されれば、クライアントは、サーバーが規定するリース時間内にリースを更新しなければなりません。サーバーはリース期間終了後にクライアントのロックを解放します。(mountdとlockdという)2つのプロトコルを無くしたことで、NFSサーバーを操作するための処理オーバーヘッドが減少しています。

新しいNFSのバージョンには、NFSサーバーの実装が容易になるような改善も行われています。ファイルシステム・オブジェクトの生存時間中にファイルハンドルが参照するパーシスタンスは、一部の古いNFSサーバー実装では困難な要求でした。NFSv4はパーシスタントなファイルハンドル・タイプに加えて揮発性ファイルハンドル・タイプを追加しています。こうした2つのファイルハンドル・タイプのおかげで、サーバー実装はオペレーティング・システムだけでなく、サーバーにあるフィルシステムの機能にも合わせることができます。クライアントはサーバーが提供するファイルハンドルのタイプを知り、それに対応準備し、それぞれのタイプを処理するための操作を設定することができるのです。

ファイルとファイルシステム属性の分類もNFSに追加されたもので、これによってもサーバー実装が容易になります。古いNFSバージョンでは、基本的にUNIXファイルやファイルシステムを主な対象とした固定の属性セットを使用しています。サーバーまたはクライアントがある特定の属性をサポートできない場合には、できうる限りその属性をシミュレートする必要がありました。バージョン4では属性を3つのグループ、必須(mandatory)、推奨(recommended)、名前指定(named)に分類しています。

必須属性は最低限のファイルまたはファイルシステム属性で、サーバーが適切に提供、表現する必要のあるものです。推奨属性は異なるファイルシステム・タイプやオペレーティング・システムを表し、オペレーティング・システムをよりうまく取り込み、オペレーティング・システム間の相互運用性を高めるためのものです。名前指定ファイルシステム属性分類はディレクトリやファイルと関連付けられたバイト・ストリームであり、ストリング名で呼ばれます。こうした名前指定属性は、クライアント・アプリケーションが特定のデータをファイルやファイルシステムと関連付けるために使用します。属性分類システムができたことで、大幅なコード修正をせずに、新しい属性を簡単に追加できるようになったわけです。

NFSv4では冗長性を向上させ、サーバー側でのファイルシステム複製や移行をサポートするようになりました。特別なファイルシステム位置属性を使うことで、クライアントはファイルシステムの位置に関してサーバーに照会することができます。サーバーのファイルシステムが負荷分散などの理由で複製されている場合には、クライアントは、要求したファイルシステム全ての位置を受け取ります。そうするとクライアントは自身のポリシーを利用して、要求したファイルシステムの適切な位置をマウントし、アクセスすることができます。同様にファイルシステムが移行されている場合にはクライアントは、古い位置をアクセスしてエラーを受信すると、そのファイルシステムの新しい位置を照会し、位置変更に対応するために必要な変更を行います。

NFSv4の注目点の最後は、キャッシュの際にサーバーが一部の責任をクライアントに委譲できる機能です。これは真の意味でのデータ整合性のために必要なものです。これまでのバージョンのNFSではUNIXの書き込みを安全に使うことはできませんでした。NFSv4ではサーバーがクライアントに対して、一定のファイルに対する読み書きの委譲を行います。あるファイルに対して、あるクライアントが読み込み委譲を受け取ると、他のクライアントには委譲期間中、そのファイルに対する全ての書き込みが許可されなくなります。さらに、あるクライアントがあるファイルに対して書き込み委譲を受け取ると、他のクライアントはどれも委譲期間中、そのファイルに対して読み書きできません。あるクライアントに委譲したファイルに対して、別のクライアントが競合するアクセスを要求した場合には、サーバーが委譲を取り消します。この場合にはサーバーは委譲したクライアントに対して、クライアントとサーバー間にあるコールバック・パスを使って通知し、委譲を取り消します。委譲によりクライアントは、(サーバーと即時にやり取りすることなく)NFSキャッシュを使ってローカルに操作をサービスできるようになります。その結果サーバーの負荷も、ネットワークのトラフィックも減少します。


改善されたTCP

ストリーム制御通信プロトコル(Stream Control Transmission Protocol: SCTP)は2.6カーネルに追加された新しいトランスポート層です。SCTPは通信制御プロトコル(TCP)と同じ特性を数多く持っているのと同時に、電話、データ通信、高可用性(high availability)アプリケーションに有利な、別の特性も持っています。

SCTPはTCPと同様な機能を提供していますが、これはエラーの無い、連続的なデータ伝送を保証することで、またデータ通信の全期間中、両方のエンドポイント間にセッション指向でエンド・ツー・エンドの関係を確立することで実現されています。ところがSCTPにはTCPを超えた新しい機能もあり、IPネットワーク上で電話信号を伝送する際など、ある種の作業負荷には致命的に重要な、マルチ・ストリーミングやマルチホーム化(multi-homing)なども提供しているのです。

マルチ・ストリーミングでは、データは複数の、独立にシーケンス化されたストリームに分割できます。その結果、どのストリームでのメッセージの喪失も、そのストリーム内での配信に最初影響するだけで、他のストリームの配信には影響しません。SCTPのメッセージ指向はTCPのバイト指向と異なり、個々のメッセージ境界のフレーム化をサポートするので、データを複数ストリーム化できます。TCPに使われているデータの単一ストリーム手法では、メッセージが失われた場合やシーケンス・エラーが起きた場合に遅延が大きくなります。TCPは正しいシーケンスが復元されるまで、アプリケーション・レベルへのデータ配信を待つ必要があります。このデータ配信遅延は電話の信号伝送やマルチメディア・コンテンツを持つWebページの配信など、全メッセージのシーケンスが必ずしも必要ではないアプリケーションでは、パフォーマンス低下の元になります。電話の信号伝送には、同じコールなど、同じリソースに影響するメッセージにはシーケンス化が必要ですが、他の関連メッセージはシーケンスの整合性要求無しに配信できます。

異なるタイプやサイズのマルチメディア・オブジェクトを持つWebページはマルチ・ストリーミングを使うことで、そうしたコンポーネントを厳密に順序づけせず、部分的に順序づけるだけで伝送することができます。データ伝送がこのように柔軟になると、トランスポートに対するユーザーの認識改善が期待できます。さらに、データ伝送が一つのSCTP関連付け内で行えるということは、全てのストリームが共通のフロー機構、輻輳制御機構に従うと言うことを意味し、これでトランスポート・レベルで要求される作業が減少することになります。

マルチホーム化もSCTPの機能の一つで、伝統的なトランスポート層プロトコルとは一線を画すものです。マルチホーム化では一つのSCTPエンドポイントで複数のIPアドレスをサポートでき、一つの接続先までに複数の経路がある状況では冗長性を持たせることができます。TCPやUDPはシングル・ホームのセッションであり、ローカルLANアクセスに障害が起きるとエンドシステムを分離し、全ネットワーク内で障害が起きると、IPルーティング・プロトコルがトラフィックを再ルーティングするまで一時的な障害を引き起こします。

マルチホームのSCTPは冗長なLANと組み合わせることで、ローカルでのエンドポイント・アクセスを強化します。(SCTPのマルチホーム化に関連して使われている)異なるプレフィックスや経路を持つ複数のアドレスで、全ネットワークに渡って冗長性が改善します。SCTPのマルチホーム化機能にはネットワークの負荷分散や負荷共有機能はありません。この機構の主要な目的はSCTPで通信しているアプリケーションに対して冗長な接続ができるようにすることです。SCTPは一つのアドレスを「プライマリー」アドレスと指定し、全てのデータ通信にこのアドレスを使用します。再送信の必要が起きた時には、他方のエンドポイントに到達する可能性が上がるように、全てのアドレスにデータが送信されます。プライマリー・コネクションが完全に失敗した時には、全てのデータは、ある代替アドレスに経路変更されます。標準の高可用性と同様な方法を使用して、障害が起きたプライマリー・コネクションに向かって「ハートビート(heartbeat)」信号を送信し、これで元々のコネクションが再度確立できるかどうかを判断します。


IPセキュリティと圧縮

インターネット・プロトコル・セキュリティ(IPSec)も2.6カーネルでの改善点です。IPSecでは、ローカルネットワークやインターネットにまたがるネットワーク通信を認証、暗号化できます。2.6カーネルではパケット暗号化に加えてIPペイロード圧縮(IPComp)を使い、伝送を改善しています。IPCompは、低速で輻輳したネットワークでの伝送品質を改善するための圧縮、逆圧縮アルゴリズムを使用したプロトコルです。

2.6カーネル・コードにIPSecを導入したことで、ユーザーはIP層でのトラフィックのためにセキュリティ・サービスを利用できるようになります。IPSecはインターネットを作り上げているメディアとアプリケーションの複雑な混合組み合わせに対する一般的なソリューションになります。2.6カーネルは、認証ヘッダー(Authentication Header: AH)とカプセル化セキュリティ・ペイロード(Encapsulated Security Payload: ESP)という、2つのIPSec機構をサポートしています。どちらも暗号系API(Cryptographic API)が提供する認証アルゴリズムに基づいており、これも2.6カーネルに含まれています。

認証ヘッダー(Authentication Header: AH)はIPヘッダーのすぐ後に追加される追加ヘッダーで、パケット認証のためのものです。パケットレベル認証のおかげでユーザーは、受信したパケットがある特定のマシンから来たものだと分かり、その内容が途中のどこかで改変されてはいないことが確実に分かります。この機構はパケットの内容を隠したり保護したりしようとするものではありません。AHが提供する主な機能はパケット整合性保証なのです。さらに暗号化の恩恵を受けたいと思うユーザーは、ESPを追加して使用すべきです。

ESP(Encapsulated Security Payload)ヘッダーにはパケット認証に加えて暗号化を提供できる機能があります。ESPヘッダーには暗号化、認証、「反再送攻撃サービス(anti-replay service: 部分シーケンス整合の一形式)」、「限定トラフィック・フロー秘匿性(limited traffic flow confidentiality)」があります。ユーザーは認証を規定せずに暗号化を選択するかもしれませんが、そうするとパケットが活発な攻撃を受けやすくなり、ある外部実体によって暗号が破られることになりかねません。ESPヘッダーの場所はIPヘッダーの後でトランスポートモード・プロトコル(UDPまたはTCP)の前、またはトンネリングを使用している場合にはカプセル化されたIPヘッダーの前にあります。

ESPは内部のIPパケットとヘッダー全体を保護します。トンネル・モードでは内部IPヘッダーは本来意図したソース・アドレスと元の目的アドレスを運びますが、外部IPヘッダーはセキュリティ・ゲートウェイのようなホップ点のIPアドレスを含みます。


IPペイロード圧縮

IPペイロード圧縮(IPComp)はIPデータグラムのサイズを縮小します。2.6でのこのネットワーク機能によって、2つのエンドポイントにある両方のマシンが十分な計算能力を持っていれば、また輻輳状態や低速リンクで通信が行われる場合には通信状態が改善されます。

IPSecで必要となる追加ヘッダーを使用する場合にはパケットサイズが大きくなるため、IPCompプロトコルをIPSecと組み合わせて使用すると非常に便利です。IPCompには送り出しパケット圧縮と受け取りパケット圧縮という2つのフェーズがあります。圧縮・逆圧縮中も、元のIPパケット内でのデータの整合性は保持されます。インターネット固有の特性により順序が乱れて到着するパケットを許容するため、各パケットは独立に圧縮・逆圧縮されます。


IPv6プライバシー・エクステンション

2.6カーネルはIPv6で改善されたセキュリティ・オプションもサポートしています。IPv6でもIPSecやIPCompやトンネリングが動作するようにサポートを拡張しただけでなく、2.6カーネルはIPv6プライバシー・エクステンションも提供しています。

IPv6のIPSecではIPv4での場合と同じレベルの認証とセキュリティ・レベルを提供しています。IPv6-to-IPv6トンネリングのサポートも含めたことにより、2つのエンドポイント間伝送、例えば仮想プライベート・ネットワーク(VPN)を通しての伝送などで、セキュアで継ぎ目のない通信が行えるようになります。

IPv6プライバシー・エクステンションは、インターネットの匿名性を改善することに特に焦点を当てた機能であり、ユーザーがIPv6アドレスを使用する際に自分の素性を保護するためのオプションとなります。現在のステートレス・アドレス自動設定モデルでは、(イーサネット・カードや携帯電話など)デバイスのMACアドレスを使用して128ビットのIPv6アドレスのプレフィックスを作り出しています。不変の識別子を使ってアドレスを作り出すことにより、意図せずに使われてしまう可能性のあるデータが追跡できるようになります。例えばネットワーク探知プログラムがMACアドレスを知るだけで、どのマシンがいつ、別のマシンと通信していたかを追跡できるのです。

ネットワークのトポロジーによらず、またマシンが携帯電話やラップトップであってもMACアドレスは一定のままなので、ネットワーク探知プログラムからのこのデータは簡単に集計することができます。またこのデータを記録している人達は、この情報を使って作業パターンや作業場所などを追跡することができます。

IPv6プライバシー・エクステンションにより、ユーザーはランダムなインターフェース識別子を使って、別のIPv6グローバル・アドレスを生成できるようになります。マシンはこうした一時的なアドレスを、規定された時間内で、別のランダムなアドレスにリセットされるまで使うことができます。そのリセットの後も、既に確立されたコネクションは通信を維持することができますが、新しい通信は全て新しい一時アドレスで確立する必要があります。


まとめ

大部分のユーザーにとってはこうした新機能や改善された機能のいくつかによって、システム環境でのLinuxの使い勝手が向上しているはずです。

現在NFSを使っていて、パフォーマンスまたはセキュリティの改善を求めるユーザーであれば、バージョン4に移行することで、どちらも満足できるでしょう。キャリヤー・グレードのアプリケーションや電話アプリケーションの開発者であれば、SCTPが提供する機能を使って、より高品質で高信頼性のサービスを消費者や顧客に提供できるようになります。セキュアではないネットワークを通してのセキュアなデータ通信手段を必要とする人や企業にとっては、IPSecが解決手段となります。またそうした人達や企業はIPCompを使うことにより、より小さなパケットで通信できるようになり、インターネットを通してのデータ通信が改善されます。さらにIPv6に対応したことで、この次世代インターネット・プロトコルを使う人達にセキュリティやプライバシーの改善が図られることになり、またIPv4アプリケーションの開発者がこの改善IPバージョンを使うように移行を進めやすくなります。

2.6カーネルでのネットワーク機能の改善は全体的に見て、企業環境での大幅なLinux採用を促すためのステップとして、非常に前向きなものと言えるでしょう。

参考文献

  • Generic Packet Tunneling in IPv6 Specification(RFC 2473)はインターネット・パケットのIPv6カプセル化について、モデルや汎用機構の概要を説明しています。
  • アメリカ政府の調査グループがIPv6展開の影響を調査しています。関連機関によるRequest for Commentsを読んでみてください。
  • IP Authentication Header(RFC 2402)はIPデータグラムに対するコネクションレス整合性とデータ起源認証を扱っています。
  • IP Encapsulating Security Payload (ESP)はそのファンにはRFC 2406として知られており、IPv4やIPv6サービスでのセキュリティ・サービスのシグニチャー混合をESPがどのように提供しているかを説明しています。
  • RFC 3041としても知られているPrivacy Extensions for Stateless Address Autoconfiguration in IPv6は、IPv6プライバシー・エクステンションがDHCPサーバー無しにアドレスを生成するためにステートレス自動設定をどのように使うかを概要説明しています。
  • An Introduction to the Stream Control Transmission Protocol (SCTP)は親しみを込めてRFC 3286としても知られており、高位レベルでのSCTPの紹介です。
  • IP Payload Compression Protocol (IPComp)(RFC 3173)は、IPペイロード圧縮がどのように、またなぜ暗号化の前に行われるかを説明しています。
  • Network File System (NFS) version 4 Protocol(RFC 3530)はNFSへのファイル・ロックとセキュリティを導入しています。
  • AIX Security Guideでも基礎を説明しています。ここにはTCP/IPセキュリティやIPセキュリティ、NFSセキュリティやその他の説明が含まれています。
  • developerWorksのLinuxゾーンには、この他にもLinux開発者のための資料が豊富に用意されています。
  • Developer BookstoreのLinux sectionにはLinux関係の技術書が幅広く取り揃えられています。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=226873
ArticleTitle=カーネル比較: 2.6カーネルでのネットワーク機能の改善
publish-date=03032004