[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: UDP-encapsulated IPsec Transport mode
On Fri, 8 Nov 2002, James Huang wrote:
>
>
> > -----Original Message-----
> > From: Skip Booth [mailto:ebooth@cisco.com]
> > Sent: Friday, November 08, 2002 4:50 PM
> > To: James Huang
> > Cc: 'Markus Stenberg'; ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > Subject: RE: UDP-encapsulated IPsec Transport mode
> >
> >
> >
> >
> > On Fri, 8 Nov 2002, James Huang wrote:
> >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Skip Booth [mailto:ebooth@cisco.com]
> > > > Sent: Friday, November 08, 2002 12:09 PM
> > > > To: James Huang
> > > > Cc: 'Markus Stenberg'; ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > > > Subject: RE: UDP-encapsulated IPsec Transport mode
> > > >
> > > >
> > > >
> > > >
> > > > 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.
> > > >
> > >
> > >
> > > Skip,
> > >
> > > With UDP-encapsuilated IPsec, NAT box will only see and
> > modify the outer UDP
> > > header used to encapsulate the IPsec packet (in addtioanl
> > to modify the
> > > outer IP address). After the security gateway
> > decapsulating an IPsec packet
> > > in transport mode (i.e. removing the outer UDP header and
> > the ESP header)
> > > and modify the source IP address in the outer IP header
> > with the address
> > > received in the NAT-OA, the checksum in the inner TCP/UDP
> > header should be
> > > already correct as the client computes that checksum based
> > on the same
> > > address in the NAT-OA.
> > >
> > > Am I missing something here?
> >
> > I think you are confused since it appears that you believe
> > their is an outer IP
> > header and an inner IP header. This is not true for the
> > Transport Mode ESP
> > encap specified in the draft. The packet format for
> > Transport Mode ESP Encap
> > (which is what would be used for L2TP/IPsec most likely) is
> > specified as
> > follows:
> >
> > 3.2 Transport Mode ESP Encapsulation
> >
> > BEFORE APPLYING ESP/UDP
> > ----------------------------
> > IPv4 |orig IP hdr | | |
> > |(any options)| TCP | Data |
> > ----------------------------
> >
> > AFTER APPLYING ESP/UDP
> > -------------------------------------------------------
> > IPv4 |orig IP hdr | UDP | ESP | | | ESP | ESP|
> > |(any options)| Hdr | Hdr | TCP | Data | Trailer |Auth|
> > -------------------------------------------------------
> > |<----- encrypted ---->|
> > |<------ authenticated ----->|
> >
> > For L2TP/IPsec, these will look like:
> >
> > IP/UDP/ESP/1701/1701/[L2TP hdr/PPP]/ESP trailer/ESP Auth
> >
>
>
>
> Skip,
> The L2TP/IPsec packet should look like this in more detail,
>
> IP1/UDP/ESP/1701/1701/L2TP hdr/PPP hdr / IP2/ ... /ESP trailer/ESP Auth.
> The outer IP header is the first IP header IP1 above. The inner IP header
> is the second IP header IP2 that I just added. THis is the packet format
> after the IPsec tunnel is set up, L2TP tunnel is set up, IPCP is completed
> (e.g. for the client to obtain a private address in the corporate network),
> and the real data traffic inside the L2TP tunnel starts flowing..
>
>
>
>
> > As such, the outer header contains the private address. The
> > NAT box will
> > perform the IP address/port translation on the outer IP/UDP
> > header and in the
> > process will recompute the CRC on the outer IP header. On
> > the SG, after
> > restoring the private addresses on the outer header, the CRC
> > must be restored to
> > the original value prior to the NAT fixup.
> >
> > -Skip
>
>
> Skip,
>
> Lets take the following scenario as an example.
>
>
> PC -------- NAT -------- internet --------- SG
> ------------ server
>
>
> Suppose the PC's private address is PC1, the public address at the NAT is
> P1, the public address at SG is P2, and the server has a private corporate
> address S1.
> Both the IPsec transport mode tunnel and the L2TP tunnel are btw the PC and
> the SG.
>
> During IKE QM exchange to set up an IPsec tunnel to protect L2TP packets,
> the first packet the SG received will look like this:
>
> ip header: P1->P2,
> traffic selectors: IP: PC1<->P2, udp port: 1701 <-> 1701 (assuming LAC
> chose the fixed UDP port). If the QM exchange succeeds, the SG will enter
> into its inbound/outbound filtering database based on above traffic spec.
>
> When the PC sends out a L2TP control packet, it will look like this:
> IP/UDP1/ESP/UDP2/L2TP control/ESP trailer/ESP Auth. The IP header will be
> from PC1 to P2 and UDP1 will be from 4500 to 4500, UDP2 will be from 1701 to
> 1701. The UDP checksum in UDP2 will be based on the address PC1. After
> this packet passed the NAT box, the IP header will be from P1 to P2 and UDP1
> may be adjusted to from port Y to 4500 and its checksum also adjusted.
> Note UDP2 is not touched by the NAT box.
>
> After the SG decrypts and decapsulats the inbound packet, it will look like
> this: IP/UDP2/L2TP control. The IP header will be from P1 to P2 and UDP2
> from 1701 to 1701.
> The SG will then modify the IP header to PC1 -> P2. Now the packet will
> pass the checking using the filtering database and the checksum in UDP2 will
> also be automatically correct.
I'm not sure that the checksum in the outer IP header is valid at this point
though. The IP header's CRC will be based on the P1 to P2 addresses, however
once IPsec finishes manipulating the packet, the IP addresses will be PC1->P2
and the IP CRC will need to be adjusted to reflect that. I agree with you
though that the UDP2 checksum should be correct.
>
> After the L2TP tunnel is set up, and IPCP is completed, the PC will obtain a
> private address Vpc1 from inside the corporate network. Now the packet sent
> by the PC will look like this: IP1/UDP1/ESP/UDP2/L2TP hdr/PPP hdr / IP2/
> ... /ESP trailer/ESP Auth.
>
> IP1: PC1->P2
> UDP1: 4500->4500
> UDP2: 1701->1701 (checksum computed based on PC1)
> IP2: Vpc1->S1
>
> The rest should be very similar to what I described above.
That's all correct and hopefully we've now answered you original question about
how the packet passes the SG filter checks. I'll defer any further checksum
questions to the authors of the draft :)
-Skip
>
>
>
> -- James Huang
>
>
> > >
> > > Regards,
> > > James Huang
> > >
> > >
> > >
> > >
> > > > > 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 passte
> > > > > > 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.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>