Locator-ID split in a new transport protocol

It seems that the Internet engineers like to periodically revisit old discussions. For example, every year or so, there will be intense exchanges on the IETF mailing list on the continuous use of ASCII for formatting RFC. The discussion will explore a variety of options before choosing to just maintain the status-quo. Of course ASCII RFC is just one of these recurring topics. There are a couple more, notably the “ID-locator separation,” which periodically resurfaces as one of the opportunity that was supposedly missed during the selection of IP next generation, now IPv6.

The ID-locator separation argument is fundamentally about routing, and how to scale the routing infrastructure to match an ever larger Internet. In the current Internet, IP addresses have two roles. They tell the network the destination of a packet, i.e. the location of the target, and they tell to the TCP layer the context of the packet, i.e. the identification of the peer. The argument is that if we separated these two roles, for example by splitting the address in two parts, we could use one part as a host identifier that never changes, and another part as a “locator” that could be changed in time to accommodate multi-homing and mobility, or to facilitate NAT traversal. TCP connections would be identified by the identifier part, and that same identifier part could also be used by firewalls and other filters.

The proposal looks nice, but it is actually quite hard to deploy. The proposal makes most sense if the locators can be rewritten inside the network, e.g. when crossing the boundaries between management areas, but that can only be done if we design and deploy a new service that retrieves the adequate “locator” for the identifier. This seems expensive, and the practical solutions are merely variations of NAT, which only rewrite the locators when entering a “private” network. But more importantly, the proposals belong to the “infrastructure” category, i.e. new functions that must be deployed by everybody before anybody reaches the full benefits. That means deploying new TCP stacks in pretty much every host and every router of the Internet. We saw with IPv6 how long this kind of deployment takes. See you back in 10 years!

Even if we could actually deploy it, we would have to resolve two nasty issues, security and privacy. The current linkage of address and identification provides for a minimal form of security, by checking that the return address works. If host A sends a message to host B and receives back a valid response, host A has a reasonable assumption that the initial message was delivered to the intended address, and that the response is indeed coming from host B. The assumption is false if the packet routing was somehow hacked, but hacking packet routing is hard, so there is some level of precaution. If there is no linkage between location and identity, if locators can be changed at will, we lose that minimal security.

Today, hosts get new addresses when they move to different network locations. That provides some measure of privacy. Of course hosts can still be tracked by other means, e.g. cookies, but at least the address is different. If we give hosts a strong “network identifier” that will not change with network location, we enable a new way of tracking. If the identifier cannot be changed, then network services can track users using their network identifier, even if these users take the precaution of destroying the web cookies in their browsers. Of course, the privacy issue could be mitigated by changing the identifier often, but that is contradictory with the idea of a stable identifier and a variable locator.

The more I think of it, the more I believe that the locator-ID split would be better addressed by building the ID in the transport protocol, instead of trying to redefine the network layer. Basically, the IP addresses with all their warts and their NATs become the locators, and the identifiers are entirely managed by the transport protocol. Of course, changing TCP is just as hard as changing IP, but we don’t necessarily have to “change TCP.” There can only be a single network protocol, but there can definitely be multiple transport protocols. We could define a new transport protocol for use by applications that want to manage multi-homing and mobility, or even NAT traversal. The broad lines are easily drawn:

  • Each connection has its own identifier, a large number that is independent of the IP addresses used to route the packet.
  • The identifier is negotiated during the initial exchange, using some cryptographic procedure.
  • The cryptographic procedure generates a secret key used to prove the authenticity of packets.
  • Packets can be sent or received through any pair of IP addresses, as long as they arrive to the destination.
  • Apart from the change in identifiers, the protocol behaves like TCP.

This will provide a large part of the advantages of the id/loc separation, without requiring any update to the network nodes. If I had to design it now, I would define an encapsulation on top of UDP, so that the packets could be sent across existing NAT. In fact, adding a NAT traversal function similar to ICE would enable deployment behind NAT. The main issue there is the design of the connection identifier negotiation, and its linkage to some form of host identity. There are many possibilities, from variations of Diffie-Hellman to designs similar to TLS. Clearly, that needs some work. But we would get a secure transport protocol that supports multi-homing, renumbering, mobility and NAT traversal. Seems like we should start writing the Internet drafts!

Advertisements

About Christian Huitema

I have been developing Internet protocols and applications for about 30 years. I love to see how the Internet has grown and the applications it enabled. Let's keep it open!
This entry was posted in Uncategorized. Bookmark the permalink.

7 Responses to Locator-ID split in a new transport protocol

  1. jariarkko says:

    At the 10.000 feet viewpoint, multipath TCP seems to do what you want. Or at least could. Have you looked at that, and any thoughts on whether you think it could satisfy your needs?

  2. Scott Brim says:

    (1) See my repy on Facebook. (2) NAT is the bane of all, but there are ways to get through even the old ones, by encapsulating the real transport protocol in UDP or TCP or HTTP — see Jana Iyengar’s “minion mode” work. (3) for MPTCP and security see associated work on “tcpcrypt”. And finally (4) SCTP does everything better. 🙂

  3. Please allow me to leave some idea relationg to ID/locator separation, which is not the reply.
    All methods listed in RFC6115 are strongly expected to help resolve current and/or future challenges relating to routing architecture of the Internet. LISP can support multi-homing, but does not explain how to suppress possible explosion of size of routing tables used in the Internet. I have reported “(Basic Idea of) Routing architecture for capsulation network”, with my acquaintance, that provides the solution for the routing table size problem, which is available at http://www.obn.dsri.jp. (select “English”, next click “Papers of OBN Architecture”, and you may get the target. )
    Outline is as follows. All address masks inside routing tables should be the same value across the capsulation network, such as “255.255.255.0”, and delete a field for address mask from routing tables. Edge nodes with en-/de-capsulation are placed at edge of network. Routers and edge nodes are called “node”. Rename “address-prefix” of capsulation address to NA (node address), and “host address” to EA (end point address). Routers should carry out its operation using only the NA. Multiple end points (EPs) are given to individual edge node, and each EP is used to identify a logical point to connect a circuit to a kind of user site. Size of routing tables depends only on the number of nodes, i.e., routers and edge nodes. The size of routing tables remains unchanged even if the number of sites, address-prefix of each site are altered. The method is a kind of ID/locator separation.

  4. I add some idea to the comment reported in March.
    (1) Consider a large-scale communication network (a backbone) supporting a fair amount of users, where every router maintains a map of the entire address space so it knows where to forward each packet. In this case, a better routing method that can definitely suppress the size of routing tables held in routers is essential.
    (2) Let us see another type of routing mechanism (called junction routing here) that can be implemented at junctions, of highway-based traffic networks. Here, we assume that a junction corresponds to a router, and a car to an IP packet. When a car reaches a junction at which it is to select its route, the car can use the location information (a kind of address) of the next junction or the location information of the interchange at which the car wants to leave the highway and take an ordinary road (not highway). The important point is that junction routing can be implemented by using only location information of junctions and/or interchanges. That is, no kind of address information that corresponds to “address-prefix” in case of communication network is necessary.
    (3) Applying the above idea to capsulation network, we have a new routing mechanism. The key point is that capsulation addresses should include addresses made of location information of a router (corresponding to a junction) and/or an edge node (corresponding to an interchange). The capsulation addresses should not include any address information generated at user sides, i.e., outside of the capsulation network.
    (4) Outline of the new routing mechanism is as follows. Consider a capsulation network with edge nodes having IPv4 en-/de-capsulation functionality. All address masks inside routing tables in routers should be the same value across the capsulation network, such as “255.255.255.0”, so the field for address mask can be deleted from the routing tables. Routers and edge nodes are called “nodes”. Rename “address-prefix” of capsulation address to NA (node address), and “host address” to EA (end point address). Routers should perform their intended tasks using only NA. Multiple end points (EPs) are given to each individual edge node, and each EP is used to identify a logical point to connect a circuit to a kind of user site.
    (5) Routing table size depends only on the number of nodes, i.e., routers and edge nodes. The size of routing tables remains unchanged even if the number of sites, address-prefix of each site, are altered. The method is an embodiment of the ID/locator separation, which can support existing IPv4 communications, and IPv6 if necessary.
    (6) Explanatory slides and technical reports are available at http://www.obn.dsri.jp. (Select “English”, next click “Papers of OBN Architecture” and you may get the target.)

  5. Scott Brim says:

    Dear Shoji: I haven’t looked at your papers yet but I will. I suspect that there is a lot of overlap with previous proposals. However, while your approach may help with routing scalability, it does not deal with ID/locator separation. ID/locator separation is not a routing problem. Rather, the problem is identification functions that use location-dependent information as inputs. Also, identities are used at multiple layers, in multiple contexts, and all of them are useful. Since this blog entry was first posted, ILNP has been published and is looking good, but every application uses some form of identity for various reasons including session sustainability. The natural home for most identity use in the Internet seems to be in the session or transport layer, but there is also a use for identities at lower layers.

  6. Dear Scott: Thanks for your comment. Sorry that April’s comment includes the report in March, so please ignore the latter. I hope you could have time to check slides expaling the method ploposed.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s