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

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



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?

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

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.

Steve