RFC 7607: AS 0処理の規格化

要旨

本文書はRFC 4271を更新し、BGP UPDATEメッセージ内のボーダー・ゲートウェイ・プロトコル (BGP) OPEN、AS_PATH、AS4_PATH、AGGREGATOR、およびAS4_AGGREGATOR属性で、自律システム(AS) 0の使用を禁止する。

本文書の位置付け

本文書は、インターネット標準化過程の文書である。

この文書はInternet Engineering Task Force (IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。公開レビューを受けており、Internet Engineering Steering Group (IESG)によって公開が承認されている。インターネット標準の詳細については、RFC 5741のセクション 2を参照のこと。

本文書の現在のステータス、正誤表、および文書に対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc7607 で入手できる。

著作権表示

Copyright (c) 2015 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。

本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている簡易BSDライセンスのテキストを含まなければならず、簡易BSDライセンスに記載されているように保証なしで提供する。

1. はじめに

自律システム(AS) 0は、IANAの自律システム番号レジストリに「Reserved - May be use [sic] to identify non-routed networks」(予約済み - ルーティングされないネットワークを識別するために使用されることがある) ([IANA.AS_Numbers])と登録されている。

[RFC6491]では、経路オリジン認可(ROA)にAS 0を使用して、プレフィックスとそのすべてのMore Specificプレフィックスを、ルーティング・コンテキストで使用しないものとしてマークするために使用することを規定している。これにより、リソース保有者は、AS 0を唯一のオリジンとするROAを発行することで、プレフィックス(およびMore Specifics)をルーティングすべきではないと示すことができる。このシグナルに応答するには、BGP実装がAS 0を含む経路を受け入れたり、伝播しないことが必要である。

⚠️ AS0 ROA

RFC 6483のセクション4に、AS 0 ROAのことが書かれている。

4. ルーティング発信の否認

ROAは、プレフィックス保有者がASに対して、このプレフィックスに対する経路をドメイン間ルーティング・システムで発信する権限を与えることを示す肯定的な証明である。プレフィックス保有者は、ASがアドレス・プレフィックスの経路を発信する権限を一切付与しない認可(authorization)を構成することが可能である。これはROAを使って実現され、そのROAの対象ASはいかなるルーティング・コンテキストでも使用してはならない。具体的には、AS 0がIANAによって予約されており、ルーティングされないネットワークを識別するために使用できる[IANA-AS]。

AS 0を持つROA (AS 0 ROA)は、ROAに記述されたプレフィックスやMore Specificプレフィックスが、ルーティング・コンテキストで使用すべきではないことを、プレフィックス保有者が証明するものである。

セクション2で説明した経路検証手順は、他の有効なROAが単独で使用された場合に、検証結果が「無効」であっても、アドレス・プレフィックスとオリジンASに一致するROAがあれば、「有効」という結果を提供する。その結果、AS 0のROAは、ルーティング可能なASを対象とする他のどのROAよりも相対的な優先順位が低くなる。これにより、プレフィックス保有者はAS 0のROAを使用して、プレフィックスと等しいか、More Specificな経路を「無効」とみなすデフォルト条件を宣言することができると同時に、他の同時に発行されたROAが、More Specificなプレフィックスに対して有効なオリジン認可を記述することもできる。

慣例では、AS 0 ROAはIPv4アドレスのmaxLength値として32を、IPv6アドレスのmaxLength 値として128を持つべきである。しかし、経路検証の観点からは、どのような有効なmaxLength値でも、maxLength要素がROAから省略されても、同じ結果が得られる。

また、慣例として、AS 0 ROAは、任意のアドレス・プレフィックスに対して発行される唯一のROAであるべきである。繰り返しになるが、これは厳密な要件ではない。AS 0 ROAは、異なるAS値を持つROAと共存する可能性はあるが、そのような場合であっても、AS 0 ROAの有無は、経路の有効状態を何ら変更しない。

• https://academy.apnic.net/wp-content/uploads/2021/04/AS0-Demystified.pdf

AS 0を禁止するという明確な記述は、どのBGP仕様にも書かれていなかった。この文書は、この欠落を修正するもので、最も重要なことはAS_PATHについてである。[RFC4271]のセクション6.2および6.3で規定されているエラー処理手順を更新し、AS 0が存在する場合の動作を規定する。

少なくとも2つの実装がAS 0を含む経路を破棄しており、本文書はこの動作を規定する。

1.1. 要件の表記

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、[RFC2119]の記述にしたがって解釈される。

2. 動作

BGPスピーカーは、AS_PATH、AS4_PATH、AGGREGATOR、AS4_AGGREGATOR属性のAS番号が0の経路を発信または伝播してはならない(MUST NOT)。

AS_PATHまたはAGGREGATOR属性にゼロのAS番号を含むUPDATEメッセージは、不正な形式とみなし、[RFC7606]で規定されている手順で処理しなければならない(MUST)。

AS4_PATHまたはAS4_AGGREGATOR属性にゼロのAS番号を含むUPDATEメッセージは、不正な形式とみなし、[RFC6793]で規定されている手順で処理しなければならない(MUST)。

BGPスピーカーがOPENメッセージでピアASとして0を受け取った場合、接続を中止してエラーコード「OPEN Message Error」とサブコード「Bad Peer AS」を含んだ通知を送信しなければならない([RFC4271]のセクション6を参照)。ルータはAS 0であると主張して接続を開始してはならない(MUST NOT)。

自律システム番号を運ぶ将来のプロトコル拡張の開発者は、AS 0が予約済みであることを念頭に置き、AS 0の処理方法について明確な指示を提供することが推奨される。

3. IANA に関する考慮事項

IANAは、AS 0のエントリが明確に「予約済み」(Reserved)となるよう、「16-bit Autonomous System Numbers」のレジストリを更新する。

4. セキュリティに関する考慮事項

リソース公開鍵基盤(RPKI)のリソース保有者は、AS 0が経路の唯一有効なオリジンであることを示すROAを発行できるようにすることで、特定のアドレスリソースが使用されていないことを表明することかできる。経路内でAS 0を認識するすべての実装がその経路を無視することで、悪意のある関係者がリソースをハイジャックしようとして、AS 0を含む経路をアナウンスすることを防ぐ。

さらに、本文書では、AS 0を含むAS_PATH(またはAS4_PATH)を受信した場合の動作を標準化することで、動作をより明確に定義する。

5. 参考文献

5.1. 引用規格

[IANA.AS_Numbers] IANA, "Autonomous System (AS) Numbers", <http://www.iana.org/assignments/as-numbers>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.

[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, <http://www.rfc-editor.org/info/rfc6793>.

[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, July 2015, <http://www.rfc-editor.org/info/rfc7606>.

5.2. 参考規格

[RFC6491] Manderson, T., Vegoda, L., and S. Kent, "Resource Public Key Infrastructure (RPKI) Objects Issued by IANA", RFC 6491, DOI 10.17487/RFC6491, February 2012, <http://www.rfc-editor.org/info/rfc6491>.

謝辞

Elwyn Davies、Enke Chen、Brian Dickson、Bruno Decraene、Robert Raszuk、Jakob Heitz、Danny McPherson、Chris Morrow、iLya、John Scudder、Jeff Tantsura、Daniel Pinsburg、Susan Haresに感謝の意を表す。見逃してしまった方々にはお詫びを申し上げる。意図的なものではない。

著者のアドレス

ウォーレン・クマリ
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
アメリカ
メール: [e-mail]

ランディ・ブッシュ
インターネット・イニシアチブ・ジャパン
5147 Crystal Springs
Bainbridge Island, WA 98110
アメリカ
メール: [e-mail]

ヘザー・シラー
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
アメリカ
メール: [e-mail]

ケユル・パテル
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
アメリカ
メール: [e-mail]

更新履歴

• 2024.1.25
• 2024.1.30