Subject: [L2tpext] RE: UDP-encapsulated IPsec Transport mode

From: Skip Booth <[email-masked]>
Date: Thu, 7 Nov 2002 22:30:33 -0500 (Eastern Standard Time)

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:[email-masked]]
> > Sent: Wednesday, November 06, 2002 11:51 PM
> > To: James Huang
> > Cc: [email-masked]; [email-masked]'
> > Subject: Re: UDP-encapsulated IPsec Transport mode
> >
> >
> > James Huang <[email-masked]> 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, I
> > 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.
> >
>

_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext

---

From: Skip Booth <[email-masked]>
Date: Thu, 7 Nov 2002 22:30:33 -0500 (Eastern Standard Time)

-Skip