Re: IPSec NAT pass-through and TCP checksums

[Bora Akyol <bora@cisco.com>]

William

I don't think in my email I required the NAT to provide a message, I
said that the party in the public network can tell the party in the
private network what it thinks its public side address (effectively
the address of the NAT) is.

It looks like the draft is geared towards a host coming from behind a
NAT with a VPN box/router sitting in the public network and providing
connectivity. I think this is a perfectly normal case in which the
host sitting behind the NAT has the option to disregard the TCP
checksums when and if it desires for transport mode, but if the box
sitting behind the NAT also happens to be a router, then for every
packet that it receives in TRANSPORT mode, it looks like it needs to
calculate complete TCP checksum. 

This seems very inefficient to me. Suppose that I have a NAT/VPN
router in my house and I have 6-10 computers behind it, now this
router when I configure transport mode, is recomputing TCP checksums
for every packet that it receives. 

Do you agree that this may present a problem?

Bora

From: "William Dixon" <wdixon@windows.microsoft.com>
Subject: RE: IPSec NAT pass-through and TCP checksums
Date: Mon, 23 Sep 2002 16:07:04 -0700

> The purpose of the existing Original Address payload in quick mode is to
> provide the information to the authenticated peer for how to fix up the
> TCP/UDP checksums that are protected by ESP encapsulation, if the
> TCP/UDP receiver chooses to do so.  If the TCP/UDP receiver knows that
> the traffic was received over an IPsec SA, it may choose not to
> recalculate or verify a checksum on inbound traffic that it consumes.
> However, I refer you to the mail by Brian Swander 7/29/02 to the IPsec
> list that dealt with a more general problem of this case, multiple IPsec
> NAT-T clients behind the same NAT going to the same receiver IP address.
> 
> 
> Note the operative phrase above: "that it consumes".  These drafts do
> not intend to provide a solution if you have to NAT the traffic before
> it is encapsulated with IPsec ESP or after it is decapsulated, such as
> NATing traffic from a remote office's private address space before or
> after it gets IPsec tunneled to HQ network.  The drafts only claim to
> provide a solution within IKE & ESP UDP encapsulation for passing IPsec
> ESP transport or tunneled traffic across NATs that exist between the
> IKE/IPsec peers.
> 
> Bora, your suggestion of the involvement of the NAT violates the
> requirements draft - that a solution must be independent of and
> essentially transparent to existing deployed NATs.  Further, there would
> be no way to trust such a message and no way to depend on NAT vendors
> implementing it.  Plus the external source address shouldn't be that
> useful, because you don't know whether there were 1 or 2 or N NATs on
> the traffic outbound before you received it - what if you received
> multiple....   
> 
> -----Original Message-----
> From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] 
> Sent: Friday, September 20, 2002 9:52 AM
> To: 'Bora Akyol'; ipsec@lists.tislabs.com
> Subject: RE: IPSec NAT pass-through and TCP checksums
> 
> 
> 
> > >From the statements in the relevant sections of the ID, it seems that
> > this is in fact correct. I am wondering however, why not simply add a 
> > NAT-NA (NAT Address) payload (optionally) sent by the public side 
> > device, which has this address, to the other party involved in the IKE
> 
> > exchange so that a simple recomputation should suffice. Of course if 
> > both sides are behind NAT gws then all bets are off.
> 
> This occurred to me, actually I think we can even sort out the double
> NAT case.
> 
> The initiator sends as part of the key agreement a statement of
> 1) What it believes its source IP address to be
> 2) What it believes the destination IP address to be
> 
> This can then be stored with the SA and used to fix up the packets.
> 
> 
> > I may be opening up an old wound here unknowingly, and my apologies 
> > for that in advance.
> 
> Patent troll perhaps???
> 
> When in the distant past there were discussions of NAT the frequent
> pushback was 'if you are NAT on the NET you are NOT on the NET'. So 
> I would not take a great deal of notice of the old wounds.
> 
> The WG now understands that NATs exist and are not going away and so we
> all have to work out how we can live with them (translation I have a NAT
> box at home and I want my VPN to work through it)...
> 
> 
> 		Phill
> 
> -----Original Message-----
> From: Bora Akyol [mailto:bora@cisco.com] 
> Sent: Thursday, September 19, 2002 7:12 PM
> To: ipsec@lists.tislabs.com
> Subject: IPSec NAT pass-through and TCP checksums
> 
> 
> 
> >From a review of the NAT-T and UDP encap IDs,
> it seems that the entity that is within the
> private network (and behind the NAT gw) does not have access to the
> public side IP address of the NAT gw.
> 
> This in turn causes the receiver of transport-udp mode traffic to
> recompute the entire TCP checksum as opposed to an adjustment of it.
> 
> >From the statements in the relevant sections of the ID, it seems that
> this is in fact correct. I am wondering however, why not simply add a
> NAT-NA (NAT Address) payload (optionally) sent by the public side
> device, which has this address, to the other party involved in the IKE
> exchange so that a simple recomputation should suffice. Of course if
> both sides are behind NAT gws then all bets are off.
> 
> I may be opening up an old wound here unknowingly, and my apologies for
> that in advance.
> 
> Regards,
> 
> Bora Akyol
> 
> ps. I did try to search the list archives on this topic 
> but neither of the two FTP sites are working tonight.
>