Some extensions to STUN.
Cullen Jennings <[email protected]>
| Newsgroups | gmane.ietf.midcom |
|---|---|
| Message-ID | <BC5D44A1.32863%[email protected]> |
I'm interested in adding few other tests to characterize NATs. One is testing to see if they rewrite data inside the payload of a UDP packet. NATs have been observed that rewrite the mapped address inside the stun packet. Multiple people have suggested a solution to this - an extension that returned an encrypted (mostly likely with xor) form of the the mapped address with some predefined key would detect this. The other tests probably do not require any STUN extension. One would be to look at NATs that changed their characteristics after the first packet. For example some devices act like a full cone on the first packet then after the first packet arrives, restrict down to only accept future packets from the same location as this first packet. (Rohan, Dan Wing, others have proposed this) Another test would be to check if a NAT is sending to two different addresses from the same port, will a packet on one flow update binding times for both flows. Some recommendations are still needed on how to keep NAT bindings alive. I suspect the deeper we look into how NATs operate, the more we will find strange cases. This leads me to be fairly keen on using