[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IKEv2 and NAT traversal
I am attempting to get down to the core argument here.
It appears to me that the significance of Son of IKE wrt NAT is that it is
an oppotunity to do the right thing ab initio, and hence avoid much of the
complexity of retrospective NAT fixes for IKE.
The ability to support NAT reliably is likely to become the main value add
that son-of-IKE provides to end users. This is because support for NAT
translates into 'ability to use the ethernet connection in a hotel room or
the 802.11B in the Red Carpet Club and Starbucks'.
It is disappointing that there is still a faction still peddling the 'if you
are NAT on the NET you are not on the NET' dogma. NAT is what you get when
you architect a network with a built in upper bound of 4 billion addresses
on a planet with a human population of ten billion, it fixes a bug in the
design of the Internet that was introduced so that an IP address would fit
in a register on a long defunct machine, end of story.
The core problem with NAT is that packets appear from an IP address which is
not the one that the sender expects. This causes other fields on the packet
to arrive damaged, including the checksum.
One solution to this that occurs to me is to modify the key agreement so
that the sender tells the reciever the IP address that they believe that
they are using and the responder tells the sender the one that it sees. This
information is stored in the SA/SPD or NTLA (New Three Letter Acronym),
permitting the responder to affect repairs to the said damaged packets.
The main issue here is whether commonly deployed NATs perform any harm to
the packets that cannot be repaired with knowledge of the IP address.
I am less bothered by the secondary points in the requirements document
about applications that rely on IP addresses embedded in protocols. I
suspect that such protocols break anyway when they pass through the current
generation of NAT. The only way to make them work well would be to devise
some protocol to support requests from a client to open up ports on the NAT
- which would typically be left turned off because NAT boxes are often
serving as firewalls.
The other security issue to consider is that NAT is often installed
specifically to conceal the details of the internal network configuration
from external parties.
This is not a solution that is open if you are not already messing with the
key agreement. Once the key agreement is on the table however it is
important to take the opportunity to do the right thing.
At present we do not have a true IPSEC deployment, we have a VPN deployment
that uses IPSEC in a network, but we are not at the 'network of netowrks'
level, still less anywhere close to an Internet secured at the packet layer
(which is a necessary but not sufficient condition for a secure internet).
I suspect that before we get to ubiquitous deployment of IPSEC that the
protocol will morph in several ways, replacement of IKE being one, dropping
AH mode being another, junking the vanity crypto (or at least the
unnecessarily complex negotiation mechanisms support for vanity crypto
requires).
Phill
Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227
>
Phillip
Follow-Ups: