Much Earlier, Tony Li wrote: >> Given that ILNP identifiers are not global, >> doing identification purely on identifier >> is not going to help.
This is precisely true, but a bit misleading. ILNP has 2 different classes of Identifier, global-scope and local-scope. The normal case is to use a global-scope Identifier. The binding between the Identifiers and the Locators for a node, and between the FQDN and both Identifiers and Locators can all be cryptographically authenticated using DNSsec. (Maybe 2 years ago, it was not so clear that DNSsec deployment would happen soon, but actually the speed of DNSsec deployment is quite rapid now, so using DNSsec is quite reasonable for ILNP.) The local-scope Identifier capability exists primarily to handle uncommon special cases (e.g. people who want to use CGAs, or who want to use HIP-like Identifier values [e.g. based on a hash of a public key]) or who have some other special use model. As with all choices, the choice to deploy a local-scope Identifier has implications for the deployment overall. There is a single bit in the EUI-64 which indicates whether a given EUI-64 is local-scope or global-scope. So it is trivial to determine which scope a given Identifier value possesses. Tony's original comment is precisely correct in that when one is using a local-scope Identifier there is an extremely small, but non-zero, probability that 2 nodes would accidentally generate the same Identifier value in overlapping timeframes. However, by the existing ARP and Neighbour Discovery (ND) mechansisms, it is NOT possible for 2 nodes to use the same Identifier on the same subnet (i.e. with the same Locator value) at the same time. Now, as [CERT CA-1995-01] explained 15 years ago, it is already both trivially easy and common to forge IP addresses. The same half-hearted risk reduction measures that are (partly) deployed today, namely uRPF checks, work equally well with Locator values as they do with the routing prefix portion of the IP address. So if one applies existing uRPF checks against Locator values (which is only sensible and no additional implementation work or deployment work than the existing uRPF checks) and then uses the Identifier in the place of the IP address in one's rule set, one gets equivalent security and equivalent assurance as with today's deployed IP Internet. Now, if a node C is trying to impersonate another node A that is legitimately talking with B, the impersonation still won't work. If the packet with C's Locator and A's Identifier reaches B (and it ought not, since the ACL rule can be automatically updated - details below), then B will check the received ID & Locator values against its local session cache and discover that C's Locator is not associated with A's Identifier and realise that it is either a forgery or a new session connection attempt. This implementation issue is discussed at more length in one of the ILNP I-Ds. Later, Patrik Frejborg wrote: > But then we are back in the renumbering challenge, > if the partner changes his locator value I have > to change my rule base simultaneously This turns out to be trivial, because the partner will always send an ICMP Locator Update message, which can be authenticated, to provide the new Locator values. Since the seecurity appliance is along the path from source to destination, the security appliance will always see the ICMP Locator Update message and can update the set of valid Locator bindings by itself instantly.[1] We talk about this in one of the MILCOM papers in more detail than I am writing down in this note. Our example in that paper relates to NAT and updating the NAT session state, but there is no fundamental difference between updating NAT session state and updating an ACL rule. > - and we are not > really improving mobility here (either worsening it > from current solution). Actually, mobility is MUCH improved here, for the reasons I've outlined above -- dynamic changes to location automatically cause the ACLs to be instantly updated. > It would be nice if the identifier could be used to > limit access to my server farm, the final authentication > is then done (by e.g. IPsec) by the server. In the normal case it can be done that way, since in the normal case Identifier values are global-scope. > It seems that the firewalls should move towards > DNS based filtering solutions. Yes, and that is true even if none of the Routing RG proposals get adopted, because it mitigates risks in the current deployed Internet. > I'm exploring the capabilities and limitations of the > ILNP identifier, also renumbering - if renumbering could be > made easier we would have a business case at the enterprises. A good paper to read is [MILCOM09]. > We can't use the identifier at the firewalls to limit access > at a security zone, if we use locators we loose mobility > - both site and host mobility. That's not true, for the reasons I've outlined above. > But then we have host mobility, a cellco is not keen to let > the end user to roam over to another network that they can't > charge for - This is no longer true. The bandwidth pressures created by various "smart phones" mean that mobile phone operators are quite keen to encourage their users to migrate to WiFi if they roam to an area with good WiFi coverage (for example), at least for data traffic (Handoffs of voice telephony traffic to WiFi is still in flux in the marketplace). > thus the core locator do not change but the edge locator > will change when the device is moving at the cellco's > RAN (if you take the identifier mechanism to the future mobile > network architecture). I don't agree. The current approach to mobility is driven by Internet architectural constraints, and available engineering options, rather than by business models. Mobile phone operators already use the handset's identifier (e.g. GSM SIM ID) to ensure that both the carrier being roamed onto and the carrier the subscriber belongs to normally can bill, and settle cross-charges between operators, and that the subscriber in turn can be charged extra for roaming (if applicable to the subscriber's tariff). None of those capabilities are lost if using ILNP. In fact, several become simpler because ILNP has a location-independent ID, and existing IP addresses don't. (I'm not sure, but I think there is even an open specification of how one puts a GSM SIM ID into EUI-64 format.) Yours, Ran Atkinson ran.atkin...@gmail.com _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
