要約

  • ASN 0はBGPのピア識別子、AS_PATH、AS4_PATH、AGGREGATOR、AS4_AGGREGATORでは使用できない。一方、ORIGIN属性の値0はIGPを表す有効な符号である。
  • RFC 7607は出現場所ごとに処置を分ける。OPENでAS 0を名乗る接続は中止し、AS_PATHを含むUPDATEの経路はwithdrawとして扱い、集約・4オクテット移行属性では不正な属性を捨てて残りの処理を続ける。

夜間変更の後、NOCに三つの通知が並んだ。一つ目は、ピアがOPENを交換した直後にBad Peer ASで切断されたという通知。二つ目は、セッションがEstablishedのまま、特定プレフィックスだけが消えたという通知。三つ目は、経路が残ったままAGGREGATOR属性が失われたという通知である。

上位の集約画面は、三件を「BGPでAS0を検出」とまとめた。

この要約では復旧手順を決められない。RFC 7607が禁じる値は同じでも、値を運んだプロトコルオブジェクトが異なるからだ。OPENのpeer ASがゼロなら、成立しようとした隣接関係が無効である。AS_PATH内のゼロなら、そのUPDATEが運ぶ到達性を信頼できない。AGGREGATORや4オクテット移行属性なら、当該属性を除去して残りを評価する手順が定められている。

強い処置を一律に選ぶことは安全性ではない。必要以上のセッションリセットは正常経路まで落とす。必要なwithdrawを属性破棄で済ませれば、根拠のない経路を残す。安全性は、ゼロの位置を失わず、規定された最小単位を拒み、その結果をRIBの各段階で証明することにある。

AS 0は「未設定」を意味しない

IANAの現行AS番号レジストリでは0がReservedとされ、RFC 7607が参照されている。特殊用途AS番号レジストリを見ると、AS_TRANS 23456、文書用範囲、プライベート用途範囲、末尾の予約番号などが別々の理由で管理されている。

特殊用途という分類は、用途を交換できるという意味ではない。AS_TRANSは4オクテットAS番号への移行に意味を持つ。プライベートASNは閉じた運用範囲で使える。AS 0は、匿名のネットワーク、番号決定前の仮ピア、あるいは「値なし」の代替ではない。

ところが自動化は、欠損値を整数に変換する際にゼロを作りやすい。テンプレート変数が空、データベース列がNULL不可、移行先ASNがまだ登録されていない、といった事情がBGP上の主張へ変換される。管理システムにとっての初期値が、プロトコルにとっての禁止された識別子になる。

生成段階で止めることは重要である。Juniperの4-byte AS番号に関する文書は、記載された製品範囲で0を含む制限番号の設定がcommitに失敗すると説明する。ただし、自装置が生成しないことと、隣接装置から受け取らないことは別問題だ。受信parserとエラー処理は依然として必要である。

OPENにある0はピアを成立させない

RFC 4271のOPENにはMy Autonomous Systemフィールドがある。RFC 7607は、ここでゼロを受信したspeakerに接続の中止と、OPEN Message Error / Bad Peer ASのNOTIFICATION送信を要求する。自らAS 0を名乗って接続を開始することも禁止される。

この場合の障害単位は接続である。BGPセッションは成立していないため、そのセッション内の一部経路だけを温存する話ではない。記録すべきものは、受信OPEN、送信NOTIFICATION、TCPの方向、両端、時刻、再接続回数、生成元設定である。

暫定的にpeer-AS検査を緩める対応は、正当な例外を作らない。AS 0には例外を許可できる保有者が存在しない。買収や移行で複数の実在ASNを扱うなら、local-as等の仕組みを実在値で設計し、OPENとAS_PATHへの影響を検証すべきである。

AS_PATHにある0は経路を撤回扱いにする

AS_PATHにASN 0を含むUPDATEはRFC 7607によりmalformedとされ、処理はRFC 7606へ渡される。malformed AS_PATHの処置はtreat-as-withdrawである。そのUPDATEに含まれる経路をwithdrawされたものとしてAdj-RIB-Inから除去する。

セッション自体は維持できる。これにより、同じピアから受け取った無関係の有効経路まで一斉に失うことを避ける。過去の一般的なセッションリセットは、一つの不正属性の影響を多数のプレフィックスへ拡大し得た。RFC 7606の狙いは、正当性を維持できる範囲で影響を局所化することにある。

局所化は値の修正を意味しない。受信側がAS_PATHから0だけを削除したり、想像したASNに置き換えたりすれば、隣接装置が実際に広告していない経路履歴を作る。正しい回復は、送信元が防御可能なAS_PATHを新たに広告するまで当該経路を拒むことである。

境界ポリシーは補助になる。FRRoutingのBGP文書には、bogon ASN用のAS-path access-listで_0_をmatchする例がある。このルールはAS_PATHの追加防御と計数に使えるが、OPENやAGGREGATOR、AS4_PATH、AS4_AGGREGATORの処理までは証明しない。

AGGREGATORにある0は属性を失わせる

AGGREGATORは、集約経路を作ったASとBGP speakerを記録する。そこにASN 0がある場合もRFC 7607違反だが、RFC 7606がmalformed AGGREGATORに割り当てる処置はattribute discardである。属性を捨て、UPDATEの処理を続ける。

経路は他の検査に通れば残り得る。従って、「AS 0を含むUPDATEは常にwithdraw」という運用説明は誤りである。ただし、経路が残ることは送信元の正しさを意味しない。集約の来歴が失われ、禁止値を生成した欠陥は残っている。フィールドと処置をログし、元の生成経路を修正する必要がある。

RFC 6793は、4オクテットASN対応の異なるspeaker間で情報を保持するAS4_PATHとAS4_AGGREGATORを定める。RFC 7607は両属性のAS 0をmalformedとし、RFC 6793の手順に従わせる。該当する移行コンテキストでは属性を捨て、ローカルに記録し、UPDATE処理を続ける。

この判断にはOPENの能力情報が欠かせない。双方が4オクテット対応のNEW speakerなら、そもそもAS4属性を相互に運ぶべきではない。受信UPDATEだけを保存してOPENを失えば、同じ属性が正当な移行情報だったのか、存在自体が異常だったのかを説明できない。

ORIGIN 0を正しく扱えるか

RFC 4271のORIGIN属性では、値0がIGP、1がEGP、2がINCOMPLETEを表す。ORIGIN 0は正常であり、origin ASNが0という意味ではない。

これは監視設計の良い試験になる。文字列や汎用originフィールドだけを索引にすると、ORIGINコード、AS_PATHから導くorigin ASN、デフォルトルート、ゼロメトリックが混ざる。誤検知が増えればルールは抑制され、本当に禁止されたAS_PATHも見逃しやすくなる。

回帰試験には、有効なORIGIN 0を一件と、五つの禁止位置にASN 0を置いた各ケースを用意すべきだ。監視系は有効ケースを誤って遮断せず、禁止ケースではフィールド名と想定処置を別々に示さなければならない。

最低限の保存項目は、メッセージ種別、属性type code、無損失の値、方向、peer、AFI/SAFI、能力、実装バージョン、時刻である。人向けの「AS0検出」というラベルは入口に過ぎず、原記録の代わりにはならない。

AS 0 ROAは別の権限である

RFC 6482はROAを、一つのasIDとプレフィックス群を持つ署名オブジェクトとして定義する。RFC 6483では、プレフィックス保有者がAS 0 ROAを発行し、そのプレフィックスとmore-specificをルーティングに使うべきでないと表明できる。

これはAS 0に経路生成権を与える仕組みではない。RFC 6907が示す通り、正当なBGP経路はorigin ASN 0を持てず、AS 0 ROAとmatchする経路も存在しない。実在ASNからの経路は、候補ROAが存在しても実際のoriginと長さにmatchするROAがなければInvalidとなる。

一方、RFC 6483はAS 0 ROAと実在ASNのROAの併存を認める。実在ASN側のROAがプレフィックス、maxLength、originにmatchすれば、その経路はValidである。AS 0 ROAは一致する正の許可を上書きする拒否票ではない。

時間軸も別である。BGPメッセージはセッション上で即時に処理される。ROAは公開点、証明書検証、収集、relying partyのcacheを経る。BGP広告を直した時刻とRPKI検証結果が変わる時刻は一致しない。調査記録は両方を関連付けても、統合してはならない。

入力、選択、出力を分けて証明する

RFC 7854のBMPは、受信UPDATE、peer状態、pre-/post-policy Adj-RIB-Inを観測できる。pre-policyは隣接装置が何を送ったかを示し、post-policyはローカル処理後に何が残ったかを示す。片方だけでは、送信元の違反と受信側の封じ込めを分離できない。

RFC 9069はLoc-RIB監視を追加する。そこではDecision Processが選んだ経路を確認できる。ただし、Loc-RIBはFIBやパケット到達性ではない。サービス影響を主張するなら、転送表と実トラフィックの証拠を追加する。

RFC 8671はpre-/post-policy Adj-RIB-OutをBMPに加える。「AS 0を伝播しない」という要件を、重要な各出力境界で検査できる。RFC 7454は入出力フィルタとAS-path管理の一般的な運用規律を示し、RFC 7607はこの値に固有の処置を決める。

一件のケースファイルは、原メッセージ、peerと能力、実際のエラー処置、pre/post-policy差分、Loc-RIB、必要なFIB・パケット、重要なAdj-RIB-Out、生成元設定、修正版メッセージを順に結ぶべきだ。アラートが消えただけでは、どの段階が直ったか分からない。

情報源