Subject: [L2tpext] UDP-encapsulated IPsec Transport mode

From: James Huang <[email-masked]>
Date: Wed, 6 Nov 2002 16:11:46 -0800

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).

Regards,
James C. Huang

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

---

From: James Huang <[email-masked]>
Date: Thu, 7 Nov 2002 11:01:33 -0800

> -----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
> 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.
>

---

From: James Huang <[email-masked]>
Date: Thu, 7 Nov 2002 11:01:33 -0800

Agreed.

- James Huang

---

From: James Huang <[email-masked]>
Date: Fri, 8 Nov 2002 10:27:39 -0800

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?   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?

Thanks,
- James 

> From: Skip Booth [mailto:[email-masked]]
> Sent: Thursday, November 07, 2002 7:31 PM
> To: James Huang
> Cc: 'Markus Stenberg'; [email-masked]; [email-masked]'
> 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:
> 
> >
> >
> > > > IPsec transport mode tunnels behind a NAT box.  However, 
> > > did not find any

---

From: James Huang <[email-masked]>
Date: Fri, 8 Nov 2002 10:27:39 -0800

Skip,

Thanks,
- James

---

From: James Huang <[email-masked]>
Date: Fri, 8 Nov 2002 14:51:18 -0800

> Sent: Friday, November 08, 2002 12:09 PM
> To: James Huang
> On Fri, 8 Nov 2002, James Huang wrote:
> 
> > Skip,
> > 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?

Regards,
James Huang

> > The checksum was originally computed by the client using its
> I don't the CRC fixup has anything to do with Appendix A.
> 
> -Skip
> 
> >
> > Thanks,
> > - James
> >
> >

---

From: James Huang <[email-masked]>
Date: Fri, 8 Nov 2002 14:51:18 -0800

Skip,

Regards,
James Huang

---

From: James Huang <[email-masked]>
Date: Fri, 8 Nov 2002 15:26:19 -0800

Satyadeva,

	I thought about NAT-NA too.  But I think the better idea which can
do without NAT-NA is as follows:
(1) The security gateway (SG) will insert entries into its filtering
database based on the traffic selector (ID) specified by the client during
the QM exchange.
(2) After the SG decrypted and decapsulated an UDP-encapsulated IPsec packet
in the transport mode (i.e. removing the outer UDP header and ESP header),
it will modify the source IP address in the outer IP header using the
address in the NAT-OA payload it received in the QM exchange.  

With this scheme, the packet after decapsulation will pass the security
policy at the SG and the checksum in the inner UDP/TCP header no longer need
to be re-computed by the SG as was described in section 3.1.2 in the draft.
Also it will solve the issue of multiple clients behind the same NAT box
described in section 5.3.

The above  is my personal opinion.  I hope the authors of the draft can
provide more clarification.

Regards,
James Huang

> From: Satyadeva Konduru [mailto:[email-masked]]
> Sent: Friday, November 08, 2002 2:51 PM
> To: James Huang; [email-masked]; [email-masked]
> James,
> Will there be any problem if the gateway (or any peer) treats 
> the NATed
> public address as the Phase 2 traffic selector, ignoring the private
> address sent by client ? Obviously, the private address is of 
> no use to
> the gateway. Even the SPD lookup policy is based on the NATed 
> address. 
> 
> One other way the authors could have pursued is: the IKE 
> gateway sending
> the NATed address (NA) to the client in the Phase 1 as a 
> NAT-NA payload.
> This way, the client will get to know of its public address. But since
> the NAT-NA can dynamically change, the gateway has to send the NAT-NA
> payload every time the NATed public address changes.
>
> -Satyadeva Konduru
> 
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of James Huang
> > Sent: Wednesday, November 06, 2002 4:12 PM
> > To: [email-masked]; [email-masked]'
> > Subject: UDP-encapsulated IPsec Transport mode
> > 
> > Hi all,
> > IPsec transport mode tunnels behind a NAT box.  However, I did not
> find
> > any
> > the client sends out during quick mode exchange, should the 
> client use
> its

---

From: James Huang <[email-masked]>
Date: Fri, 8 Nov 2002 15:26:19 -0800

Satyadeva,

Regards,
James Huang

---

From: James Huang <[email-masked]>
Date: Fri, 8 Nov 2002 16:44:04 -0800

> Sent: Friday, November 08, 2002 3:52 PM
> Your suggestion will only "bypass" NAT but it will not "traverse" NAT.
> My understanding is that the SG should see only the NATed public
> address. If you take the transport mode in a larger context (not just
> L2tp/ipsec), let us suppose there is a host accepting TCP connections.
> As per your suggestion, if you replace the NATed address with NAT-OA,
> there would be multiple TCP connections from different 
> clients (all with
> the same private address) mapping to the same socket pair.
> 

Satyadeva,

	If these multiple clients use the same private address, then when
the server (LNS) receives an inbound  SCCRQ , it should have chosen a
distinct UDP port number for each client.
           If we take a larger context as you suggested where there is a
server running in the SG listening to a well-known TCP port.  If the above
multiple clients also chose the same TCP port number,  then I agree doing
NAT will not be enough.  In that case, the SG will have to do NAT (on the
inbound source IP address) + dynamic PAT (on the inbound TCP source port)
before passing a decapsulated inbound packet to the server.

-- James

> -Satyadeva. 
> > From: James Huang [mailto:[email-masked]]
> > Sent: Friday, November 08, 2002 3:26 PM
> > To: 'Satyadeva Konduru'; [email-masked]; [email-masked]
> > (2) After the SG decrypted and decapsulated an 
> UDP-encapsulated IPsec
> > packet
> > policy at the SG and the checksum in the inner UDP/TCP header no
> longer
> > need
> > > > discussion on another related issue:  In the traffic 
> selector (ID)
> > > payload
> > > > public IP address)?  If it the later, how does the client know
> about
> > > that

---

From: James Huang <[email-masked]>
Date: Fri, 8 Nov 2002 16:44:04 -0800

Satyadeva,

-- James

---

From: James Huang <[email-masked]>
Date: Fri, 8 Nov 2002 17:17:06 -0800

> Sent: Friday, November 08, 2002 5:07 PM
> >            If we take a larger context as you suggested 
> where there is
> a
> > NAT will not be enough.  In that case, the SG will have to 
> do NAT (on
> the
> I think you got me wrong here. In my example, the multiple 
> clients with
> the same private addresses lie behind "different NAT gateways with
> different public addresses" and hence a single NAT done by a 
> NAT gateway
> in the middle would suffice. Now as per your earlier suggestion of
> replacing the NATed public address with NAT-OA after UDP decapsulation
> does not make sense here, because, all the clients could possibly have
> the same private addresses and ports.
> 
> -Satyadeva
> 

No, I knew this is exactly what you are talking about.  That is why I said
NAT (on the inbound source IP address) using NAT-OA + dynamic PAT (on the
inbound TCP source port) is needed at the security gateway after
decapsulating the UDP/IPsec header.

- James

> > > > 	I thought about NAT-NA too.  But I think the 
> better idea which
> > > can
> > > > database based on the traffic selector (ID) specified by the
> client
> > > during
> > > > the QM exchange.
> > > > in the transport mode (i.e. removing the outer UDP 
> header and ESP
> > > header),
> > > > to be re-computed by the SG as was described in section 3.1.2 in
> the
> > > > draft.
> > > > Also it will solve the issue of multiple clients behind the same
> NAT
> > > box
> > > > The above  is my personal opinion.  I hope the authors of the
> draft
> > > can
> > > > > This way, the client will get to know of its public 
> address. But
> > > since

---

From: James Huang <[email-masked]>
Date: Fri, 8 Nov 2002 17:17:06 -0800

- James

---

From: James Huang <[email-masked]>
Date: Fri, 8 Nov 2002 18:13:56 -0800

> Sent: Friday, November 08, 2002 4:50 PM
> To: James Huang
> 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.

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.

-- James Huang

> > > > > advertised during the negotiation, the packet will passte
> > > > > through the SG filters.
> > > > > > > > some discussions on the issue of multiple 
> clients running
> > > > > > > UDP-encapsulated
> > > > > > > selector (ID) payload
> > > > > > > client use its
> > > > > > > > public IP address)?  If it the later, how does 
> the client
> > > > > > > know about that

---

From: James Huang <[email-masked]>
Date: Fri, 8 Nov 2002 18:20:22 -0800

> Sent: Friday, November 08, 2002 6:08 PM
> > No, I knew this is exactly what you are talking about.  
> That is why I
> said
> > NAT (on the inbound source IP address) using NAT-OA + 
> dynamic PAT (on
> the
> So, what you are suggesting is that a dynamic PAT be applied between
> IP/IPSec layer and the socket layer within a host. Two things:
> 1) Dynamic PAT will still involve checksum recomputation (however
> simple) which you wanted to avoid, right?? 
> 2) Also, I am not convinced that the solution has to be this 
> complicated
> when all you want to know is the Phase 2 traffic selector. NAT-NA
> payload type solution seems simple (to me, of course :-))
> 
> Anyway, why is the draft silent on this issue?? Either, it is too
> obvious to mention or didn't forsee this issue.
> 
> -Satyadeva.
> 

Satyadeva,

	I am not sure.  But in Appendix A of the draft, it did mention a
"build-in NAT/NAPT" soultion to solve the multiple clients behind a NAT box
issue.  The draft said that SSH/Microsoft has intellectual property rights
to the solution.  I am not sure whether the "build-in NAT/NAPT" soultion is
the same as what I described in my previous emails.

- James Huang

> > Sent: Friday, November 08, 2002 5:17 PM
> > > > server running in the SG listening to a well-known TCP port.  If
> the
> > > above
> > > > multiple clients also chose the same TCP port number,  then I
> agree
> > > doing
> > > > inbound source IP address) + dynamic PAT (on the inbound TCP
> source
> > > port)
> > > > > Your suggestion will only "bypass" NAT but it will not
> "traverse"
> > > NAT.
> > > > > address. If you take the transport mode in a larger 
> context (not
> > > just
> > > > > > With this scheme, the packet after decapsulation 
> will pass the
> > > > > security
> > > > > > policy at the SG and the checksum in the inner 
> UDP/TCP header
> no
> > > > > longer
> > > > > > need
> > > > > > to be re-computed by the SG as was described in 
> section 3.1.2
> in
> > > the
> > > > > > draft.
> > > > > > > the NAT-NA can dynamically change, the gateway has to send
> the
> > > > > NAT-NA

---

From: James Huang <[email-masked]>
Date: Fri, 8 Nov 2002 18:13:56 -0800

Skip,

Skip,

ip header: P1->P2, 

IP1: PC1->P2
UDP1: 4500->4500

-- James Huang

---

From: James Huang <[email-masked]>
Date: Fri, 8 Nov 2002 18:20:22 -0800

Satyadeva,

- James Huang

---

From: John Lindal <[email-masked]>
Date: Sat, 9 Nov 2002 15:42:28 -0800

> database based on the traffic selector (ID) specified by the client
> during the QM exchange.
>
> (2) After the SG decrypted and decapsulated an UDP-encapsulated IPsec
> packet in the transport mode (i.e. removing the outer UDP header and ESP
> header), it will modify the source IP address in the outer IP header
> using the address in the NAT-OA payload it received in the QM exchange.
>
> policy at the SG and the checksum in the inner UDP/TCP header no longer
> need to be re-computed by the SG as was described in section 3.1.2 in the
> draft.  Also it will solve the issue of multiple clients behind the same
> NAT box described in section 5.3.

So far, we at Trlokom have contented ourselves with pointing out the myriad
problems with the various versions of the existing draft.

However, the above proposal (specifically item #2 and all that it implies)
is so similar to what we have patented that we feel that we must raise the
IPR issue.  If this proposal or anything like it ends up in a future
version of the NAT traversal draft, it will violate our patents.  The same
goes for any implementation (independent of the draft) of the above
suggestion.

--
Sincerely,
John Lindal
Chief Software Architect, Trlokom, Inc.
http://www.trlokom.com/

---

From: John Lindal <[email-masked]>
Date: Sat, 9 Nov 2002 15:42:28 -0800

---

From: James Huang <[email-masked]>
Date: Mon, 11 Nov 2002 10:01:15 -0800

> From: Awan Kumar Sharma [mailto:[email-masked]]
> Sent: Sunday, November 10, 2002 11:52 PM
> To: 'Skip Booth'; James Huang
> Cc: 'Markus Stenberg'; [email-masked]; [email-masked]
> 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
> 
> 
> [mailto:[email-masked]]On Behalf Of Skip Booth
> Sent: Saturday, November 09, 2002 9:10 AM
> To: James Huang
> > Both the IPsec transport mode tunnel and the L2TP tunnel 
> are btw the PC
> and
> > the SG.
> >
> > from PC1 to P2 and UDP1 will be from 4500 to 4500, UDP2 
> will be from 1701
> to
> > this packet passed the NAT box, the IP header will be from 
> P1 to P2 and
> UDP1
> > 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.
> > pass the checking using the filtering database and the 
> checksum in UDP2
> will
> 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
> 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
> > > >
> > > >
> > > >
> > > >
> > > > > > > > > > own private address or the public routable 
> address (i.e.
> > > > > > > > > the NAT box's
> > > > > > > > >  within the NAT-OA payload so the checksums 
> et al can be
> > > > > > > corrected.
> > > > > > > > >
> > > > > > > >
> > > > > > > > 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
> > > > > > > > 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
> > > > > > > > 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
> > > > > > > > > "Every program has (at least) two purposes: 
> the one for
> > > > > > > which it was
> **************************************************************
> *************
> 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.
> **************************************************************
> *************
>

---

From: James Huang <[email-masked]>
Date: Mon, 11 Nov 2002 10:01:15 -0800

Regards,
James HUang