[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