Re: 2401bis Issue #68 -- VPNs with overlapping IP address ranges

[Mark Duffy <mduffy@quarrytech.com>]

At 04:42 PM 9/18/2003 -0400, Stephen Kent wrote:
>Mark,
>
>>>Proposed approach:
>>>==================
>>>We recommend that IPsec implementations that support multiple subscriber 
>>>nets with overlapping private address spaces incorporate the following 
>>>capabilities:
>>>
>>>a. They MUST employ some local means to select the appropriate SPD for
>>>    each subscriber for outbound traffic
>>
>>That addresses your numbered item 1 above (for outbound traffic).  I 
>>think there should be a corresponding recommendation a' that addresses 
>>item #2 above (for inbound traffic).  E.g. "They MUST employ some local 
>>means to select the proper subscriber for inbound IPsec traffic."
>
>for inbound traffic, the SAD entry would use the negotiated VPN subscriber 
>ID to map, via some local means, to the right subscriber. Is that what you 
>have in mind?

Yes, exactly.  Or even in the event that the VPN ID is not negotiated but 
determined in some other, static way, then it still needs to use some local 
means to determine the proper subscriber.




>>>b. They MUST negotiate a VPN subscriber ID using IKE, as noted above,
>>>    to enable forwarding of inbound IPsec traffic after crypto processing.
>>>c. They SHOULD employ NAT, outside of IPsec, to accommodate bypassed
>>>    traffic.
>>
>>I agree that NAT is best done on the outside (black side).  But I 
>>question whether 2401bis should be saying so.  It seems to me that it is 
>>beyond the scope of IPsec.
>
>We're trying to be complete, but you are right that this is not purely an 
>IPsec issue. How about if we say that some means, e.g., NAT, is needed to 
>deal with bypassed traffic?

That's fine, it sounds a little less coercive.  The part about doing it on 
the black side was useful though.  Perhaps it could add that if NAT is 
done, it is usually advisable to do it on the outside, so that the SG can 
be configured based on the native addresses.


>Also, we should probably add a note re the assumed context, i.e., that 
>this model assumes that the subscribers with private address space are NOT 
>trying to communicate securely between nets where there would be address 
>space collisions.

Sure.
BTW, I think the VPN-ID aka context ID is useful even if the address spaces 
do not overlap.  Separation can be desirable even when overlapping 
addresses do not make it necessary.


>Steve

Thanks, Mark