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

RE: Another field for traffic selector?



Radia, thank you.  What you propose sounds fine.

However, I will make a small pitch here for the globally unique VPN-ID:
In a PPVPN (provider provisioned VPN) view of things, the "firewalls" may 
be called "Provider Edge devices" (PEs).  And a number of these may 
participate in a VPN membership discovery scheme in which they learn which 
VPNs (by VPN-ID) are "present" in which PE devices.  Then they might 
initiate IKE signalling amongst themselves, using this super-duper 
capability to bind the SAs to VPN contexts.  A 2-octet VPN-ID would be very 
limiting in this environment because  a) a given network operator might 
service more than 64K VPNs, and  b) if used in an interdomain environment 
it would not be practical to ensure the uniqueness of locally-significant 
2-octet VPN-IDs.  Globally unique RFC 2685 VPN-IDs would solve this nicely.

BTW, the rfc 2685 VPN-IDs are hierarchically structured, consisting of an 
organization number, and a VPN number from a space maintained by that 
organization.  So I don't think the length of the thing per se should lead 
to configuration errors -- in scenarios such as the one you describe, that 
don't need all that uniqueness, the high order bits would just be a 
constant.  Looked at another way, if IKE permits an opaque 8 octet field, 
it can be up to whoever is operating the equipment what to use as 
VPN-IDs.  They can still use e.g. 71, 22, 3, 1, etc.

--Mark

At 07:20 PM 3/12/2003 -0500, Radia Perlman - Boston Center for Networking 
wrote:
>OK. Let me summarize the issue and what I'll propose
>as the solution, and try to answer all the comments.
>
>The issue: two firewalls F1 and F2 are creating VPN service on behalf
>of multiple customer nets (C1, C2, C3, C4),
>and the nets have the same IP address
>space (can be overlapping, can be identical ranges...point being
>that an IP address is no longer unique for F2 to know who
>to deliver a packet to). Let's say that all customer nets have
>the address range 10.1.1.0-10.1.2.255.
>
>Within a customer net the addresses are unique, but between
>them they are not.
>
>F1 and F2 are trusted to glue together the pieces of C1, C2, C3, and C4,
>but they won't know which is which based solely on addresses.
>
>*********
>The proposed solution:
>
>1. Use a "VPN-ID" which need not be globally unique. It only has
>    to be such that F1 and F2 know which customer is being referred to.
>
>    If F2 and F3 have a similar topology, they could, in theory, map
>    customer net Cn to a different VPN-ID than Cn was assigned between
>    F1 and F2.
>
>    I prefer something where we don't need globally unique VPN-IDs, since
>    it takes fewer bytes, and because I suspect fewer errors will be
>    made when configuring a 2-byte quantity than a 7-byte quantity.
>    I imagine the firewall administrator knowing that they have
>    customers C1, C2, C3, and C4, and assigning them the numbers
>    71, 22, 3, 1, and it's just necessary that "C4" get assigned the
>    same number at F2 as at F1.
>
>    But if we have globally unique ones, that's fine too.
>    Mark Duffy says if we want to copy RFC 2685 it would take
>    7 bytes, or to copy RFC 2547 would take 8 bytes).
>
>2. The VPN-ID does NOT appear in data packets. It only exists in the
>    IKE negotiation for the child-SA. "I'd like to create an ESP tunnel
>    with SPI x, and IP address range k-j, with VPN-ID 7".
>
>3. F2, when it receives a packet from F1 over SPI x, knows that it
>    needs to get routed to the customer net that has been assigned VPN-ID 7.
>    The VPN-ID is implicitly known based on the SPI.
>
>4. Since on a particular SA, there should be no possibility of mixing
>    traffic from multiple VPNs, the field shouldn't go in the traffic
>    selector (which can appear multiple times if there are multiple
>    IP ranges) but instead, I'd claim, in the "Traffic Selector Payload"
>    (section 3.13 of IKEv2 spec). There's currently a 3-octet "reserved"
>    field. I'd suggest using 2 octets of that for VPN-ID, and not
>    have globally unique VPN-IDs (the assumption being that firewalls
>    wouldn't have more than 2^16 VPNs...if not, we can use all 24 bits).
>
>*****************
>Comments on various people's comments, if I think the above doesn't
>answer the comments...
>
>1) packets do not need to be verified as coming on a particular virtual
>net. Assuming there is end-to-end IPsec as well as firewall-to-firewall,
>packets would just get lost if misrouted, since the key wouldn't work.
>If there is only firewall-to-firewall IPsec, then you were trusted
>the firewalls anyway, and the firewalls can (as they could without
>VPN-IDs) modify IP addresses, route between the VPNs, etc.
>
>2) Why does it need to go into IKEv2?...because otherwise there's
>no way to route the packets, if the IP addresses in the customer
>nets overlap.
>
>Radia