Cloudmark

IPv6ネットワークに近々配置されるSMTPのBCP

Tweet (454KB)ホワイトペーパーをダウンロードする

コンテンツ

1. エグゼクティブサマリー
2. IPv6のバックグラウンド
3. IPv6によって導入されるアンチ不正使用メッセージングの複雑性
   • 共存・遷移テクノロジーとそれが不正使用に与える影響
   • Dual-Stack Lite(DS Lite)の潜在的な問題
   • 増分CGNの潜在的な問題
   • 6to4の潜在的な問題
   • 6rdの潜在的な問題
   • ドメイン評価はIP評価の直接代替物ではない
4. 現在のIPv4 MTAポリシーを今後のネットワークに適用する試み
   • 許容リストのIPv6への適用
   • ブロックリストのIPv6への適用
   • IPv6接続のSMTPサーバーの慎重な展開
   • まとめて送信者を追跡
   • IPv6プレフィックス長によるCoS(Class of Service Policy)の適用
   • 制御不能な環境におけるIPv4限定サーバーの維持
5. 業界の行動を求める声
6. 結論
7. 参考文献

エグゼクティブサマリー

未割り当てのIPv4アドレスの空きが枯渇状態に近づくにつれ、IPv6の展開は固定回線オペレータや企業にとって重要度がさらに高くなります。IPv6がアンチ不正使用メカニズムにどのように影響を与えるかについて、メッセージング業界の理解は高まりつつありますが、IPv6接続、それに関連する変遷、そして翻訳技術がもたらすリスクについての認識をさらに深める必要があります。

IPv6は、限られたIPv4空間の問題を解決しますが、実行可能なメッセージングサーバポリシー内でセキュリティの脆弱性をもたらす可能性が高くなることもあります。 IPv6 はいくつかのディメンションでネットワーク攻撃の脅威対象となる領域を拡張します。また、メッセージングインフラについては、IPv6は既存のIPv4使用可能なメッセージングインフラ上で膨大な量の脅威が発生する可能性を増大させます。 本論文では、IPv6の潜在脅威を特定し、既存のIPv4 ベースのメッセージングセキュリティソリューションを検証、IPv6への適用を評価するとともに、開かれた、そして業界がサポーする形で、推奨される脅威対応方法を提示します。

本論文は、自社ネットワーク内でIPv6インフラ展開を担当するメッセージングの専門家を対象にしています。本論文を読むことで、読者はIPv6展開がメッセージングインフラに影響を及ぼす可能性のある脅威を理解し、使用するメッセージングサービスが不要なリスクや大きな資本投資につながらないように、必要なメッセージング機能をサポートするマネジメントができる合理的な展開方法を検討できるようになります。

メッセージングセキュリティコミュニティには、IPv6使用可能な世界で進化しつづけるメッセージングセキュリティをサポートするような新しいテクノロジーおよび基準の確立が必要です。業界のリーダーシップがない中では、ネットワークメッセージングインフラが断片化され不正アクセスに対して脆弱性があるような、その場かぎりの解決方法が生まれることになります。

IPv6のバックグラウンド

botに感染したPCとリンクされる可能性が高いIPｖ４ネットワークはケーブルまたはDSLモデムを使用した住宅および小規模オフィスや自宅オフィスのネットワークです。これらのネットワークには通常、１つのパブリックIPｖ4（32ビット）アドレスが割り当てられ、このネットワーク内の感染PCはそのアドレスからのみメッセージの送信ができます。このPCから送信されたものは分離させ追跡することができるので、メッセージングサーバを受け取ることで、乱用防止制御ができます。

境界線ネットワークデバイスがサービスプロバイダにに再接続し、DBCPリースをリフレッシュしていても、多くの場合、有効期限切れのDBCPリース回数が原因でネットワークがフレッシュIPアドレスを受け取ることにはなりません。この環境をIPｖ6ロールアウトと比較すると、ほんとんどのサービスプロバイダは、通常／56～／64範囲のプレフィックスサイズで大規模なIPv6ネットワーク空間（128ビット）を各顧客団体に配分しています。PCがこれらのネットワーク内の１つの中で障害を受けている場合、そのネットワークの膨大な範囲の割当IPｖ6でIPアドレスからトラフィックを特定できます。IP集束のレピュテ―ションシステムはIPｖ４の世界では標準となるので、この高周波数IPアドレスホッピング動作で、botが未検出のままになり、IPｖ6に移行後にその負のレピュテ―ションを与えてしまいます。

この問題がどのくらいの規模になるかを見るために、その範囲内の各IPv6アドレスからメッセージ1つを送信するところで、シングル／64カスタムネットワーク範囲を活用して、スパム攻撃を起動できます。これは、スパム発信者が割り当てられたネットワークブロック内部からシングルIPアドレスを再利用しないで、膨大なスパムを送信できることを意味します。送信IPアドレスが常に回転している場合でも、その攻撃者はまだ、理論的にはその／64ネットワーク内で同じIPアドレスから送信する必要もなく、一年中複数回、毎秒5億8,000万件のメッセージを送信できます。さらに、リトレーニングブラックリストは現在のIPv4のIPごとのブラックリストと類似しスタートは好調である可能性がありますが、長期的にはIPv6までスケールアップすることはできません。

IPv6によって導入されるアンチ不正使用メッセージングの複雑性

今日広い範囲で展開しているIPv4メッセージングエコシステムで、効果的で一般展開した不正アクセス防止機構の多くは、接続やメッセージ送信の元となるIPアドレスの評価に依存しています。これら機構には以下のようなものがあります。

1. リバースDNS検証（rDNS）
2. リアルタイムDNSブロックリスト（DNSBL）チェック
3. クラス・オブ・サービス（CoS）をベースとした帯域スロットル
4. センダー・ポリシー・フレームワーク（SPF）評価
5. 送信者ID評価
6. 手動ホワイトリスティング
7. IPアドレス修復
8. その他協力的レビュテ―ションシステム

これらの一般機構には、メッセージ配信の元のIPアドレスをポリシー（SPF、送信者ID）または既知の良好、疑わしいおよび不良アドレスのデータベースと照合が含まれます。

これらの不正アクセス防止技術の多くは、使用可能なアドレス空間が膨大なため、IPv6への移行全般でかなり、障害が発生します。例えば：

• サービスプロバイダの多くは、その対応に必要なメモリとディスクリソースを考え、MTA rDNSチェックの要件であるダイナミックアドレス空間用のリバースDNS記録に対応しない移行を宣言しています。これは、Sendmail等、ユビキタスメール伝送（MTA）を含む、シンプルセキュリティ機能としてrDNSチェックを利用する多数のシステムとインターフェースします。
• DNSELサービスを行うDNSサーバは、IPｖ6では、明確なリソース、キャッシュおよびパフォーマンスペナルティとあわせて、IPｖ4で必要となる以上の大規模なデータセットを蓄積し対応することが必要になります。この圧力の一部からでも解放され、このデータセット内でネットワークアグレゲ－ションを行う方法案はほとんどなく、あってもごく初歩的なものです。1つのIPアドレスという考えにおいては、かなり改善が必要ですが、ネットワークアグレゲ－ションスキームを考えた場合でもDNSがスケールしないことは可能です。
• 今日、トラフィックシェーピングソリューションは、送信者のIPｖ4アドレスへのアクセス回数が比較的少なくなること、および帯域または接続シェーピングによる各IPアドレスから受ける可能性のある損害を制限しようとすることに依存しています。これらのソリューションは、攻撃者が膨大なソースIPアドレスのセット上でメッセージ配信を行いはじめると、効果はなくなります。
• レピュテ―ションサービスまたはIPアドレス修復レポートを提供するデータマイニングサービスは、膨大な範囲からのシンプルメール転送プロトコル（SMTP）に関するデータを受け取りはじめますが、そのほとんどは悪質なものです。アドレス割付には基準が提起されているわけではないので、この情報の結合は難しいものです。IETFは一般的なIPv6ブロック割付サイズを標準化しようとしましたが、その役割を最近撤回し、「アドレス空間がどのくらいエンドサイトを割り当てているのかの正確な把握は運用コミュニティ自体の問題である」と述べています。"(1)ブロック割付サイズには標準化もガイドラインもないため、サービスプロバイダがそれぞれ、適切と判断するネットワーク割付を自由に再分割しています。サービスプロバイダがどの割付ポリシーを実行するかを正確に示すことができる基準がなく、データマイニングサービスには、IPｖ6アドレスを結合するための信頼できる情報がありません。この結果、IPｖ6アドレスが保守的に結合することでセキュリティレベルが落ちたり、IPｖ6アドレスの結合がアグレシブになることで、偽陽性になったりします。
• SPFおよび送信者IDは、問題なく移行を行うのに最適な位置にあります。ただし、他の不正アクセス防止機構あるいは将来登場する同等のものに対して信頼し続けられるかの必要性を回避するだけ技術的に安全性が十分なわけではありません。
• DomainKeys Identified Mail (DKIM)またはその他ポストSMTPプロトコルメッセージ属性に依存するレピュテ―ションシステムは技術的には興味深いですが、実用面では、現在展開されているIPアドレスベースのソリューションにはたいした利点はありません。例えば、MTAを受け取ってDKIM署名を有効にする場合、メッセージはまず、DKIMヘッダが認証される前に完全承認が必要なので、帯域やMTA計算リソースが無駄になり、メッセージがレピュテ―ションルックアップに基づく信用できないソースから発信されていることに気づくだけです。SMTPプロトコルには、データフェーズでMTAを受信中にメッセージを妨害する規定はありません。送信者が残りのデータ部分の伝送を停止する唯一の方法は、送信エージェントが一時的な問題に直面し、メッセージを再送列に入れることになる接続先を外すことです。その結果、同じメッセージ配信サイクルは数分後にはじまることになります。

共存・遷移テクノロジーとそれが不正使用に与える影響

大規模NAT（LSN、以前はと呼ばれていた）、Dual-Stack Lite (DS Lite)、インクレメンタル・キャリヤ・グレードNAT (CGN)、6to4 ゲートウェイ、6rdゲートウェイ、6in4トンネリング、 Teredoリレー等、IPv4-to-IPv6移行をサポートする技術は無数にあります。これら技術の中には有効的に活用されているものもあれば、実験段階のものもあります。これらに共通した課題は、さまざまな形態のトンネリングやアドレス移行レイヤがあげられます。

これらの機構には、メッセージ配信を要求するエージェントの実際のIPアドレスを、ある程度、隠すものもあります。受取MTAがこれらのレイヤの１つを送信者が通過したレピュテ―ションを追跡する方法を理解することが難しいか、不可能としているものもあります。この不明化が原因で、現在の多くのIPアドレスベースのセキュリティ機構が、IPアドレスが半スタティック状態、または各SMTP送信者の独自識別子の上で特定されるため、効果的に機能できなくなっています。パケット内のIPアドレスが変換レイヤ、トンネルまたはゲートウェイと交換された場合、個別ソースでの正確な対応力は阻害されます。以下のセクションでは、これら移行技術のうち3つに関して考えられる課題について記載しています。

Dual-Stack Lite(DS Lite)の潜在的な問題

Dual-Stack Lite (DS Lite)により、サービスプロバイダは、加入者宅内機器(CPE)とサービスプロバイダのネットワークの間のIPv6唯一のコネクティビティで、新規顧客を展開できます。DS Liteの長所は、サービスプロバイダはCPEレイヤにIPｖ6アドレスを提供することだけは必要ですが、ネイティブIPｖ6またはデュアルスタックアドレッシングに対応していない旧式コンピュータやデバイスをまだ使用している顧客環境に対応することです。DS Liteを使用することで、RFC 1918アドレスでDHCPを経由して局所的に対応するIPｖ4のみ対応の旧式デバイスが顧客ネットワークのエッジで、DS Lite適合のCPEデバイスから、インターネットに接続できます。このルーターはIPｖ4パケットをIPｖ6パケット内にカプセル化し、IPｖ6サービスプロバイダの内部ネットワークからLSNレイヤに転送します。次に、LSNは、元のIPｖ4パケットを取り出し、局所的にプロビジョニングされたパブリックIPｖ4アドレスからIPｖ4インターネットにNAT接続できます。その結果生成されるパケットは現在、パブリックインターネット上にあり、LSNに属するIPｖ4ソースアドレスを持つことになります。このパケットはその後、ダウンストリームIPｖ4ネットワークが、宛先のリモートIPｖ4サービスにルーティングします。この場合、このDS Lite有効ネットワークから発生したIPｖ4 SMTPトラフィックはすべて、シングル共有外部アドレスからそのサービスプロバイダのLSNデバイスに到着したようにみえます。

図 1
Dual Stack Liteはユーザーと大規模NAT間のIPv6上のIPv4パケットのトンネリング

そのようなトラフィックを受け取るオフネットワークSMTPサーバは、トラフィックの実際のソースを正確に確認することはできず、その代り、LSNの外部IPｖ4アドレス上のレピュテ―ションを追跡します。リモートSMTPサーバにはNATデバイスのようにIPアドレスを検出する信頼できる機構がないため、IPアドレスがシングルIPｖ4ホストを表すものと誤認することがあります。botアクティビティが、LSNから発信スパムトラフィックにつながるサービスプロバイダネットワーク内に十分ある場合、LSNの外部IPｖ4アドレスは、リモートMTAにスロットルまたはブロックされる確率が高くなります。このLSNシングルIPアドレスを通過する後ろにある悪質botは同じLSN外部インターフェースを使用してこのトラフィックに偶然ルーティングしてくる無関係な顧客の信用に害が及ぶことになり、特定リモートサービスへのサービスを拒否することになります。この状況は、今日トラフィックが大容量のNATデバイスを通過するモバイルユーザーがすでに経験しています。ここでは、1基の動作が悪質なモバイルデバイスによって、他の多くの正当なモバイルユーザーのリモートサービスへのアクセスが影響を受けることになります。

さらに、不正アクセス対応が万が一、法執行に及ぶ場合、元のIPアドレスの不明化が、各種変換およびトンネリングレイヤを明確にして不正の本当のソースを取得する必要があるため、調査が実際、かなり複雑になります。この結果、それらを通過するトラフィックについて記録することが必要になるので、これらのレイヤを運用するエージェントには負担がかかります。そのようなロギングをしないで、不正アクセスを追跡してソースを確認することはほとんど不可能になりました。サービスプロバイダがLSNレイヤを通過するデータにどのようにロギングするかを説明した一般的な初期のベストプラクティス(2)は、まだ実行は断片的であるものに、IETF内で現在、議論が行われています。

増分CGNの潜在的な問題

インクレメンタルCGNは、機能はDS Liteに似ていますが、各CFEデバイスがIPｖ6ではなくIPv4を使用して、サービスプロバイダネットワーク上で通信する点は異なります。顧客ネットワーク内のコンピュータシステムから発生したIPｖ6トラフィックはどれも、IPｖ4パケットないでカプセル化され、LSNデバイスに転送されて、最終宛先に配信される前にカプセルが解除されます。顧客ネットワーク内のコンピュータシステムから発生したIPｖ4トラフィックについては、トラフィックはLSNデバイスに方向づけられ、NAT44変換され、接続元のソースアドレスが効果的に隠されます。リモートSMTPサーバのクロスNAT可視化のあるDS Liteに関する同じ課題がここでも適用され、リモートMTAがポリシーを有効にして、巻き添え被害を及ぼさずに、別のオペレータのLSNデバイス後ろで発生したトラフィックからの不正アクセスを効果的に制限できます。

6to4の潜在的な問題

今日インターネット上でパブリックルーティングするダイナミックまたはスタティックIPｖ6アドレスが／48 IPｖ6ネットワーク範囲を自動請求できる6to4等の別のソリューションを考えると、今日のIPｖ4メッセージングエコシステムの雪靴(3)問題が、個別のIPアドレスのレピュテ―ションを追跡するシステムにとってかなり大きな問題になります。6to4が有効なネットワークはすべて、現在、botがその／48以内の多くの独自IPアドレスから大量のスパムを送信する可能性があります。

6rdの潜在的な問題

6to4ゲートウェイがスタティック定義したネットワークプレフィックスにより特定しやすい一方、6rd（rapid deployument）ゲートウェイはそうではありません。6rdサービスを提供するネットワークオペレータは、IPｖ6ネットワークプレフィックスをこのゲートウェイに割り当てることができます。その結果、リモートMTAが、シングル6rdゲートウェイを通過するときにそのゲートウェイから発生ｓｈちあトラフィックを簡単に特定するのを防止します。ターゲットMTAが、この情報が公開アクセス可能な方法でパブリッシュされていないので、レピュテ―ションをアグレゲートするために正しいネットワークプレフィックス長を理解する機構はありません。

ドメイン評価はIP評価の直接代替物ではない

ほとんどの大型メッセージングシステムが。IPレピュテ―ションサービスリスティングまたはローカル動作履歴データにより今日、IPｖ4接続すべてのうち80５～95％拒否することを考えると、接続レベルのMTAポリシーは、比較的低リソースコストでもっとも酷い大量の送信者からかなり保護できます。対象となる送信者に対してメッセージを認証するのに必要なデジタル署名がメッセージヘッダ内に含まれるDKIM等の認証ソリューションを活用するドメインレピュテ―ションテクノロジーには、送信者の認証ができる前に、SMTPプロトコルのデータフェーズからMTAで各メッセージを受け取ることが必要です。その後、DNSルックアップ、署名済みメッセージ変だおよび本文欄に対するDKIM署名の暗号ハッシイング等を含む、DKIMヘッダの追加分析が必要になります。この認証プロセスの実施には、かなりの数のMTAおよびネットワークリソースが接続を承認し、メッセージを受け取る必要があります。一般的に重いメッセージの承認機能（LDAPに対するRCPT TOの評価、ASおよびAVエンジンの実行等）のいくつかがDKIM情報を評価するまで遅延する場合でも、このプロセスは、IPレピュテ―ションに依存して早期の接続許可／拒否決定をするよりも、MTAに対する負荷が増えます。この結果、メッセージングプラットフォームのインフラコストがかさむことになります。

送信者の認証では、ドメインと関連した署名MTAがメッセージを取り扱っていること、およびローカルMTAで受け取った、その結果発生したメッセージが記載の署名の評価に合格していることを確認します。認証済み送信ドメインに基づくドメインレピュテ―ションは追跡するデータに役立ち、IPアドレスベースのレピュテ―ションソリューションの代わりにIPｖ6が有効なメールサーバ上のドメインレピュテ―ションだけに依存することは、不正アクセストラフィックの拡大に対応するためにさらに多くのMTAおよびネットワーク空間が必要になります（2010年最後の異常な数ヵ月は除く）。

ドメインレピュテ―ションおよびDKIMは不正アクセス報告、各種正当なマーケティング目的の送信者の送信動作のアカウンティング、フィッシング防止（ADSPおよびその継承者とあわせて）、およびメッセージのソースの追加保障が必要なソースからのトラフィックの取り扱いに便利です。MTAシステムを接続レベルで迷惑送信者から保護するには、他のソリューションが必要です。

現在のIPv4 MTAポリシーを今後のネットワークに適用する試み

現在のIPｖ4展開では、IPレピュテ―ションに基づく接続管理は、防衛の第一線であり、膨大な量のスパムおよびその他悪質トラフィックからメッセージングインフラを保護するもっともリソース効果的な方法です。このアプローチによって、オペレータは、接続拒否、帯域形成、接続づじせい制限、（再）接続率制限、およびRCPT TO制限等、各自のインフラに対してさまざまなCoSを展開できます。メッセージングシステムオペレータは着信環境をIPｖ6 SMTP接続に解放することを考えるため、ネットワーク空間がさらに膨大になることで、考える課題もさらに増えます。提案の中には、承認された送信者のみIPｖ6上で着信MTAに接続できる、ホワイトリストまたは「許可」リストを推奨するものがあります。シングルIPアドレスブラックリスティングを継続することでメッセージング脅威に十分対応できるとするものもいます。以下のセクションはこれらの案について説明しています。

業界の行動を求める声

IPｖ6が原因で発生可能性のある脅威は、IPｖ4で使用した既存のメッセージング不正防止技術の考課に陰りを投げかけています。新たなベストプラクティスおよび技術を確立および準拠することで、これらの拡大攻撃ベクトルを和らげることが必要です。業界が参加することなしで、SMTPトランザクション内で早期に既知の不良ソースの制限または拒否を実現し、所定のIPを個別にレート制限し、または所定のIPから配信される接続を制限することは容易ではないでしょう。その解決には、CoSブロック割付の標準化またはパブリッシュが必要となるでしょう。

IPｖ6は、IETF (Internet Engineering Task Force) および APNIC (Asia Pacific Network Information Center) から NANOG (North American Network Operators Group)、MAAWG (Messaging Anti-Abuse Working Group)まで業界フォーラムの多くで、議論のテーマとなってきました。今日まで、割付および割当の議論がAPNIC会合で行われてきましたが、その議論ではIPｖ6空間の割当および割付が中心テーマでした。NANOGでは、運用展開の話題が中心となり、MAAWGでは、業界自体がメッセージングセキュリティに焦点を絞ってきましたため、メッセージングインフラでのIPｖ6の展開が議論されました。しかし、IPｖ6展開によるメッセージングインフラへの実際の脅威を中心にする必要があります。

IPアドレスレベルポリシーを取り除かれた大容量のIPｖ4ベースのメッセージング環境に対する影響を考えてみてください。ネットワーク接続は、すべてのネットワークリソースを消費しない場合は、重負担なります。すべてのメッセージは分類前に承認が必要です、。クラス・オブ・サービス属性はメッセージが承認された後ではじめて適用されます。つまり、既存のメッセージングインフラは破損ギリギリの負荷がかかり、配信が行き詰まり、顧客満足も得られにくくなります。

メッセージングセキュリティのコミュニティにIPｖ6が登場したことがまさしくこの課題を表しています。IPｖ6のレピュテ―ションシステムは、アグレゲートレベルまで上げる必要があります。これにはクラス・オブ・サービスブロック割付に対する標準化または一貫性を引き出す業界内合意また最低でも、IPｖ6範囲ごとにアグレゲ－ションブロックサイズの包括的で信頼できるパブリッシュが必要です。これで接続時間に適用できるCIDRレベルのレピュテ―ションが促され、メッセージ配信トランザクションの一部からのメッセージ承認は不要になります。

ヨーロッパでは、例えば、 RIPE が最小 /32の IPv6 のアロケーション(7)をローカルインターネットレジストリ (LIR) に割り当て、最小 /64 のサブアロケーション(8) を単一のサブネットを要求する個人および要求の正当化に必要な /48 以上を要求する任意の実体に割り当てています。IPv4 /24 CIDR サブネット (もしくはそれ以上) からのスノーシュー攻撃が日常的であるメッセージングセクターにおいて特に不正使用に対する考慮はほとんど行われてきませんでしたが、スノーシュー攻撃がIPv4 スペース全体 (IPv6 /96 CIDR) から由来する場合にこれがコントロールを超えて爆発する可能性について業界レベルで考慮し対処する必要があります。

IPv6 は APNIC、NONOG、および MAAWG などの業界フォーラムでは議論されてきましたが、そのどれもメッセージング不正使用のため IPv6 を意味づけすることに注目したものではありませんでした。最良の実践を開発し適用することにおける業界のコラボレーションがなければ、一貫して効果的なポリシーは不可能です。

現在、なんらかの有用な情報を含む IPv6 用の DNSBL は存在しません。DNSBL は IPv4 のメールインフラ内のセキュリティポリシーの主要な部分を形成しています。IPv6 アドレスおよび評価の包括リストの管理は集約されることなく、データの多大な増加により支持されなくなっています。第二に、すかすかの DNSBL およびその結果生じる IPv6 アドレスに接続するためのデフォルトのポリシーについて考えてみてください。最も攻撃的な CoS ならその接続を伝ってメッセージを送ることを可能にするでしょう。標準的なアロケーションブロックのサイズであれば単一のアロケーション内由来のインフラへの多くの接続を開くことが可能になり、そしてそれでもなおどの CoS ポリシーもパスするでしょう。

ある形態の公開され、信頼できる集約標準がなければ、IPv6 アドレスが /64 よりも大きなアロケーションに属しているのかどうか決定する方法がないため、特定の CIDR ブロックに接続制限を適用する合理的な方法はありません。未知の接続しようとする IP アドレスの評価が最も近い既知の隣接と連関しているという最近傍法による評価の割り当てに関する議論は行われてきましたが、このポリシーは基本的に推測作業であり、不適当な評価につながり、その結果生じるサービスの影響はサポートコストを増大させるでしょう。IPv6 アドレスへの接続が、評価が適用可能な適切なアロケーション範囲に量子化可能になるようにこの情報を提供できるよう既存のシステムを拡張すべきです。

オペレーターが IPv6 を展開しようと急ぐにつれ、IPv6 のインフラ上の全てのサービスをサポートしようとする自然な圧力が生じます。現在のトレンドはネットワーク内のエンドポイントに二重重ねの意味づけを展開し IPv4/6 間の相互運用性を確実にすることです。このことは当分は全てのエンドポイントが IPv4 機能を持つことを意味します。IPv6 上でメッセージングセキュリティポリシーの適切な計画やテストをすることなくメッセージングサービスの展開を急ぐことは、キャリヤーネットワークを不必要なリスクにさらすことになります。運営上の展開問題に焦点を当てるよりも、業界はメッセージングに対する潜在的な脅威を認識し、その知識に基づいた IPv6 の展開を注意深く行う必要が喫緊の課題として存在します。業界が標準を定義するのに長く待てば待つほど、ソリューションがそれだけ難しいものになるでしょう。

結論

本論文はメッセージングにおける IPv6 移行の必要性、既存のセキュリティポリシーの試練、および現在の移行テクノロジーによって意味づけられたこれらのポリシーに対する制限について考察してきました。私たちは IPv6 環境下におけるメッセージングの初期のロールアウトおよび IPv6 ワールドにおけるメッセージング業界のアラインメントに関する提言を行ってきました。また、IPv6 ワールドにおけるメッセージングのための最良の実践に関する業界アラインメントのための提言と共に、高水準の脅威解析を提示してきました。

IPv6 を展開する必要性が不可避になるにつれ、全てのサービスを IPv6 へ移行させようとする大きな圧力が生じています。メッセージングのプロフェッショナルはその内部メッセージングシステムを侵害しない合理的な IPv6 移行計画を開発するための IPv6 のセキュリティ上の意味合いについて考えなければなりません。メッセージングのプロフェッショナルはまた、自身の内部メッセージングシステムを侵害することなく必要な機能性を提供するアップグレードのためのロールアウト計画を確立することにより IPv6 の移行を進める必要があります。全てのメッセージングのロールアウト計画はテクノロジーの選択と共に脅威表面の解析を含むべきです。各ポリシーの実行可能性を IPv6のコンテキストの中で調べることができるように、既存のメッセージングセキュリティポリシーの IPv6 インフラへのマッピングは計画プロセスの初期のステップである必要があります。

しかしながら、私たちが IPv4 ネットワークに現在存在するものに対する防御と同様のレベルを可能にしようとすれば、メッセージングインフラにおいて外部の IPv6 ネットワークへメッセージングサービスを導入することはさらなるインターネットの進化を必要とするでしょう。このことは遠隔ネットワークのデフォルトの IPv6 プレフィクスアロケーションサイズを確認する機能を含みます。

メッセージングのプロフェッショナルは内部メッセージングシステムを侵害しない合理的な移行計画を開発するために IPv6 に対するセキュリティ上の意味づけを考える必要があります。さらに、その意味付けはそのインフラ上の任意の移行プランの影響の規模を計る能力がある必要があります。これは IPv6への移行後に同じサービスが提供できるか調べるために IPv4 で利用可能なセキュリティシステムの徹底的な評価を含んでいるべきです。 IPv6下では同様の防御を与えられないエレメントに関しては、環境が十分に進化するまで IPv4 が好ましいインターフェースを維持すべきです。これは計画プロセスにおける決定的で重要な第一歩です。

本論文はメッセージングセキュリティ業界に対してアクションを要求するものです。初期および最良の実践および推奨される最良の実践の採用に関するコンセンサスがなければ、世界中のオペレーターはメッセージングを妨害したりあるいはメッセージングインフラのセキュリティを侵害する個別のポリシーを採用するでしょう。多くの業界団体が過去数年において IPv6 のセッションを開催してきましたが、教育から実践的なセキュリティポリシーの議論へと焦点のシフトが必要です。MAAWG がICANNとの関連でメッセージングセキュリティの勧告を行うべき最良の位置にいると思われます。

IPv6 のメッセージングインフラを展開することは今後数年においてどのオペレーターにも要求されることです。IPv6 に基づくメッセージングインフラを運用する現在の水準の知識では、主要な試練は任意の IPv6 展開決定のセキュリティリスクの意味づけを正確に調べることです。これはセキュリティ解析の一次的な方法が IPv4 メッセージングの脅威の経験を IPv6 インフラに補外することに基づいている環境ではますます複雑になります。しかるがゆえに、メッセージングにおいてIPv6 によって提起された脅威展望の制限つきの視界の現実的な理解が必要ですが、この視界は各オペレーターがその IPv6 展開計画を調べる際に使用されるものです。

参考文献:

1. Postel, J., Internet Protocol, RFC 791, September 1981
2. Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., Lear, E., Address Allocation for Private Internets, RFC 1918, February 1996
3. Crawford, M., Transmission of IPv6 Packets over Ethernet Networks, RFC 2464, December 1998
4. Carpenter, B., Moore, K., Connection of IPv6 Domains via IPv4 Clouds, RFC 3056, February 2001
5. Nordmark, E., Gilligan, R., Basic Transition Mechanisms for IPv6 Hosts and Routers, RFC 4212, October 2005
6. Hinden, R., Deering, S., IP Version 6 Addressing Architecture, RFC 4291, February 2006
7. Huitema, C., Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs), RFC 4380, February 2006
8. Lyon, J., Wong, M., Sender ID: Authenticating E-Mail, RFC 4406, April 2006
9. Wong, M., Schlitt, W., Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1, RFC 4408, April 2006
10. Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., Thomas, M., DomainKeys Identified Mail (DKIM) Signatures, RFC 4871, May 2007
11. Narten,T.,Draves,R.,Krishnan,S.,Privacy Extensions for Stateless Address Auto-configuration in IPv6, RFC 4941, September 2007
12. Siemborski, R., Melnikov, A., SMTP Service Extension for Authentication, RFC 4954, July 2007
13. Klensin, J., Simple Mail Transfer Protocol, RFC 5321, October 2008.
14. Despres, R., IPv6 Rapid Deployment on IPv4 Infrastructures (6rd), RFC 5569, January 2010
15. Allman, E., Allman, J., Delany, M., Levine, J., DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP), RFC 5617, August 2009 Narten, T., Huston, G., Roberts, L., IPv6 Address Assignment to End Sites, RFC 6177, March 2011
16. Durand, A., Droms, R., Woodyatt, J., Lee, Y., Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion, draft-ietf-softwire-dual-stack-lite-07, March 2011
17. Jiang, S., Guo, D., Carpenter, B., An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition, draft-ietf-v6ops-incremental-cgn-03, January 2011
18. Levine, J., An efficient method to publish ranges of IP addresses in the DNS, draft-levine-iprangepub-01, December 2010
19. Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., Ashida, H., Common requirements for IP address sharing schemes, draft-ietf-behave-lsn-requirements-01, March 2011
20. St Sauver, J., MAAWG IPv6 Session, PDF, February 2009
21. Hogewoning, M., Van Mook, R., Value of the "status:" and "assignment-size:" attributes in INET6NUM objects for sub-assigned PA space, ripe-513, February 2011
22. Durand, A., Gashinsky, I., Lee, D., Sheppard, S., Logging recommendations for Internet facing servers, draft-ietf-intarea-server-logging-recommendations-03, February 2011
23. Doyle, J., Understanding Carrier Grade NAT, Network World Blog, September 2009
24. Doyle, J., Understanding Dual-Stack Lite, Network World Blog, October 2009

(454KB)ホワイトペーパーをダウンロードする トップに戻る