RE: UDP-encapsulated IPsec Transport mode

[Skip Booth <ebooth@cisco.com>]

On Fri, 8 Nov 2002, James Huang wrote:

> Skip,
> 	If we fix up the source IP address using the private address
> advertised in NAT-OA during IKE negotiation, then why should TCP/UDP
> checksum be re-computed at the security gateway as was described in section
> 3.1.2?

Because the NAT would have modified the checksum as the packet passed through
the NAT.  In order for it to pass the IP CRC check at the SG, you must fixup the
checksum based on the pre-NAT values.

> The checksum was originally computed by the client using its
> private address.  Also is this solution the same as the "built-in NAT"
> solution mentioned in Appendix A of draft-ietf-ipsec-udp-encaps-04.txt to
> solve the problem of multiple clients behind a NAT with overlapped traffic
> specifications?

I don't the CRC fixup has anything to do with Appendix A.

-Skip

>
> Thanks,
> - James
>
>
> > -----Original Message-----
> > From: Skip Booth [mailto:ebooth@cisco.com]
> > Sent: Thursday, November 07, 2002 7:31 PM
> > To: James Huang
> > Cc: 'Markus Stenberg'; ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > Subject: RE: UDP-encapsulated IPsec Transport mode
> >
> >
> >
> > James, does the recommendation in section 3.1.2 a) answer
> > your question?  I
> > believe after fixing up the IP header to include the private
> > address which was
> > advertised during the negotiation, the packet will pass
> > through the SG filters.
> > The authors of this draft should be able to provide further
> > clarification if
> > this doesn't address your concerns.
> >
> > -Skip
> >
> > On Thu, 7 Nov 2002, James Huang wrote:
> >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Markus Stenberg [mailto:fingon@iki.fi]
> > > > Sent: Wednesday, November 06, 2002 11:51 PM
> > > > To: James Huang
> > > > Cc: ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > > > Subject: Re: UDP-encapsulated IPsec Transport mode
> > > >
> > > >
> > > > James Huang <james.huang@watchguard.com> writes:
> > > > > Hi all,
> > > > > 	In the appendix A of
> > > > draft-ietf-ipsec-udp-encaps-04.txt, there is
> > > > > some discussions on the issue of multiple clients running
> > > > UDP-encapsulated
> > > > > IPsec transport mode tunnels behind a NAT box.  However,
> > > > did not find any
> > > > > discussion on another related issue:  In the traffic
> > > > selector (ID) payload
> > > > > the client sends out during quick mode exchange, should the
> > > > client use its
> > > > > own private address or the public routable address (i.e.
> > > > the NAT box's
> > > > > public IP address)?  If it the later, how does the client
> > > > know about that
> > > > > public address?  This seems to be a serious issue,
> > > > especially for L2TP
> > > > > voluntary tunnels secured by IPsec (in transport mode).
> > > >
> > > > L2TP specific issues I am blissfully unaware of; however,
> > > > because the NAT
> > > > boxes are not neccessarily even controlled by the IPsec user,
> > > > sending the
> > > > public address is not really an option that can be supported
> > > > everywhere.
> > > >
> > >
> > > Agreed.
> > >
> > > > Here's how the information flow goes as far as I see it:
> > > >
> > > >  Public address doesn't really need to be sent in any case as
> > > > the remote
> > > >  side's public address is the address we're talking IKE with
> > > > (or at least
> > > >  remote address+port combination, but in NAPT case you don't
> > > > really have
> > > >  more of an remote address in any case).
> > > >
> > > >  Private address that is used by the OS for actual
> > traffic is provided
> > > >  within the NAT-OA payload so the checksums et al can be
> > corrected.
> > > >
> > >
> > > Let me describe the issue with regarding to L2TP/IPsec
> > (voluntary L2TP) when
> > > a NAT is present.  Suppose a PC with a home network's
> > private IP address V_1
> > > is behind a NAT box with a public address P_1.  The
> > corporate network's
> > > Security Gateway's IP address is P_2 and the PC wants to
> > connect to a
> > > corporate server with private IP address I_2.  If
> > everything goes well, this
> > > PC will eventually obtain another private address I_1 from
> > the corporate
> > > network through IPCP .   So the L2TP traffic sent by the PC
> > will have the
> > > following headers: IP/UDP/ESP/UDP/L2TP control or
> > > IP/UDP/ESP/UDP/L2TP/PPP/IP/.... The outer IP header will
> > indicate the
> > > traffic is sent from V_1 to P_2.  The inner IP header will
> > indicate the
> > > traffic is sent from I_1 to I_2.  The source IP address V_1
> > in the outer
> > > header will be changed by the NAT box to P_1 on the way
> > out.  So the packet
> > > received by the corporate SG is an UDP-encapsulated
> > TRANSPORT mode IPsec
> > > packet from P_1 to P_2 with UDP source port 1701 and UDP
> > dest port 1701 in
> > > the 2nd UDP header (assuming no dynamic UDP port for L2TP).
> >  To allow this
> > > packet to pass through the SG, an inbound filter matching
> > the packet must
> > > exist in the SG.  The inbound filter is dynamically created
> > after a quick
> > > mode exchange between the PC and the SG.  To create such a
> > filter in the SG,
> > > the PC must specify < IP = P_1, proto = UDP, port  = 1701>
> > in ID_i during
> > > the quick mode exchange.  But how does this PC knows about P_1?
> > >
> > > What I described above is a scenario specific to L2TP/IPsec.  But in
> > > general, any transport mode IPsec tunnel with a NAT box
> > along its path will
> > > have the same problem.
> > >
> > > Am I right? Or I am missing something here?
> > >
> > > - James Huang
> > >
> > >
> > >
> > > > Therefore, at least as far as implementation I used to work
> > > > on goes, ID
> > > > payload in transport mode case doesn't matter (I seem to
> > > > recall we sent
> > > > private address, but pretty much ignored what was sent by remote).
> > > >
> > > > -Markus
> > > >
> > > > > Regards,
> > > > > James C. Huang
> > > >
> > > > --
> > > > "Every program has (at least) two purposes: the one for
> > which it was
> > > > written, and another for which it wasn't. "
> > > >
> > > > From ACM's SIGPLAN publication, (September, 1982),
> > Article "Epigrams
> > > > in Programming", by Alan J. Perlis of Yale University.
> > > >
> > >
> >
>