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

Re: NAT and IPsec




--- Ari Huttunen <Ari.Huttunen@F-Secure.com> wrote:
> Pyda Srisuresh wrote:
> > Couple of questions:
> >     1. Sanity check: I believe, ESPUDP is a specific instance of a UDP
> >        application, when the destination/Source is set to 2746 or 2797.
> >        Is this correct? The ESPUDP port apparently requires an ESP header
> >        to follow the UDP header, right? Does this ESPUDP  also mandate
> >        that the UDP checksum field be turned off?
> 
> ESP is required since we want to make a secure protocol, and AH will
> never work with this. IPCOMP may come after ESP. We mandate the UDP checksum
> to be turned off because it's just overhead in this case (same endpoints).
> 

I understand, if you choose to mandate turning off UDP checksum. 
However, UDP checksum is not an issue with the NAT devices.

> >     2. Assuming the above assertion is valid, the transport mode will not
> >        work with TCP/UDP packets for NAPT for the follwing 2 reasons
> >        A. Checksum failure, as pointed out in the draft[section 6]
> >        B. 2 independent hosts in the same private domain could be
> >           using the same (source port, destination port) pair and the
> >           external node will have no way to distinguish between the two.
> 
> I still claim it can be made to work. For A the receiver of a packet (either
> end)
> must first process the ESP header, after which it needs to both do some sort
> of NAT and recalculate the TCP/UDP checksums.

This is what I was refering to - Exporting NAT function to external devices.
RSAP-IP, on the other hand, does this on the RSAP-node. External nodes will
not see the private address or the port.

> 
> For B:
>  Alice sends IP:A->GW UDP:2797->2797, GW receives IP:NATBOX->GW
> UDP:aaaa->2797
>  Bob   sends IP:B->GW UDP:2797->2797, GW receives IP:NATBOX->GW
> UDP:bbbb->2797
> 
> 

But, the end-to-end TCP/UDP header and payload are encrypted, right?
I was refering to these encrypted ports that are decrypted by the
peering external device.

> >     3. As for tunnel mode using ESPUDP port, I dont see the
> >        point of transporting private address across to an external
> >        domain. This is essentially moving the NAT function from possibly
> >        multiple private domains to a single external Node. This is very
> >        problematic and shouldnt be used, in my opinion.
> 
> There's no problem. You can do it with the politically correct DHCP over
> IPsec or the politically incorrect MODECFG. Works fine either way.

The tunnel peer will have to do unique address and port assignments,
for each tuple of (Tunnel-encapsulating IP address, tunnel-encapsulating
ESPUDP source port, encapsulated-IP address(pvt), encapsulated-port(pvt)).
This is not just DHCP. It seems to me, the approach is complex and 
has scalability problem.

Doing RSIP does not export the problem to external devices.

> 
> Ari
> 
> -- 
> Ari Huttunen                   phone: +358 9 859 900
> Senior Software Engineer       fax  : +358 9 8599 0452
> 
> F-Secure Corporation       http://www.F-Secure.com 
> 
> F-Secure products: Integrated Solutions for Enterprise Security

cheers,
suresh



=====


__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.com/