「BGP経路情報をDNSで確認」という提案
IETFのGROW(Global Routing Operations)ワーキンググループで「DNSSECを使っているDNSでの逆引きに拡張を追加してBGP経路ハイジャック対策しようよ！」という提案が提出されました。 考え方としては、「DNSSECで完全性を確保したうえで経路情報認証に使えば、BGPでの経路ハイジャックを防げる」というものです。 具体的には、RLOC RRType(Route Lock Resource Record Type)とSRO RRType (Secure Route Origin Resource Record Type)を追加するという提案です。
このドラフトには、IETF重鎮の一人であるLixia Zhang教授や、ルートDNSサーバを2系統運用しているVerisign社の社員が含まれています。
このドラフトが提出されてから、いくつかの返信メールが流れていますが、中には「1999年にSIDRワーキンググループで提案したけど却下されてる。この提案は死んでるよ。」と1999年に発表した本人から指摘されたりもしています(参考1,参考2,参考3)。 ただ、最終的に「IETFでアジェンダに空きがあれば発表時間があってもいいのでは？」という意見も出ていました(参考)。
現時点では、このドラフトがどうなるのかは不明です。 RFCになる以前に、そもそもワーキンググループドラフトとして採用されるかどうかも怪しいです。
今回のdraftを読んだ感想ですが、本件とは別に雨後のタケノコのように「DNSSECでやればいいのでは？」という提案が色々と集まって、いまよりもさらにDNSがクリティカルなシステムへと変化していきそうな予感がして気持ち悪いと思いました。 先日の幽霊ドメイン脆弱性に対するISC(Internet Systems Consortium / BINDを管理しているところ)が「通常のDNSはセキュリティを実現するようには設計されていない。そういった用途はDNSSECで行うことをISCは推奨している。」と発表していますが、この文章をあらためて読むと「DNSSECであればセキュリティ担保に利用しても良い」と言っているようにも読めるので、なおさら気持ち悪さが残ります(*1)。
「DNSを乗っ取ればBGPハイジャックもできるようになります！」という感じになると、結構怖い気がします(今は、状況によってはそれがなくても出来るから、今よりマシという考え方もありますが)。 さらに、DNSレコードのTTLを考えると、状況によっては経路変化が反映されずに正しい経路が「偽物」と判定される事故も発生しそうだとも思いました。 まあ、現時点での個人的な感想としては「混ぜるな危険」ですが、同時に「オレに混ぜさせろ」と言いたくなる人も多そうだなぁという感じです。
*1) ISCによる公式発表は行われていませんが、その後、BINDに含まれる幽霊ドメイン問題は修正されているようです。(via tss_ontapさん)
SIDRワーキンググループのRPKI
今回のDNSSECによるBGP経路情報提案は、SIDR(Secure Inter-Domain Routing)ワーキンググループで今年2月に色々とRFCになったRPKI(Resource Public Key Infrastructure)と問題意識が競合しているという側面もあります。 BGPハイジャック対策としてRPKI vs DNSSECという議論になるのか、「RPKIでいいじゃん」で終わるのかというのもありそうです。
これまでBGPハイジャック事件は色々とあり、その対策として経路奉行のような取り組みが行われてきましたが、これから徐々に新しい経路認証技術が利用されていく方向へと変化して行くのかも知れません。
最近のエントリ
- Interop 2023のShowNetバックボーン詳解
- Interop Tokyo 2023 ShowNet取材動画
- 「ピアリング戦記 - 日本のインターネットを繋ぐ技術者たち」を書きました！
- 1.02Tbpsの対外線！400GbE相互接続も - Interop ShowNet 2022
- Alaxala AX-3D-ViewerとAX-Sensor - Interop 2022
- SRv6を活用し、リンクローカルIPv6アドレスだけでバックボーンのルーティング - Interop ShowNet 2022
過去記事
