IETFでは「Transport Options for UDP」という仕様の標準化が議論されています。このUDP Optionsの仕様では"Maximum Datagram Size", "Timestamps " などのデータをオプション領域に格納して送信できるようになります。
新しいプロトコル機能の利用については、過去にもTLS1.3やTCP Fast Openといった新しいプロトコルがインターネット上で正しく処理されない(Ossification)問題が知られています (参考リンク)
UDP Optionsは特に変わったパケットになるため、インターネット越しで問題なく疎通するのか確認するというのが今回の目的です。
ちょっと面白い振る舞いも観測されたため書いていきます。
目次
実験
surplus areaをもつUDP パケットを 自宅からインターネット上の公開サーバに送信し返信が返ってくるか確認する。
利用したパブリックサーバは次のプロトコルを喋るものを幾つか選定。
手順としては、各公開サーバに対して以下の2つを試す。送るパケットは、それぞれのプロトコルに合わせて適切なパケットを送るものとする。
- 1. surplus areaのないUDPパケットを送信し、返信があることを確認する
- 2. surplus areaのあるUDPパケットを送信し、返信があることを確認する
パケットの例
パケットキャプチャすると、このようにDNSパケットとして正しく解釈されるものです (この例はDNSクエリのUDPパケットにsurplus areaを追加)
surplus areaに『this is surplus area』という文字列が格納されています。
結果
データ
- DNS: 21公開サーバに送信した。surplus areaがあると6サーバが返信しなくなった
- NTP: 10公開サーバに送信した。surplus areaがあると2サーバが返信しなくなった
- QUIC: 6公開サーバに送信した。surplus areaがあると2サーバが返信しなくなった
surplus areaがあると返信が返ってこなくなるサーバがいくつか観測された。幾つかは返ってくるためミドルウェア実装は問題なく処理できているのではないかとおもう。想像するに、返信がないケースはWAFなどにより不正なパケットとして遮断されているケースかなと思われる。
実際に、Google Cloud Platform (GCP)にVMインスタンスを起動しsurplus areaのあるパケットを送ってみると、VM側までパケットが到達してないことが確認できた（通常のUDPパケットは届く）。
また、次に示すように一部アプライアンス製品では、surplus areaがあるとパケット処理が特殊なケースも有るかもしれない。
奇妙な振る舞い
奇妙なことに、サーバ側 surplus area をそのまま送り返してくるケースが確認された。
NTPサーバ側からsurplus areaに『this is surplus area』という文字列入っているパケットが返ってきている。
調べたところサーバはNTP専用のアプライアンス製品であるもよう。想像するに、受け取ったパケットを格納しているバッファ領域を再利用してる感じなんだろうか？
このようなことが有ると、相手が送ってきたUDP Optionsが信頼できないので、コピーされてないことを保証する仕組みが必要になりそう
（例えば、追加のUDP Optionsとして"client bit", "server bit" みたいな送信方向を示すoptionsなどを定義するなど）
まとめ
今回はパブリックなサーバに対しsurplus areaを含むUDPパケットを送信した。
実験結果として以下のことがわかった
- surplus areaがあると疎通しないケースが有る
- surplus areaをそのまま送り返してくるサーバが居る
UDP Optionsは対応してない相手には無視されることが期待されるが、疎通しないケースが存在すると、UDP Optionsをつけずに再送しなおす必要が出てくる。
自分たちがサーバ側もクライアント側もコントロール出来るケースにおいてはUDP Optionsは気にせず利用できるが、そうではない場合は常に疎通しないケースを考慮する必要がでてくる。
終わりに
この実験結果をもってしてなにか改善にとりくめるか、一緒に議論できる方がおりましたら是非よろしくお願いします
