RE: NAT Traversal

[Srinivasa Addepalli <srao@intotoinc.com>]

Solution 3:
     I had gone through midcom documents. It seems that midcom
     NAT traversal is different from what we are trying to 
     achieve.

     But mobileIP working group NAT traversal is similar to what
     we are discussing here. 

     Is there any interest in using mobileIP nat traversal?
     It seems that, it works even if IPSEC device gets the
     private IP address from the local service provider.
     It works with any other applications too. 

     No changes to IPSEC/IKE and NAT boxes. Once mobile IP is
     implemented on both ends of communication, it should work.

Regards
Srini


On Mon, 4 Mar 2002, Srinivasa Addepalli wrote:

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