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

RE: NAT and IPSEC issues:- Question





Actually, the SPI that the responder uses is chosen by the initiator,
which is what allows RSIP to allocate disjoint SPIs to clients.

-Mike





"Bernard Aboba" <aboba@internaut.com> on 05/24/2000 08:38:36 AM

Please respond to aboba@internaut.com

Sent by:  "Bernard Aboba" <aboba@internaut.com>


To:   "'Gallagher, Mick'" <mick.gallagher@roke.co.uk>, "'Stephane Beaulieu'"
      <stephane@cisco.com>, "'Waters, Stephen'" <Stephen.Waters@cabletron.com>
cc:   ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com (Mike Borella/MW/US/3Com)
Subject:  RE: NAT and IPSEC issues:- Question



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

L2TP is only relevant in how it influences the negotiated filters.

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

I believe that this issue is covered in draft-ietf-ipsec-dhcp-05.txt. The
SGW (which acts as a DHCP Relay) needs to track which IP addresses have been
assigned to which tunnels, and plumb routes for them.

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

On the NAT side, the NAT needs to figure out how to de-multiplex the
incoming IPSEC traffic, which all has the same IP Protocol (ESP) and
outer source address (the SGW). It uses SPIs for this. The NAT also
needs to de-multiplex the incoming IKE traffic (rekeys). In NAT
WG we discussed use of IKE cookies for this but concluded that to
handle rekeys we needed to float the IKE source port.

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

Yup. This is why the RSIP/IPSEC specification allows the RSIP server
to inspect the chosen SPIs to check for conflicts.

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

No, because the SPI is chosen by the responder. But the NAT could check
the SPI and inform the client if it was in conflict. That is what RSIP
does.

>There's got to be a way...

This is working in shipping software today, so indeed there must be :)