TBD (TBD)

Chairs

The TBD Co-chairs are Pekka Nikander <pekka.nikander@nomadiclab.com> and Tom Henderson <thomas.r.henderson@boeing.com>.

Mail List

The Research Group initially shares a mailing list with the IETF Host Identity Protocol working group. The email list is <hipsec@honor.trusecure.com>. To subscribe, visit the Hipsec mailing list info page or send an email to <hipsec-request@honor.trusecure.com>.

An archive of the email list is available at Hipsec archive.

It is expected that the research group mailing list will be split from the HIP WG mailing list once both groups are well running and established.

Background

The current Internet architecture is based on using IP addresses in two distinctive roles.

• From the network point of view, an IP address names the current topological location of an interface that host has attached to the network. That is, an IP address is used as a name for the location where a specific network interface can be found. If a host moves around and attaches its network interface to a different location, the IP address associated with the interface changes. This role is often called the locator role.
• From an application point of view, an IP address identifies a host. That is, an IP address is is used as an identifier for the peer host. It is expected that this identifier remains stable as long as the association is active. This role is often called the identifier role.

Due to the increased mobility and multi-homing requirements, together with some other issues like IPv4 address scarcity, this dual role of IP addresses is becoming problematic. The generic phenomenon was previously studied at the IRTF NameSpace Research Group (NSRG), and the questions studied there are outside of the scope of this group.

The Host Identity Protocol (HIP) is a piece of development that has happened alongside the IETF and the IRTF for a few years. Its development has been partially based on the discussions that took place at the NSRG. Basically, HIP is a concrete proposal for adding a new name space to the TCP/IP stack. The new name space consist of Host Identifiers, which are cryptographic public keys. The HIP architecture adds a new layer between the IP layer and the transport layer, thereby decoupling the layers from each other, and splitting the dual roles of IP addresses. When HIP is used, IP addresses function as pure location names. Instead of IP addresses, the applications use Host Identifiers to name peer hosts. More concise representations of Host Identifiers, 128-bit Host Identity Tags (HITs) and 32-bit Local Scope Identifiers (LSIs), have been defined to represent host identities in IPv6- or IPv4-sized address structures, respectively, allowing most but not all legacy applications to work unmodified on top of HIP.

The IETF Host Identity Protocol working group is being chartered to complete the short term engineering work on HIP, including the base protocol specification, basic mobility & multi-homing, basic rendezvous service, and the basic DNS records needed to store HIP related information.

Charter

The TBD Research Group has two fundamental, slightly different goals.

• The RG shall study the proposed Host Identity Protocol and architecture, and their potential effects on the Internet. When deemed so, the RG can suggest extensions and modifications to the protocol and architecture.
• The RG shall study, in a wider sense, the consequences and effects that wide scale adoption of any type of separation of the identifier and locator roles of IP addresses are likely to have.

As its final result, the research group shall produce an experiment report, giving a recommendation to the IETF on the mechanism(s) for separating the identifier and locator nature of IP addresses. That is, given the assumption that some kind of identifier and locator separation should be adopted, this research group shall give an recommendation on a baseline architecture and mechanism on which standardizing such separation should be based on.

The question of whether the background assumption is valid or not falls mostly beyound the scope of this research group. That is, the group must not spend excessive amount of time discussing whether such a separation of roles is needed or not. The group work is based on the assumption that such separation is needed, in a form or another. On the other hand, it is perfectly fine to discuss any technical drawbacks that such a separation might have, and to study alternatives.

The range of topics that the research group may pursue is relatively wide, including (but not limited to) the following ones.

• Development of other identifier / locator separation mechanisms besides HIP
• Comparisons of HIP and other identifier / locator separation mechanisms
• Studies on how HIP changes Internet traffic patterns
• Comparisons of HIP and other mobility and multi-homing mechanisms
• Studies on privacy and security effects that HIP may have
• Studies and prototype designs on additional mechanisms, such as
  • mechanisms for referrals using HITs as host identifiers
  • mechanisms for HIT based flat overlay routing
  • mechanisms for security policy control using HITs
  • mechanisms for HIT based firewalls and NAT devices
• Studies on how HIP might help with other current IETF design tasks, such as moving networks (nemo), multi-cast and anycast, etc.

The experiment report will be the main deliverable from this research group. The report is expected to document collective experiences and lessons learned from all other studies, experimentation, and designs completed at the research group. Its main result is to report the following.

• Recommendation for a baseline architecture and protocol for standardizing the separation of identifiers and locators.

  It is expected that people will continue to work with other architectures and mechanisms for separating the identifier and locator roles of IP addresses but HIP. While HIP appears to be the most mature mechanism at the time of founding this research group, the situation may well change. The experiment report shall include an objective comparison of HIP and other mature mechanisms, and a recommendation of which of them should be adopted as the baseline for future standardization.

• Would introducing the identity / locator mechanism as an Internet Standard be safe.

  Since HIP and the other mechanisms propose an architectural change, in some ways similar to what Network Address Translation (NAT) did, it is far from clear what the consequences of such a change would be. A major task in this research group is to evaluate whether the likely outcome could be classified as safe, i.e., having no notable negative effects to the Internet in the large.

• Does the recommended baseline architecture or protocol need any changes.

  The initial HIP specifications, produces by the HIP WG, are experimental. The same is likely to be true for any other serious proposal for identity / locator separation. A major task in this research group is to evaluate if and what kind of changes would be needed or be desirable to the initial specifications.

An initial version of the experiment report is expected to be available in the first quarter of 2005, and the final version is planned to be ready in the second quarter of 2006.

Relationship to the IETF working groups

The RG is works in a close liaison with the Host Identity Protocol (HIP) working group. In addition to the HIP WG, the RG work is somehow related at least to the following working groups, in rough order of relevance:

• Site Multihoming in IPv6 (multi6), for sharing many architectural aspects.
• IPsec Mobility Extensions (mobike), for sharing some architectural aspects.
• Mobility-related WGs (mip4, mip6, mipshop, and nemo), since HIP addresses mobility in a way different from Mobile IP.
• DNS Extensions (dnsext), as HIP might provide a new tool for securing DNS updates.
• Next Steps in Signalling (nsis), since HIP may have implications in middle box signalling.

The following IRTF RGs are likely to be more related than the others:

• Ad Hoc Network scaling (ans), as HIP might be used as a new tool for mobile ad hoc networks.
• Peer-to-Peer (p2p), as HIP is fairly much p2p in nature, and may provide for mobility and multi-homing for some peer-to-peer protocols.

Membership

The RG operates in an open fashion (meetings & mailing list). If at a future date smaller meetings or subgroups are necessary for working out the details of specific items to be then reported to the larger group as a whole, then we can certainly provide for such a mechanism.

Meetings

Initially, meetings will be held three times a year, co-located with the IETF meetings. Depending the amount of time needed, the meetings may be scheduled on a regular IETF meeting slot, or after or before the IETF meeting.