ISPでのNATに関する諸問題

数日前になるが、IACの宮川さんがJuniperのプライベートショーでキャリアグレードNATについて講演されたニュースを見た。
1、2年ほど前から個人向けISPを中心に巨大なNAT箱を入れるらしいと聞いていたので、ついに現実化してきたかぐらいの思いしかないのだけど、実際に導入するとなると幾つか問題があるんじゃないかと思った。

明示的にNATに穴を開けるようなプロトコルへの対応

UPnPのNAT Traversalなどを使って明示的にNATに穴を開けてまで外部と通信しているプロトコルは単純には動かなくなるだろう。SkypeみたいにUDPパンチングホールとかは上手くすれば通るかもしれない。
少なくとも現在の約款で普通に使えている物をある日からISPの都合で使えなくするというのは通るだろうか。ヘビーユーザへのトラフィック制限と違って、説明がつきにくいのではないだろうか。
既存のユーザのアドレスはそのままにして、ライトコースのような物をつくって予め制限があることを約款に明記した別メニューを作れば対応可能かもしれない。但し、現行の値段より安くしないとユーザは納得しないだろうし、ただでなくとも厳しい収益を後ろ向きの努力で更に圧迫するかも。

NATテーブルの公平性

記事でも1つのIPv4アドレスにぶら下げられるユーザの数についての試算がある通り、案外ポートの数は小さい。現在でも多くのユーザをぶら下げているようなNAT箱ではテーブル溢れがときどき発生してしまうが、こういうときにはタイムアウトを短かくすることで対応している。しかし、ISPでサービスとして使おうというのだから、そんな対応だけでは済まないだろう。
じゃあ、1ユーザが同時に使えるTCP/UDPのポートの数をユーザ毎にアロケーションして厳密に管理してしまうと収容効率が下がるのでやりたくないはず。ある程度アロケーションしつつ、残りをソースアドレスごとに公平に利用するようなQoSの仕組みが必要なのかもしれない。多分現存するNATの実装でそこまで考えているのは無いんじゃないだろうか。
まあ、これはどちらかというと実装面での技巧の話。どうにかなるというか、どうとでも出来る。

ユーザのトラッキング

現在では掲示板などへ書き込みがあったときにISPがユーザの特定などをRADIUSの情報などを元に行っているが、これがNATの情報に代わる。
TCPの通信期間はPPPoEなどよりずっと短いし、量も多いので記録が膨大になるだろう。これらを法令で定められた期間保管するのはISPにとっても結構な負担になるんじゃないだろうか。
パケットダンプほどではないにしろ、結構な量になるはず。情報を突き合わせて個人を特定するときも、今までのようにIPアドレスだけではなく厳密にはソースポートも必要になってくる。
また、そもそもその情報を記録していいのかという懸念もある。TCPのヘッダ情報といえば、ISPからすれば本来見る必要のない顧客の通信内容だ。それらを機械で自動的に行うとはいえ、解析した上記録をとっていいものだろうか。DDoS対策などでヘッダの一部を解析する業務に関してはISPのネットワークへの脅威を取り除くという名目で監督官庁のお墨付きが出たらしいが、今度も拡大解釈だけでなんとかなるだろうか。

セキュリティ

POP before SMTPなんて今や使っている人はほとんど居ないと思うが、同様のIPアドレスベースで許可しているようなサービスは軒並み使えなくなる。
そもそも筋が悪い方法なので、駆逐されてしかるべきだとは思う。今後は、同じIPアドレスを他人も同時に使っているのだという事を常時意識する時代になるということだろう。
今までNAT箱ってオフィスや家庭などの閉じた環境で使われることが多かったので、内側からの攻撃にはそれほど晒されて来なかったのではないかな。直ぐに思いつくのは隣りのセッションを偽装パケットで乗っとるような攻撃だけど、これは箱のinboundフィルタを適切に使えば防げそう。でもこればっかりは色々と思いつく人達がいるので、暫くは穴を発見されては対策をするというのが続くんじゃなかろうか。