9.2.3 Comments for IPsec Support (IPsec サポートに関するコメント)

9.2.3 Comments for IPsec Support (IPsec サポートに関するコメント)

IPsec ワーキンググループでのレビュー中に、本文書の 2 つの領域について多くのコメントが寄せられました。本セクションでは、これらのコメントについて説明し、提案された変更が採用されなかった理由を説明します。

最初のコメントは、ノード単位の構成が SA 単位の構成よりも実装が容易であることを示唆しました。慎重に検討した結果、最初はノード単位の構成を推奨していましたが、それはもはや良いアイデアではなくなりました。懸念は、IPsec で ECN 認識が段階的に展開されるにつれて、多くの ECN 認識 IPsec 実装が、ECN 認識および ECN 非認識 IPsec トンネルエンドポイントの混在と通信することになるということです。ノード単位の構成を持つこのような環境では、唯一の合理的な対応は、すべての IPsec トンネルで ECN の使用を禁止することであり、これは望ましい結果ではありません。

2 番目の領域では、数人のレビュアーが SA ネゴシエーションが複雑であり、それに追加することは非自明であると指摘しました。あるレビュアーは、トンネル設定後の可能な代替案として ICMP を使用することを提案しました。本文書での SA ネゴシエーションへの追加はオプションであり、オプションのままです。実装者はそれを無視することが自由です。著者は、それが提供する保証が多くの場合に有用である可能性があると考えています。実際には、実装されない場合、標準プロセスの後の段階で削除できます。トンネル設定後に ECN をネゴシエートするために ICMP を拡張することは、SA 属性ネゴシエーションを拡張するよりも複雑です。一部のトンネルはトンネル出口エンドポイントにアドレス指定されたトラフィックを許可しないため、ICMP パケットは他の場所にアドレス指定され、出口エンドポイントによってスキャンされ、そこまたは実際の宛先で破棄される必要があります。さらに、ICMP 配信は信頼できないため、ICMP パケットが破棄される可能性があり、別の ack/再送メカニズムを発明する必要があります。既存の SA ネゴシエーションメカニズムのオプション拡張を単純に指定する方が良いように思われます。