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

RE: IPSec NAT pass-through and TCP checksums



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.