RE: NAT Traversal

[Srinivasa Addepalli <srao@intotoinc.com>]

Hi Chinna,
   As I see it, we are trying to debate on three solutions:

   1. Supporting ESP ALG in NAT boxes with SPI changes. 
   2. NAT traversal as defined in current drafts.
   3. Some independent solution. ( You indicated that independent NAT
      discovery
      and NAT traversal alerady being taken care off by midcom
      working group. So, we can postpone this discussion).

   Solution 2:
     By standardizing different UDP port for encapsulating ESP/AH traffic,
     it works through all existing NATs (supporting ESP ALG or not).
     One disadvantage is that it requires changes to IKE/IPSEC 
     implementations. 
     
     By having different UDP port, the overhead also comes down by
     8 bytes. But, one more keepalive timer is required to make 
     the NAT session alive.

   Solution 1:
     Have limitations such as only ESP traffic, no AH traffic.
     What about Transport Mode? Does this solution support?
     SPI modifications which require changes in existing hardware
     and software implementations. (It was assumed that SPI selection
     is local matter). 
     What happens if hash value of different SPIs come out to be same?
     How does it work, if quick mode responder sends the packets first?
     

  Keeping both the solutions in mind, it appears that solution 2 is
  better. 


Regards
Srini

On Mon, 4 Mar 2002, Chinna N.R. Pellacuru wrote:

> On Mon, 4 Mar 2002, Paul Koning wrote:
> > >>>>> "Chinna" == Chinna N R Pellacuru <pcn@cisco.com> writes:
> >
> >  Chinna> And considering the fact that an IPsec SA is identified by
> >  Chinna> the tuple: Destination, Protocol and SPI, the probability of
> >  Chinna> a collision is even lower, and for all practical purposes
> >  Chinna> zero.
> >
> > But we're talking about NAT.  NAT hides addresses behind it and makes
> > everything look like a single address.
> >
> > So in the context of NAT (at the other end) you have lots of SAs from
> > the same address, and of course the protocol is constant (50).
> >
> 
> I think that there seems to be a big problem with people who want to only
> casually look at this problem of NAT and IPsec. I think that these casual
> observers tend to assume that any and every possible scenario of NATs and
> IPsec will work with some solution. You'll have to first take the time to
> understand what is feasible, and what is not. Once you have come up with a
> set of scenarios in which it is feasible to solve this problem, then you
> have to pick a technique that will only work in those scenarios.
> 
> Now, given that, please let me know what scenario are you particularly
> interested in, and I can try and see if our solution will work. Without
> the details, I don't know what you are talking about. Lets not try and
> talk about NAT and IPsec in general, because I think both of these
> protocols are very complex individually, and once you combine them, they
> tend to become intractable.
> 
>     chinna
> 

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