People appear to be so caught up in whether we should be supporting NAT that the issue of how to support NAT is forgotten about. A good analogy here IMHO is email. In the email world all sorts of horrible kludges have been deemed necessary because most email servers are hopelessly broken. They arbirarily change character sets to no good purpose (esp. lossy ASCII to ASCII translations), they strip out bit 7 for no reason, they insert CRs at random points to support broken mail clients from the 1950s. And as for mailing lists, the protocols are hopelessly broken. But if you are in a mail group you are expected to work with the existing legacy infrastructure. I find the idea that the NAT infrastructure that is out there is going to be changed to be hopelessly naive. The problem is only going to get worse the longer the IPSEC group refuses to admit that it is a major problem. We already have a major problem with vendors introducing proprietary work arrounds. The only infrastructure you can change to make IPSEC work is IPSEC. I really don't care how we got to here. I really don't care what the Internet architecture was. I have no interest in normative architectural values, I care about the infrastructure as it exists. There are OSI working groups for those who care about architectural perfection. Otherwise, just treat NAT boxes as an adversary that is attempting a DoS service on your protocol. You protocol does not pass acceptance testing unless it works (i.e. packets get through) in the presence of a NAT attack. Reading through the NAT 'requirements' draft the issues appear to divide into two sets: 1) Those that affect only AH mode 2) Those that are due to the design of IKE The solution to 1 would appear to be to simply admit that AH mode is not going to be compatible with NAT. The solution to 2 does not appear likely to be a minor tweak to IKE, not least because there is now the problem of dealing with infrastructure that is attempting to anticipate IKE behavior. At the very least we need a version rev here. Since the majority of the problems appear to be due to the key exchange it would appear to be best to concentrate on developing a NAT compatible key exchange, i.e. ensuring that IKEv2/JFK or whatever hybrid emerges is NAT friendly. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227
Phillip Hallam-Baker (E-mail).vcf