[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: UDP-encapsulated IPsec Transport mode
> -----Original Message-----
> From: Awan Kumar Sharma [mailto:awank@future.futsoft.com]
> Sent: Sunday, November 10, 2002 11:52 PM
> To: 'Skip Booth'; James Huang
> Cc: 'Markus Stenberg'; ipsec@lists.tislabs.com; l2tpext@ietf.org
> Subject: RE: UDP-encapsulated IPsec Transport mode
>
>
> Hi James and Skip,
>
> Initially the idea for re-computation for TCP/UDP Checksums
> was confusing me
> too. But now I feel that whatever has been mentioned in the draft is
> correct. I am putting my opinion regarding that here and
> please correct me
> if I am wrong anywhere. Incidentally, I would like to clarify that the
> checksum that needs to be updated (as specified in the draft)
> is the TCP/UDP
> checksum and not the IP Checksum (as Skip had quoted in one of his
> clarifications).
>
> There is no need to take an example of L2TP for finding the need for
> checksum re-computation. Any data traffic example in transport mode is
> enough. So, I am taking an example of a TCP traffic (between
> H1 and H2)
> being protected using IPSec in transport mode.
>
> Set-Up:
>
> SG1/Host1 ---------NAT(N1)------------- INTERNET ---------SG2/Host2.
>
> In this set-up, the hosts H1 and H2 are the SG's as well,
> since the traffic
> is protected in transport mode.
> A TCP packet going out of H1 (without IPSec) would look like:
> IPh1h2 | TCPh1h2 | Data,
> where TCPh1h2 is the TCP header that uses H1
> and H2 as the IP addresses
> for checksum computation.
> When IPSec is applied in transport mode with NAT traversal,
> the packet would
> look like,
> IPh1h2 | UDP <4500,4500>| ESP | encrypted (TCPh1h2 | Data ).
>
> When this packet traverses through a NAT device, the packet
> gets altered to
> IPn1h2 | UDP <x,4500>| ESP | encrypted (TCPh1h2 | Data).
>
> After this packet reaches SG2 (i.e. H2), after the normal
> IPsec processing
> and decapusulation as mentioned in the draft, the TCPh1h2 needs to be
> modified to TCPn1h2 (Why?). This is because, as far as TCP
> connection is
> concerned, after NAT H2 can only send data with Destination
> IP address as N1
> and not H1.
If we perfrom reverse NAT operation for outbound traffic at SG2, what you
just said should not be an issue.
>So, the data going UP(to TCP/HL) after IPSec
> decapsulation at
> SG2 should have the IP address as N1 and H2 and not H1 and
> H2. Now here is
> the point you were confused (I think). Instead of changing
> the IP address
> from N1 to H1, we need to change the checksum to adapt to N1
> as source. As
> far as my knowledge goes, the draft nowhere suggests to change the IP
> address from N1 to H1. It suggests only change in checksum.
> To change the
> checksum we need the IP address recieved through NAT-OA.
>
The problem with what you described above is that the packet will
have trouble passing the filtering database check at SG2. This is because
the traffic spec negotiated during IKE QM exchange is for traffics btw h1
and h2 (not N1 and h2).
One good side effect of changing the address from N1 back to h1 at
SG2 as I described in my previous emails is that the issue of "multiple
clients behind a NAT" described in the draft will no longer exist.
Regards,
James HUang
> Similar would be the case for L2TP.
> Hope that this clarifies your doubt . Please let me know if I
> am wrong a
> any place.
>
> Regards,
> Awan
>
>
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Skip Booth
> Sent: Saturday, November 09, 2002 9:10 AM
> 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 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.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> **************************************************************
> *************
> This message is proprietary to Future Software Limited (FSL)
> and is intended solely for the use of the individual to whom it
> is addressed. It may contain privileged or confidential information
> and should not be circulated or used for any purpose other than for
> what it is intended.
>
> If you have received this message in error, please notify the
> originator immediately. If you are not the intended recipient,
> you are notified that you are strictly prohibited from using,
> copying, altering, or disclosing the contents of this message.
> FSL accepts no responsibility for loss or damage arising from
> the use of the information transmitted by this email including
> damage from virus.
> **************************************************************
> *************
>