RE: NAT Traversal

[Srinivasa Addepalli <srao@intotoinc.com>]

Hi,
  MobileIP working group did lot of work in regards to NAT discovery
  and Traversal. We can use this work as basis to define discovery
  and traversal of NAT boxes in this working group OR see the
  possibility of using mobileIP work here. This will not require
  any changes to either IKE/IPSEC or no changes to NAT boxes.

  Mr Henrik is kind enough to offer his services to solve the 
  problem with his expertise in mobileIP. I really would like to
  see some solution which solves the problem without any changes
  to IKE/IPSEC and NAT boxes.

Regards
Srini

On Sat, 2 Mar 2002, Henrik Levkowetz wrote:

> On Thursday, February 28, 2002 Chinna wrote:
> ...<snip>...
> > 
> > I would also like to extend the request to everyone (the veterans who can
> > help us technically and also guide us through the IETF process, and
> > frankly THE MORE THE MERRIER).  Please join us if you want to help us. If
> > you are skeptical of us due to the flame exchange, honestly, that's not
> > our true nature. Please send me an email.
> > 
> 
> Well, I'm taking you up on this; then we'll see if I end up hit
> by a barrage of pies, eggs, tomatoes and whatnot from every direction...
> 
> I've followed the discussions with respect to NAT traversal on the ipsec
> mailing list during the last half year or so, while I've been working on
> the current draft on NAT traversal for Mobile IP, and also implementing
> NAT traversal for Mobile IP.
> 
> It seems to me, viewing this discussion somewhat from the outside, that
> in the matter of NAT traversal for IPsec you have as a group become the
> victims of your own success. Let me explain what I mean; it is leading
> somewhere:
> 
> One goal in IPsec work would naturally be to have the protocols concerned
> be as opaque and resistant as possible to both traffic and content analysis.
> 
> One goal for NATs is to leverage extra information (in the form of port
> addresses preferably) in order to make up for a scarcity of ip-addresses.
> 
> So the more you succeed in making the communication opaque, the less there 
> is for NATs to work with. The (in this respect) straightforward solution to 
> accomplish NAT traversal is then to give NATs their favourite stuff to work
> with: Port numbers. All ALGs (Application Layer Gateways) which are
> added to NATs are there to take care of the protocols which do NOT give
> the NATs port numbers to work with. They sometimes work, and sometimes
> work well.
> 
> The solution subdivides into (at least) two parts: Discovering if you are 
> behind a NAT, and doing something about it if you are.
> 
> Chinna had a reference to an excellent draft which answers the first part
> in a generic way: 
>   http://www.ietf.org/internet-drafts/draft-rosenberg-midcom-stun-00.txt
> 
> The answer to the second part will have to consider the particular
> requirements of the protocols which you want to get trough a NAT, but
> if you would accept input from someone who's not of the IPsec community,
> I'd be willing to pitch in. I don't believe the problem is too intractable.
> 
> 	Best regards,
> 
> 		Henrik
> 

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