[Hipsec] Pekka Nikander's personal view on HIP related discussions at DC
pekka.nikander@nomadiclab.com (Pekka Nikander) Mon, 15 November 2004 05:29 UTC
From: pekka.nikander@nomadiclab.com
Date: Mon, 15 Nov 2004 05:29:04 +0000
Subject: [Hipsec] Pekka Nikander's personal view on HIP related discussions at DC
Message-ID: <415EB47C-36FB-11D9-A88A-000D9331AFB0@nomadiclab.com>
X-Date: Mon Nov 15 05:29:04 2004
Folks, This collection of notes provides a _personal_ point of view to the discussions that I participated to during the DC meeting. Most probably contains some controversial issues; if you want to discuss those, PLEASE DO START A NEW THREAD and make sure that you redirect your responses to the appropriate list, either WG or RG. Thank you for keeping the mailing list discussions organised. Outline/Summary =============== - A lowest location-independent layer of identification - A and B, or the value of non-secure identifiers - What is core HIP? - DNS semantics - PATH, or HIP NAT traversal - Extending the idea of locator - Separation of signalling and data A lowest location-independent layer of identification ===================================================== In the good olde days, it was possible to use IPv4 addresses as universal identifiers for reaching *any* host in the Internet. As argued in more detail in the architecture document, this had a great value, just as such. Furthermore, this value has now been lost by the introduction of NATs, firewalls, IPv4 and IPv6 in parallel, mobility, address-based multi-homing, and a plethora of other things that break the "end-to-end", in some sense. Currently, people are trying to fix the situation by introducing new location-independent name spaces. Today, SIP identifiers are probably the most prominent example of this. However, these new identifiers tend to be located at the application layer, and tend to be, at least to an extent, application specific. If we could engineer and *deploy* a new *lowest* layer that provides universal, location-independent identifiers, that might re-establish the end-to-end connectivity that we used to have. While SIP provides such a service in a limited way, it might not be at the right place in the stack. On the other hand, there seems to be more momentum currently behind SIP, and in the usual Betamax vs. VHS fashion, SIP may be good enough so that few if any people bother even to try HIP. Punch line: Let's make HIP to go through current middle boxes at least as well as SIP does! A and B, or the value of non-secure identifiers =============================================== Right now, HIP seems to provide two "services" at its core. It aims to provide identifiers that A. have a cryptographically strong binding to a public key, and B. have a location-independent end-to-end semantics, at the lowest possible layer in the stack. There might be some value in separating A and B, and allowing upper layers to select either A+B or just B. B would provide enough security just to protect innocent bystanders from flooding and other related attacks that might be created by B itself. A+B, on the other hand, would provide the full package, i.e., that "You know whom you are talking to", where whom is defined by the public key. That is, you know that you are talking to whoever/whatever possesses (a copy of) the private key corresponding to the public key that you are using a reference. Punch line: Let's make sure that *someone* (multi6?) provides plain B, too. What is core HIP? ================= An important question raised on Saturday's workshop was that of what is "core" to HIP? In a way, this was a reaction to people using the term "HIP" to denote anything that is taking place at the working or research groups. That seems to be confusing. Hence, we should define in specific terms what are the fundamental properties of HIP and what are features that are build on the top of that. As a starting point, I would propose the following: - A+B, from above, is core - being the *lowest* location-independent layer is core - the *idea* of location-independence (such as in middle box traversal) is core - the specific mechanisms for traversing specific middle boxes are NOT core - the *idea* of location-independence (such as in mobility) is core - mobility and multi-homing, as defined in the mobility and multi-homing draft, are NOT core - even the idea of rendezvous is NOT core but just as something that is needed for location-independence The fact that HIP will eventually require us to reconsider the placement of various functions, such as congestion control, in the stack, is a feature and not a bug. Hence, it is a direct consequence of what is core to HIP. Punch line: Use "lowest location-independent" as Occam's razor! DNS semantics ============= Today, a (leaf) DNS name defines a service, not a host. In many cases, the same service is provided by many hosts. The current practise is to list the IP addresses of all of the hosts providing to that service under the given DNS name. This is the semantics that HIP must conform to. There is a separate thread on this on the WG mailing list, so no more on this here. Punch line: Don't tell me what to put in my DNS! Preferred Alternatives to Tunnelling HIP (PATH) =============================================== I have changed my mind on HIP legacy NAT traversal. Two years ago I opposed it on architectural bases. A year ago I would not have done it myself but didn't oppose it any more. Now I am doing it. To make HIP the lowest location-independent layer in today's networks, we must make HIP to go through current NATs and firewalls. While making pinholes through firewalls seems like an arms race, there is no question in the value of making HIP to go through current "convenience" NATs. Those NATs are primarily there to solve the address space problem, and there are a hoard of applications that already make it possible to open a connection to a host behind a firewall. STUN, ICE and other specifications already define how you should do that, for your application. Let's make this application independent, allowing you to use both existing and future applications without having to worry about NATs. Given that we can directly employ the mechanisms in STUN and ICE, this seems to be a relatively easy piece of work, now. That might not have been the case two years ago. In the future, we can probably lean even more to the work in produced by the BEHAVE and other working groups, without spending too much cycles on making this clean and mean. Basically, we agreed to write two drafts: 1. Packet formats for HIP over UDP and UDP as locator. 2. A document specifying a STUN-server like HIP rendezvous server, and the protocols that you use to register to the server and making HIP connections to the host behind the NAT with the help of such a server. Both documents should be relatively short, as they can mostly rely on work done elsewhere. Punch line: Make UDP based NAT traversal a trivial combination of methods developed elsewhere. What is a locator? ================== As a starting point, HIP was designed to function on the top of the two versions of IP, providing connectivity over both of them. Unfortunately, IPv4 does not provide end-to-end connectivity today. Instead, one must use various kinds of hacks, like tunnelling other protocols on the top of UDP. To keep the HIP architecture relatively clean, it looks preferable to model all the different means of providing end-to-end connectivity as locators. That is, whenever there is an "address", i.e. a piece of information that allows one to make a connection, this is modelled as a locator. The first such locator type to be defined would be for HIP-over-UDP tunnelling. Basically, this requires one to convey information about IP addresses and UDP ports, and their usage; should a given port be used for HIP traffic, for ESP traffic, or for both? If the latter, how exactly one should determine whether a received packet is a HIP or an ESP packet? Hence, to me it looks like that we want to generalise the notion of locator, making HIP an universal non-tunnelling tunnelling protocol. That is, providing HIP with the generic hooks that allow HIP to traverse all the imaginable kinds of protocols, providing the "HIP connectivity service" on the top of that. Note that while we use here tunnelling like mechanisms, this is not really tunnelling in the sense that we are providing something more than what is available below the tunnel, the A+B property from above, and we also provide the property of mobility across these various tunnelling methods. As a result, I think that we should define an extensible locator data type, to be used the REA payload. Additionally, it *might* make sense to define a new DNS resource record that allows one to store these additional locators into the DNS. OTOH, my current feeling is that it is too early to propose the new DNS resource record. We might as well try to get some operational experience with rendezvous and mobility based NAT traversal mechanisms first. Punch line: HIP over Anything and Everything (HAE) Separation of signalling and data ================================= The way HIP is currently defined provide a convenient way of separating signalling and data traffic. Basically, host-to-host signalling traffic is carried within the HIP protocol while data traffic is carried within the ESP protocol. In the future, I surmise that we will support other data protocols but ESP, too. As we now aim to support legacy NAT traversal, we probably need to provide some more flexibility on this. For example, we may want to provide one UDP port for HIP traffic while using another one for ESP traffic. More generally, we may want to express that one particular locator is only valid for HIP traffic while the other locator may be used for ESP traffic. Even more generally, we probably want to add capabilities to locators, allowing us to express explicitly what each locator is good for. The telecom people will love this, I am sure. Finally they can understand TCP/IP, at least when HIP is used :-) Punch line: Let's make HIP appealing both to Internet and Telecom folks :-) --Pekka
- [Hipsec] Pekka Nikander's personal view on HIP re… Pekka Nikander
- Locators (Was: Re: [Hipsec] Pekka Nikander's pers… Jari Arkko
- [Hipsec] Re: Locators Pekka Nikander
- [Hipsec] Re: Locators Pekka Savola
- [Hipsec] Re: Locators Pekka Nikander
- [Hipsec] Re: Locators Pekka Savola
- [Hipsec] NAT details (was Locators) Pekka Nikander