[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IKEv2 and NAT traversal
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]
> On Behalf Of Henry Spencer
>
> > 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...
> > permitting the responder to affect repairs to the said damaged
packets.
>
> Care would be needed to avoid chicken-and-egg problems here -- the
> information needed to make repairs can't be exchanged by mechanisms
which
> assume repair is already possible! That said, this has potential.
>
Very interesting! This is the approach that I had proposed @ San Diego.
Essentially you can take two* approaches to solving the NAT problem.
First approach is to prevent the NATs from modifying the part of the
packet that you care about. The second approach is to let NATs modify
the packet and just reverse the effect of NATs at the receiver.
ESP-UDP is the former approach and ours is the latter approach.
The way we have designed the solution, you don't need any modifications
to IKE. Our solution is a more general NAT traversal solution, and
non-IPsec people can also use it. The solution is ready and hopefully we
will be ready to release it by March-April 2002.
>
> However, in most IPsec situations there is little that can be done
about
> it. There simply is no way to do benign surgery on packet innards
without
> causing IPsec authentication failures, even if you have access to the
> innards at all, which you don't if they're encrypted.
>
;-)
> Henry
Spencer
>
henry@spsystems.net
~Jayant Shukla
Trlokom, Inc.
* Third approach is to change NAT! :-)
Follow-Ups:
References: