[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: NAT and IPSEC issues:- Question

[Also forwarded to IPsec list]

Thanks for your replies.

My original question (IPsec over L2TP thru NAT) was aimed at squeezing IPsec
through a NAT; I was interested to see whether L2TP was a reasonable way of
doing this.

If I may forget L2TP altogether, please consider the following scenario:

- IRAC using tunnel mode ESP to SGW
    (no AH protection of 'outer' IP addresses)
- IRAC 'virtual' IP address assigned by DHCP via SGW
    (and so no UDP checksum problems)
- No Pre-Shared key authentication in IKE MM
    (and so no IP addresses used as identifiers)

In this scenario, so far as the IPsec user plane is concerned, the main
problem is how to reliably route incoming IPsec traffic from the SGWs to the
stub-domain private IP addresses of the IRACs. (I appreciate that this may
be a crass simplification. Please let me know if it is!)

Couldn't the SPIs be used for the public->private address mapping?

Of course, the problem here is that the NAT box doesn't assign SPIs, and so
a collision situation may exist if two IRACs choose the same SPI for
incoming IPsec sessions.

(And just for clarification, I'm thinking IPsec-customised-NAT, not
traditional NAT).

If the IRAC could be persuaded to request an available SPI from the 'NAT'
box, wouldn't this resolve the problem?

What other problems remain to be tackled in this IRAC tunnel mode ESP
scenario?

There's got to be a way...

Mick

(now on vacation for a week - my responses to any replies won't be speedy!)


> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com]
> Sent: 16 May 2000 10:13
> To: 'Stephane Beaulieu'; Gallagher, Mick; ietf-ipsra@vpnc.org
> Subject: RE: NAT and IPSEC issues:- Question
> 
> 
> > Looking at the problems mentioned, would it be fair for me 
> to assume that
> > running IKE/IPsec over L2TP is a feasible solution?
> 
> There are several issues with making L2TP/IPSEC NAT friendly. One
> is UDP checksums. These need to be turned off on the sender and/or
> ignored on the receiver, or the incoming L2TP packets will be
> discarded. 
> 
> Another issue is IKE. The source port needs to be floated in order
> to permit the NAT to properly de-multiplex a re-key. It will also
> be necessary not use IP addresses as identifiers
> in IKE MM. Similarly, there are issues in IKE QM (see the 
> IPSEC/L2TP security draft for a description of the filters). 
> 
> Finally, there is the issue of floating the server L2TP port.
> This is necessary in case there is more than one L2TP client
> behind a given NAT. Otherwise, there will be two IKE MMs up
> with the same filters and addresses and so the L2TP server
> could send the packets down the wrong IKE QM SA.
> 
> The next revision of the L2TP/IPSEC security draft will discuss
> these issues in more detail.  
>
Follow-Ups: