[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 2401bis issues (possible) resolution
At 01:38 PM 10/7/2003 -0400, Angelos D. Keromytis wrote:
In our weekly teleconference, we discussed the following items from the
68 VPNs with overlapping IP address ranges
We believe that these items are implementation-specific and/or not applicable
to implementations in general (this applies in particular to 50 and partially
to 68). We invite one last round of comments on these items --- if you feel
Hi Angelos and list,
As invited, I am yelling :-)
#68 (as I think you have acknowledged) consists of multiple parts, some of
which are implementation issues but not all. Part of #68 involved a
capability in the protocol:
b. They MUST negotiate a VPN subscriber ID using IKE, as
noted above, to enable forwarding of inbound IPsec
traffic after crypto processing.
When a security Gateway is operating on behalf of multiple contexts (e.g.
multiple subscribers, or multiple ppvpn-style overlay addressing contexts),
it is essential that the initiator be able to convey to the responder which
context is being addressed. In the absence of a capability to signal this
in IKE, the only full-functioned alternative is for the SGs to maintain a
separate IP address to use for each supported context. This can waste a
lot of addresses, and it isn't even as good anyway because it requires
coordinated configuration on both ends to understand which IP address in
each SG corresponds to which context.
My conclusion: 2401bis should support the concept of multiple contexts
supported in an IPsec device, and IKE should provide a means to convey the
desired context in the initial exchange.