| 題名 | 端末に依存しないNAT越えシステムの提案と実装 |
| 著者 | *宮崎 悠 (名城大学大学院 理工学研究科), 鈴木 秀和 (名城大学大学院 理工学研究科 ), 渡邊 晃 (名城大学大学院 理工学研究科) |
| Page | pp. 587 - 592 |
| Keyword | NAT, NAT越え, DNS, ホームネットワーク |
| Abstract | インターネットではIP アドレスの枯渇を回避するため，家庭内や企業内のネットワークはプライベートアドレスで構築されるのが一般的である．それらのネットワークとインターネットの間にはアドレス変換装置(以下NAT：Network Address Translator) が必要である．しかし，このような環境ではインターネット側の端末からプライベートアドレス空間の内部が見えなくなるため，外側の端末から内側の端末へ通信を開始することができないという制約がある．これはNAT越え問題と呼ばれている．これまで，企業ネットワークにおいてはファイアウォールが設置され，内側からの通信開始のみを許可するのが一般的であったため，NAT の制約が表面化することはなかった．今後は家庭にもネットワークが導入されること想定されるが，そこでは企業のような厳しいセキュリティポリシーは必要とならない．ここでは外出先から家庭内の端末に自由にアクセスしたいというニーズが十分に考えられるため，上記のようなNAT の制約を除去することは有益である．この課題を解決する為にこれまで様々なNATテーブル越え技術が提案されている． NAT 越えの既存技術として，STUN (Simple Traversal of User Datagram Protocol Through Network Address Translators)，AVES(Address Virtualization Enabling Service) やNAT-f (NAT-free protocol)などがある．STUN はインターネット上の専用サーバを利用することによりNAT 越えを実現できるが，第三の装置が必要で，かつアプリケーションが限定されるという課題がある．AVES はwaypointと呼ばれる特殊なサーバと改造したNATルータが協調してNAT 越えを実現できるが，STUN と同様に専用のサーバが必要であり，経路冗長が発生するという課題がある．我々はSTUN やAVES の課題を解決するため，インターネット上の端末とNAT ルータが連携することによりNAT 越えを実現できるNAT-f と呼ぶプロトコルを提案している．しかし，端末への機能追加が必要であることから，一般ユーザがNAT 越えを行うのは難しい．そこで本稿では改良したDNS サーバとNATルータが協調することにより，一般のユーザ端末でもNAT 越えを可能とする方式を提案する． 本提案方式をNTS(NAT-Traversal Support)プロトコルと呼び，本方式で使用する改良したDNSサーバをNTSサーバ，NATルータをNTSルータと呼ぶ．また，NTSルータ内のプライベートネットワークに存在する端末をPN(Private Node)と呼び，NAT越え通信を開始する外部端末をGN(Global Node)と呼ぶ．ここでPNはグローバルアドレスを所持していないので，外部の一般DNSサーバに予めPNのFQDN(Fully Qualified Domain Name)とNTSルータのアドレスをDDNS登録する必要がある．これは一般のDDNS登録と同様で，本方式の特別な処理ではない．この際，NTSルータはPNのDNS登録パケットからFQDNとプライベートIPアドレスを対応させPHL(Private Host List)へ記憶させておく．また，本方式を利用するGNはプライマリDNSをNTSサーバに指定しておく． GNがPNへ通信を開始する場合，GNはNTSサーバへPNのFQDNでクエリを送信する．NTSサーバは通常のDNS機能によりDNS名前解決を行い，得たDNSリプライパケットからNTSルータのグローバルアドレスを取得する．NTSサーバはNTSルータへGNからPNへの通信要求があることを通知し，NTSルータにその情報を保持させておく．次にNTSサーバはGNへ先ほど得たNTSルータのグローバルアドレスを伝える．GNは通常のDNSを利用した通信と同様に取得したIPアドレス宛に通信を開始すると，NTSルータは事前に得ていた情報とGNからの通信パケットによりNATテーブルを生成し，通信パケットをPNへ転送することができる．PNから返信や以降の通信は通常のNATを介した返信と同様に行われる．NTSサーバとNTSルータ間のやりとりはユーザ端末とは関係のないところで成されるため，GNやPNはNATやNTSを意識せずに通信を行うことができる． |
| 題名 | NATを越えてグループ通信が可能な拡張DPRPの提案 |
| 著者 | *後藤 裕司, 鈴木 秀和, 渡邊 晃 (名城大学大学院理工学研究科) |
| Page | pp. 593 - 600 |
| Keyword | NAT, IPsec, protocol |
| Abstract | 企業ネットワークでは不正侵入，データの盗聴や改竄などの脅威に対するセキュリティ対策が課題となっている．組織外部からの脅威に対しては通信の暗号化やディジタル署名など，セキュリティ強度の高い技術が利用されており，ファイアウォール(以下FW)やIDS(Intrusion Detection System)などと協調するなど，様々な工夫がなされている．しかし，企業ネットワークのセキュリティ脅威はイントラネット内部にも存在しており社員や内部関係者による不正による犯罪が多く報告されている．しかしながら，イントラネット内のセキュリティ対策は，ユーザ名とパスワードによる簡単な相手認証，アクセス制御しかされていないのが現状であり，有効な対策が今後必要になると考えられている．ネットワークセキュリティの代表的な技術としてIPSecがあり，現在VPNを構築する手段として広く利用されている．IPSecは通信に先立ち暗号・認証に必要なパラメータを動的に生成して安全な情報の交換を行う．しかし，IPsecには多くの設定項目がありシステム環境が頻繁に変化するような環境では管理者の負担が大きい．また，ホスト間で暗号化通信を行うトランスポートモードと，ネットワーク間で利用されるトンネルモードで互換性がないため，セキュリティドメインが階層的に構築されていたり，ドメイン単位と個人単位の通信グループが混在したりするような環境では利用することが難しい．そこで我々は柔軟かつ安全なグループ通信を可能にするためにシステム構成が変化してもその変化を動的に学習することができるDPRP（Dynamic Process Information Protocol）と呼ぶ通信プロトコルを提案してきた．DPRPでは通信端末間の通信に先立って2往復のネゴシエーションを行うことで，DPRP対応端末の通信グループ情報などの情報を収集して各装置に動作処理情報テーブルPIT（Process Information Table）を生成する．PITには暗号/復号/透過中継といった処理内容が記述されている．ネゴシエーション終了後は生成したPITに従って通信パケットを処理する． 近年、アドレス管理を容易にするため、企業なでもNAT（Network Address Translation）を使うケースが増えてきた。これまでのDPRPはNATが介在するような通信環境を想定していなかった。NATではパケットのIPアドレスが変換されてしまうため適切なPITを生成できなくなる。本稿ではNAT外部からNAT内部へ通信を開始する場合についてDPRPの実現方式の検討を行った．NAT外部からの通信を始める場合はNAT越え問題を解決する必要がある。この問題は、DNSサーバとNATルータが協調することにより解決する。また、DPRPをNAT越えに対応できるよう拡張する。DPRPネゴシエーションの一往復目では、NATルータに強制的にNATテーブルを生成し、NATテーブルにマッピングされたポート番号をNAT外部の端末に応答することでポート変換テーブルを生成する。二往復目では、外部端末とNATルータに、NATにマッピングされたコネクション情報をもとにPITを生成する。ネゴシエーション終了後、外部端末は通信パケットをNATにマッピングされたポート番号に変換してからPITの処理を行う。この方法より内部端末と通信を開始することが可能となる。 |
| 題名 | マルチパスを利用したSCTPにおける帯域集約機構の提案 |
| 著者 | *岩崎 あかね, 韓 閏燮 (慶應義塾大学大学院理工学研究科), 寺岡 文男 (慶應義塾大学理工学部情報工学科) |
| Page | pp. 601 - 608 |
| Keyword | SCTP, トランスポート, 帯域集約, マルチパス |
| Abstract | 近年，GRID環境などにおいて大量のデータを高速に転送する事例が増加している．また，有線 Local Area Network (LAN)，無線LAN，携帯電話など複数のネットワークインタフェースを持つ端末の普及が進んでいる．ホストが複数のネットワークインタフェースを持つ環境をマルチホーム環境と呼ぶ．ユーザが複数のInternet Service Provider (ISP)と契約することで各ISPからIP アドレスをそれぞれ取得し，ユーザが使用するホストのマルチホーム環境が実現された場合，これらの複数のIPアドレスを同時に利用し，複数のpathに同時にデータ送信を行うことで帯域集約・負荷分散が実現でき，データ転送のさらなる効率化が図れると考えられる．また，Transmission Control Protocol (TCP)の後継トランスポートプロトコルとして注目されている Stream Control Transmission Protocol (SCTP)はTCPの様々な問題点を解決している．例えば，SCTPではTCPのConnectionに対応する1つのAssociationで複数のpathを保持することが可能であり，これによりSCTPはTCPに比べ耐故障性が向上している．SCTPは1つのAssociationで複数のpathを使用可能であるため，マルチホーム環境に適しており，SCTPは今後TCPに代わるトランスポートプロトコルとして広く世の中に普及すると考えられる．SCTPを利用した帯域集約・負荷分散手法にはいくつかの提案があるが，pathの選択にインタフェース情報を考慮していない，pathがAssociationで共通に管理されているなどの問題点がある． そこで，本研究では既存研究の問題点を解決し，トランスポートレベルでの帯域集約・負荷分散を実現する機構であるマルチパスSCTPを提案した．マルチパスSCTPではAssociation確立時にお互いのインタフェース情報を交換し，それを基に最適なpathを選択する機能を提案した．具体的には，SCTPはAssociationの確立時にINIT，INIT ACK，Cookie Echo，Cookie ACKの4つのメッセージ交換するがINIT，INIT ACKメッセージでお互いのインタフェースのID，インタフェースの種類，帯域を交換する．そして，送信側はINIA ACK受信時に，受信側はCookie Echo受信時にそれぞれ同じ関数を用いて交換したインタフェース情報を基にpathを選択する．そうすることで無線インタフェースは無線インタフェース同士，有線インタフェースは有線インタフェース同士といった様な同じインタフェースの種類でpathが決まることを保証した．さらに同じインタフェースの種類でも，帯域の近いインタフェース同士を組み合わせることで，帯域の有効利用を図り，さらなるデータ転送の効率化を実現した．また，マルチパスSCTPでは複数のpathに同時にデータを送信し，path毎に再送制御や輻輳制御を行う機能を提案した．具体的には，path毎のシーケンス番号であるPath Sequence Number (PSN)を送信データに付加し，PSNを基に送受信側でパケットの到着順序を管理し再送制御や輻輳制御を行うことでデータをpath毎に管理する機能を提案した．またデータ送信時に，送信側で持つ送信できるデータの量を保持する変数である輻輳ウィンドウの最も大きなpathにデータを送信することで，データ送信時点で送信可能であるデータの容量が最も大きなpathにデータを割り当てることが可能となり，それにより効率的な通信を実現した． 以上の提案を実際にFreeBSD6.1-Releaseのオペレーティングシステム上に実装し，性能評価を行った．また，SCTPは2007年10月のバージョンを使用した．EndHost1，EndHost2の2台のマシンと4台のルータの計6台を用いてローカルなネットワークを構築し，インタフェースリストの交換の動作確認，送信レートの監視による複数のpathへの同時データ送信の確認，SCTPとのファイル転送時間，スループットの比較の3項目による性能評価を行った． マルチパスSCTPを用いた通信をtcpdumpにより監視することで，提案手法ではインタフェースリストの交換が行われていることが確認できた．また，path毎の送信レートをtcpdumpにより監視することで，複数のpathに同時にデータが送信できていることを確認できた．さらに，通常のSCTPとファイル転送時間，スループットを比較することで，ファイル転送時間がSCTPの約51.21 %に短縮され，スループットが約1.96 倍に向上していることを示し，本提案方式の有効性を証明した． |
| 題名 | パケットロス発生におけるiSCSI遠隔ストレージアクセスに関する評価 |
| 著者 | *比嘉 玲華 (お茶の水女子大学), 神坂 紀久子 (情報通信研究機構), 山口 実靖 (工学院大学), 小口 正人 (お茶の水女子大学) |
| Page | pp. 609 - 615 |
| Keyword | iSCSI, ストレージ, TCP |
| Abstract | 近年、インターネットなどの発達により、企業でも家庭でも、個人の所有する情報量が爆発的に増えてきた。それに伴って問題となってくるのが、データを保全、管理する作業である。データを格納するストレージ装置の増設や万一に備えたデータのバックアップ、データの移管など、面倒な作業が幾つも生じてくる。さらに、データが複数の機器に分散するという問題が起こる可能性もある。 こうした問題に抜本的な解決策を与えるプロトコルとして登場したのが、iSCSIである。 しかし、iSCSIは、複雑な階層構成で処理されており、バースト的なデータの転送も多いことから、通常の通信と比較して、特に、高遅延環境においては性能が著しく劣化してしまう。特に、下位基盤のTCP/IP層が提供できる限界性能を超えることはできず、最大限の性能が発揮できるようTCPパラメータなどを制御することが求められる。 一般に需要が多い遠隔ストレージへのデータバックアップを考えた場合、データの読み出し量よりも書き込み量の方が圧倒的に多く、また遠隔ストレージ側には標準的な環境のみを使用し、カスタマイズが不可能である場合も多い。 そこで本研究では、iSCSIのパラメータを最適に設定し、Initiator側のTCPソースコードにモニタ用の関数を挿入しユーザ空間からもアクセス可能なカーネルメモリ空間に記録する仕組みを作成しカスタマイズして、TCP輻輳ウィンドウの振舞とスループットを観察し、特に、高遅延環境におけるiSCSIのシーケンシャルライトアクセスの性能を高めるための手法を考案、検討する。 具体的には、本研究において、遅延装置を使って、様々な遅延を挿入した状態の下でiSCSIのパラメータを最適に設定し、スループットとTCP輻輳ウィンドウを観察したところ、デフォルト時の性能よりも良い性能が観察できたのだが、やはり、高遅延になればなるほどその差がわからなくなってしまうほど、スループット性能が劣化してしまうことが確認できた。 そこで、ネットワークアナライザを用いて性能劣化の原因を探り、それを元に性能向上の手法を提案していく。 また、IPネットワークにおいては、通信量が増加して回線や中継装置、サーバーの処理能力を超える場合などに、データ（パケット）が廃棄されるという、パケットロスが起こってしまうことがある。本研究では、理想的な高遅延環境のみを考慮した実験のみを行っていたのだが、より実際のネットワーク環境に近づけるために、様々な場合のパケットロスの環境の下でも実験していき、ネットワークアナライザを用いて性能劣化の原因の解析を行う。 |
| 題名 | GSCIPのWindowsへの実装に関する検討 |
| 著者 | *細尾 幸宏 (名城大学理工学部), 鈴木 秀和 (名城大学大学院理工学研究科), 渡邊 晃 (名城大学理工学部) |
| Page | pp. 616 - 621 |
| Keyword | ネットワークアーキテクチャ |
| Abstract | 企業ネットワークのセキュリティを確保するために通信グループを定義することは有効な方法である．しかし，IPsecのような既存の技術では通信グループの構成が頻繁に変化する場合や，個人単位と部門単位のグループ定義が混在した場合，それらに柔軟に対応するためには管理負荷が高くなり，導入が難しくなる． 我々はFPN（Flexible Private Network）と呼ぶ柔軟性とセキュリティを兼ね備えたネットワークの概念を提唱し，FPNを実現するためのネットワークアーキテクチャとしてGSCIP（Grouping for Secure Communication for IP）を提案している．GSCIPは現在FreeBSDに実装し，基本動作を確認済みである．今後GSCIPをより多くの人に利用してもらい，評価を受けるためにはWindowsに実装することが必須である． 本稿ではGSCIPをWindowsに実装する方法について検討し，GSCIPの基幹プロトコルの１つであるDPRP（Dynamic Process Resolution Protocol）の実装と評価実験を行ったので報告する． GSCIPでは，同一の通信グループに所属する端末は共通の暗号鍵としてグループ鍵を持ち，グループ鍵と通信グループを1対1に対応付ける．これにより，IPアドレスに依存しない通信グループを定義することができ，IPsecに比べて大幅に管理負荷を軽減することができる． FreeBSDにおけるGSCIPモジュールはIP層の一部を改造し，適切な場所から呼び出すサブルーチンとして実現されている．しかし，WindowsはOSがブラックボックスになっており，FreeBSDのように直接IP層を改造して実装することができない．その代わりに，Windowsは機能を拡張できるインタフェースが公開されている．この中でネットワーク機能を拡張できるNDIS（Network Driver Interface Specification）に着目し，これを用いてFreeBSDの場合と同等の機能を実現する方法を検討した． NDISはネットワークドライバの仕様やそれらドライバとのインタフェースを規定した仕様である．NDISはデータリンク層の機能の一部であり，中間ドライバとミニポートドライバがある．NDISドライバはネットワークドライバとして必要な機能を実現するモジュール群として作成して登録しておき，登録されたモジュールはNDISのインタフェースを介して所定のタイミングで呼び出される． GSCIPはNDISの中間ドライバとして実装する． FreeBSDで開発したGSCIPのモジュールはほぼそのままWindowsへ流用可能であるが，WindowsとFreeBSDで提供されているAPIの違いへの対応，MACヘッダに対する処理の追加，処理対象パケットのフィルタリングを行うなどの処理が必要になる． また，NDISドライバにはパケット送受信時にFreeBSDのIP層にはない特有の動作がある．プロトコルスタックの上位モジュールはパケットの送信を行う際に送信処理の結果をすぐには受け取らず，後で実行される結果通知処理によって結果を取得する．受信時は上位モジュールが受信パケットへの処理終了を通知すると，ミニポートドライバがリソースを開放する． GSCIPでは通信開始時にDPRPによって通信相手とのネゴシエーションを行い，グループの認証や通信の可否を判断する．このとき，トリガとなった通信パケットを待避し，ネゴシエーションパケットを送信するが，このパケットはGSCIPが動作するスタックより上位モジュールにその送信結果を知らせる必要はない．また，上記ネゴシエーションパケットの送信完了通知を上位モジュールが受け取ると管理していないパケットの通知を取得したことに起因してクラッシュを起こす可能性がある．そこで，ネゴシエーションパケットについては送信完了通知処理時と受信処理時にパケットの判別を行い，下位モジュールで全ての処理を完結させる必要がある． 上記検討結果に基づき，DPRPをWindowsのNDISを用いて実装し，性能評価を行った． DPRPのネゴシエーションによるオーバヘッド時間と通信時の処理によるスループットの低下を測定し，従来の通信に対してほとんど影響を与えないことを確認した． 今後はGSCIPの他の機能であるMobile PPC（Mobile Peer to Peer Communication），NAT-f（NAT-free Protocol），PCCOM（Practical Cipher COMmunication）を追加実装し，性能評価を行う． |