[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Towards closure on NAT traversal.




AH can't be passed through NAT.  ESP works, but some intelligence
is needed in the NAT/firewall boxes. If NAT friendly IPSEC/IKE is 
required (which solves many problems), then both IKE and ESP have to be
fixed or encapsulated within UDP packet.

NAT traversal, outside IPSEC/IKE seems to be a good solution to me.
This does not require changes to already deployed IPSEC and NAT solutions.
L2TP is one such solution. This can encapsulate packets in UDP which
is understood by NAT. But, it adds lot of baggage to the packets and
since NAT discovery is not part of L2TP, it encapsulates all packets.
Other solution is to come out with some standard which is lightweight
and does NAT discovery and encapsulates packets of required services
(based on local configuration and NAT discovery results).

Thanks
Srini


On Fri, 1 Mar 2002, Hallam-Baker, Phillip wrote:

> 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
> 
> 
> 

-- 
Srinivasa Rao Addepalli
Intoto Inc.
3160, De La Cruz Blvd #100
Santa Clara, CA
USA
Ph: 408-844-0480 x317