draft-ietf-hip-applications-04.txt   rfc5338.txt 
Network Working Group T. Henderson Network Working Group T. Henderson
Internet-Draft The Boeing Company Request for Comments: 5338 The Boeing Company
Intended status: Informational P. Nikander Category: Informational P. Nikander
Expires: January 8, 2009 Ericsson Research NomadicLab Ericsson Research NomadicLab
M. Komu M. Komu
Helsinki Institute for Information Helsinki Institute for Information Technology
Technology September 2008
July 7, 2008
Using the Host Identity Protocol with Legacy Applications Using the Host Identity Protocol with Legacy Applications
draft-ietf-hip-applications-04
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 8, 2009. This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Abstract Abstract
This document is an informative overview of how legacy applications This document is an informative overview of how legacy applications
can be made to work with the Host Identity Protocol (HIP). HIP can be made to work with the Host Identity Protocol (HIP). HIP
proposes to add a cryptographic name space for network stack names. proposes to add a cryptographic name space for network stack names.
From an application viewpoint, HIP-enabled systems support a new From an application viewpoint, HIP-enabled systems support a new
address family of host identifiers, but it may be a long time until address family of host identifiers, but it may be a long time until
such HIP-aware applications are widely deployed even if host systems such HIP-aware applications are widely deployed even if host systems
are upgraded. This informational document discusses implementation are upgraded. This informational document discusses implementation
and Application Programming Interface (API) issues relating to using and Application Programming Interface (API) issues relating to using
HIP in situations in which the system is HIP-aware but the HIP in situations in which the system is HIP-aware but the
applications are not, and is intended to aid implementors and early applications are not, and is intended to aid implementors and early
adopters in thinking about and locally solving systems issues adopters in thinking about and locally solving systems issues
regarding the incremental deployment of HIP. regarding the incremental deployment of HIP.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology .....................................................3
3. Enabling HIP transparently within the system . . . . . . . . . 6 3. Enabling HIP Transparently within the System ....................4
3.1. Applying HIP to cases in which IP addresses are used . . . 6 3.1. Applying HIP to Cases in Which IP Addresses Are Used .......4
3.2. Interposing a HIP-aware agent in the DNS resolution . . . 7 3.2. Interposing a HIP-Aware Agent in the DNS Resolution ........6
3.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Discussion .................................................7
4. Users Invoking HIP with a Legacy Application . . . . . . . . . 10 4. Users Invoking HIP with a Legacy Application ....................8
4.1. Connecting to a HIT or LSI . . . . . . . . . . . . . . . . 10 4.1. Connecting to a HIT or LSI .................................8
4.2. Using a modified DNS name . . . . . . . . . . . . . . . . 10 4.2. Using a Modified DNS Name ..................................9
4.3. Other techniques . . . . . . . . . . . . . . . . . . . . . 11 4.3. Other Techniques ...........................................9
5. Local address management . . . . . . . . . . . . . . . . . . . 12 5. Local Address Management ........................................9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations ........................................11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgments ................................................12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 8. Informative References .........................................12
9. Informative References . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Changes from previous versions . . . . . . . . . . . 19
A.1. From version-01 to version-02 . . . . . . . . . . . . . . 19
A.2. From version-02 to version-03 . . . . . . . . . . . . . . 20
A.3. From version-03 to version-04 (current) . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
1. Introduction 1. Introduction
The Host Identity Protocol (HIP) [RFC5201] is an experimental effort The Host Identity Protocol (HIP) [RFC5201] is an experimental effort
in the IETF and IRTF to study a new public-key-based name space for in the IETF and IRTF to study a new public-key-based name space for
use as host identifiers in Internet protocols. Fully deployed, the use as host identifiers in Internet protocols. Fully deployed, the
HIP architecture would permit applications and users to explicitly HIP architecture would permit applications and users to explicitly
request the system to send packets to another host by expressing a request the system to send packets to another host by expressing a
location-independent unique name of a peer host when the system call location-independent unique name of a peer host when the system call
to connect or send packets is performed. However, there will be a to connect or send packets is performed. However, there will be a
skipping to change at page 3, line 43 skipping to change at page 3, line 14
This document does not define a native HIP API such as described This document does not define a native HIP API such as described
above. Rather, this document is concerned with the scenario in which above. Rather, this document is concerned with the scenario in which
the application is not HIP-aware and a traditional IP-address-based the application is not HIP-aware and a traditional IP-address-based
API is used by the application. API is used by the application.
The discussion so far assumes that applications are written directly The discussion so far assumes that applications are written directly
to a sockets API. However, many applications are built on top of to a sockets API. However, many applications are built on top of
middleware that exports a higher-level API to the application. In middleware that exports a higher-level API to the application. In
this case, for the purpose of this document, we refer to the this case, for the purpose of this document, we refer to the
combination of the middleware and the middleware- based application combination of the middleware and the middleware-based application as
as an overall application, or client of the sockets API. an overall application, or client of the sockets API.
When HIP is enabled on a system, but the applications are not HIP- When HIP is enabled on a system, but the applications are not HIP-
aware, there are a few basic possibilities to use HIP, each of which aware, there are a few basic possibilities to use HIP, each of which
may or may not be supported by a given HIP implementation. We report may or may not be supported by a given HIP implementation. We report
here on techniques that have been used or considered by experimental here on techniques that have been used or considered by experimental
HIP implementations. We organize the discussion around the policy HIP implementations. We organize the discussion around the policy
chosen to use or expose HIP to the applications. The first option is chosen to use or expose HIP to the applications. The first option is
that users are completely unaware of HIP, or are unable to control that users are completely unaware of HIP, or are unable to control
whether or not HIP is invoked, but rather the system chooses to whether or not HIP is invoked, but rather the system chooses to
enable HIP for some or all sessions based on policy. The second enable HIP for some or all sessions based on policy. The second
skipping to change at page 4, line 20 skipping to change at page 3, line 40
HIP was designed to work with unmodified applications, to ease HIP was designed to work with unmodified applications, to ease
incremental deployment. For instance, the HIT is the same size as incremental deployment. For instance, the HIT is the same size as
the IPv6 address, and the design thinking was that, during initial the IPv6 address, and the design thinking was that, during initial
experiments and transition periods, the HITs could substitute in data experiments and transition periods, the HITs could substitute in data
structures where IPv6 addresses were expected. However, to a varying structures where IPv6 addresses were expected. However, to a varying
degree depending on the mechanism employed, such use of HIP can alter degree depending on the mechanism employed, such use of HIP can alter
the semantics of what is considered to be an IP address by the semantics of what is considered to be an IP address by
applications. Applications use IP addresses as short-lived local applications. Applications use IP addresses as short-lived local
handles, long-lived application associations, callbacks, referrals, handles, long-lived application associations, callbacks, referrals,
and identity comparisons. The transition techniques described below and identity comparisons [APP-REF]. The transition techniques
have implications on these different uses of IP addresses by legacy described below have implications on these different uses of IP
applications, and we will try to clarify these implications in the addresses by legacy applications, and we will try to clarify these
below discussions. implications in the below discussions.
2. Terminology 2. Terminology
Callback: The application at one end retrieves the IP address of Callback: The application at one end retrieves the IP address of
the peer and uses that to later communicate "back" to the peer. the peer and uses that to later communicate "back" to the peer.
An example is the FTP PORT command. An example is the FTP PORT command.
Host Identity: An abstract concept applied to a computing platform. Host Identity: An abstract concept applied to a computing platform.
Host Identifier (HI): A public key of an asymmetric key pair used as Host Identifier (HI): A public key of an asymmetric key pair used as
a name for a Host Identity. More details are available in a name for a Host Identity. More details are available in
[RFC5201]. [RFC5201].
Host Identity Tag (HIT): A 128-bit quantity composed with the hash Host Identity Tag (HIT): A 128-bit quantity composed with the hash
of a Host Identity. More details are available in [RFC4843] and of a Host Identity. More details are available in [RFC4843] and
[RFC5201]. [RFC5201].
Local Scope Identifier (LSI): A 32- or 128-bit quantity locally Local Scope Identifier (LSI): A 32- or 128-bit quantity locally
representing the Host Identity at the IPv4 or IPv6 API. representing the Host Identity at the IPv4 or IPv6 API.
Long-lived application associations: The IP address is retained by
the application for several instances of communication.
Referral: In an application with more than two parties, party B Referral: In an application with more than two parties, party B
takes the IP address of party A and passes that to party C. After takes the IP address of party A and passes that to party C. After
this party C uses the IP address to communicate with A. this, party C uses the IP address to communicate with A.
Resolver: The system function used by applications to resolve domain Resolver: The system function used by applications to resolve domain
names to IP addresses. names to IP addresses.
Short-lived local handle: The IP addresses is never retained by the Short-lived local handle: The IP addresses is never retained by the
application. The only usage is for the application to pass it application. The only usage is for the application to pass it
from the DNS APIs (e.g., getaddrinfo()) and the API to the from the DNS APIs (e.g., getaddrinfo()) and the API to the
protocol stack (e.g., connect() or sendto()). protocol stack (e.g., connect() or sendto()).
Long-lived application associations: The IP address is retained by 3. Enabling HIP Transparently within the System
the application for several instances of communication.
3. Enabling HIP transparently within the system
When both users and applications are unaware of HIP, but the host When both users and applications are unaware of HIP, but the host
administrator chooses to use HIP between hosts, a few options are administrator chooses to use HIP between hosts, a few options are
possible. The first basic option is to perform a mapping of the possible. The first basic option is to perform a mapping of the
application-provided IP address to a host identifier within the application-provided IP address to a host identifier within the
stack. The second option, if DNS is used, is to interpose a local stack. The second option, if DNS is used, is to interpose a local
agent in the DNS resolution process and to return to the application agent in the DNS resolution process and to return to the application
a HIT or a locally scoped handle, formatted like an IP address. a HIT or a locally scoped handle, formatted like an IP address.
3.1. Applying HIP to cases in which IP addresses are used 3.1. Applying HIP to Cases in Which IP Addresses Are Used
Consider the case in which an application issues a "connect(ip)" Consider the case in which an application issues a "connect(ip)"
system call to set the default destination to a system named by system call to set the default destination to a system named by
address "ip", but for which the host administrator would like to address "ip", but for which the host administrator would like to
enable HIP to protect the communications. The user or application enable HIP to protect the communications. The user or application
intends for the system to communicate with the host reachable at that intends for the system to communicate with the host reachable at that
IP address. The decision to invoke HIP must be done on the basis of IP address. The decision to invoke HIP must be done on the basis of
host policy. For example, when an IPsec-based implementation of HIP host policy. For example, when an IPsec-based implementation of HIP
is being used, a policy may be entered into the security policy is being used, a policy may be entered into the security policy
database that mandates to use or to try HIP based on a match on the database that mandates to use or to try HIP based on a match on the
skipping to change at page 6, line 27 skipping to change at page 5, line 4
Consider the case in which an application issues a "connect(ip)" Consider the case in which an application issues a "connect(ip)"
system call to set the default destination to a system named by system call to set the default destination to a system named by
address "ip", but for which the host administrator would like to address "ip", but for which the host administrator would like to
enable HIP to protect the communications. The user or application enable HIP to protect the communications. The user or application
intends for the system to communicate with the host reachable at that intends for the system to communicate with the host reachable at that
IP address. The decision to invoke HIP must be done on the basis of IP address. The decision to invoke HIP must be done on the basis of
host policy. For example, when an IPsec-based implementation of HIP host policy. For example, when an IPsec-based implementation of HIP
is being used, a policy may be entered into the security policy is being used, a policy may be entered into the security policy
database that mandates to use or to try HIP based on a match on the database that mandates to use or to try HIP based on a match on the
source or destination IP address, port numbers, or other factors. source or destination IP address, port numbers, or other factors.
The mapping of IP address to host identifier may be implemented by The mapping of IP address to host identifier may be implemented by
modifying the host operating system or by wrapping the existing modifying the host operating system or by wrapping the existing
sockets API, such as in the TESLA approach [paper.tesla]. sockets API, such as in the TESLA approach [TESLA].
There are a number of ways that HIP could be configured by the host There are a number of ways that HIP could be configured by the host
administrator in such a scenario. administrator in such a scenario.
Manual configuration: Manual configuration:
Pre-existing SAs may be available due to previous administrative Pre-existing Security Associations (SAs) may be available due to
action, or a binding between an IP address and a HIT could be previous administrative action, or a binding between an IP address
stored in a configuration file or database. and a HIT could be stored in a configuration file or database.
Opportunistically: Opportunistically:
The system could send an I1 to the Responder with an empty value The system could send an I1 to the Responder with an empty value
for Responder HIT. for Responder HIT.
Using DNS to map IP addresses to HIs: Using DNS to map IP addresses to HIs:
If the responder has host identifiers registered in the forward If the Responder has host identifiers registered in the forward
DNS zone and has a PTR record in the reverse zone, the Initiator DNS zone and has a PTR record in the reverse zone, the Initiator
could perform a reverse+forward lookup to learn the HIT associated could perform a reverse+forward lookup to learn the HIT associated
with the address. Although the approach should work under normal with the address. Although the approach should work under normal
circumstances, it has not been tested to verify that there are no circumstances, it has not been tested to verify that there are no
recursion or bootstrapping issues, particularly if HIP is used to recursion or bootstrapping issues, particularly if HIP is used to
secure the connection to the DNS servers. Discussion of the secure the connection to the DNS servers. Discussion of the
security implications of the use or absence of DNSSEC is deferred security implications of the use or absence of DNS Security
to the security considerations section. (DNSSEC) is deferred to the Security Considerations section.
Using HIP in the above fashion can cause additional setup delays Using HIP in the above fashion can cause additional setup delays
compared to using plain IP. For opportunistic mode, a host must wait compared to using plain IP. For opportunistic mode, a host must wait
to learn whether the peer is HIP-capable, although the delays may be to learn whether the peer is HIP-capable, although the delays may be
mitigated in some implementations by sending initial packets (e.g., mitigated in some implementations by sending initial packets (e.g.,
TCP SYN) in parallel to the HIP I1 packet and waiting some time to TCP SYN) in parallel to the HIP I1 packet and waiting some time to
receive a HIP R1 before processing a TCP SYN/ACK. Note that there receive a HIP R1 before processing a TCP SYN/ACK. Note that there
presently does not exist specification for how to invoke such presently does not exist specification for how to invoke such
connections in parallel. Resolution latencies may also be incurred connections in parallel. Resolution latencies may also be incurred
when using DNS in the above fashion. when using DNS in the above fashion.
A possible way to reduce latencies noted above, in the case that the A possible way to reduce the above-noted latencies, in the case that
application uses DNS, would be for the system to opportunistically the application uses DNS, would be for the system to
query for HIP records in parallel to other DNS resource records, and opportunistically query for HIP records in parallel to other DNS
to temporarily cache the HITs returned with a DNS lookup, indexed by resource records, and to temporarily cache the HITs returned with a
the IP addresses returned in the same entry, and pass the IP DNS lookup, indexed by the IP addresses returned in the same entry,
addresses up to the application as usual. If an application connects and pass the IP addresses up to the application as usual. If an
to one of those IP addresses within a short time after the lookup, application connects to one of those IP addresses within a short time
the host should initiate a base exchange using the cached HITs. The after the lookup, the host should initiate a base exchange using the
benefit is that this removes the uncertainty/delay associated with cached HITs. The benefit is that this removes the uncertainty/delay
opportunistic HIP, because the DNS record suggests that the peer is associated with opportunistic HIP, because the DNS record suggests
HIP-capable. that the peer is HIP-capable.
3.2. Interposing a HIP-aware agent in the DNS resolution 3.2. Interposing a HIP-Aware Agent in the DNS Resolution
In the previous section, it was noted that a HIP-unaware application In the previous section, it was noted that a HIP-unaware application
might typically use the DNS to fetch IP addresses prior to invoking might typically use the DNS to fetch IP addresses prior to invoking
socket calls. A HIP-enabled system might make use of DNS to socket calls. A HIP-enabled system might make use of DNS to
transparently fetch host identifiers for such domain names prior to transparently fetch host identifiers for such domain names prior to
the onset of communication. the onset of communication.
A system with a local DNS agent could alternately return a Local A system with a local DNS agent could alternately return a Local
Scope Identifier (LSI) or HIT rather than an IP address, if HIP Scope Identifier (LSI) or HIT rather than an IP address, if HIP
information is available in the DNS or other directory that binds a information is available in the DNS or other directory that binds a
skipping to change at page 8, line 18 skipping to change at page 6, line 38
In the case when resolvers can return multiple destination In the case when resolvers can return multiple destination
identifiers for an application, it may be configured that some of the identifiers for an application, it may be configured that some of the
identifiers can be HIP-based identifiers, and the rest can be IPv4 or identifiers can be HIP-based identifiers, and the rest can be IPv4 or
IPv6 addresses. The system resolver may return HIP-based identifiers IPv6 addresses. The system resolver may return HIP-based identifiers
in front of the list of identifiers when the underlying system and in front of the list of identifiers when the underlying system and
policies support HIP. An application processing the identifiers policies support HIP. An application processing the identifiers
sequentially will then first try a HIP-based connection and only then sequentially will then first try a HIP-based connection and only then
other non-HIP based connections. However, certain applications may other non-HIP based connections. However, certain applications may
launch the connections in parallel. In such a case, the non-HIP launch the connections in parallel. In such a case, the non-HIP
connections may succeed before HIP connections. Based on local connections may succeed before HIP connections. Based on local
system policies, a system may disallow such behaviour and return only system policies, a system may disallow such behavior and return only
HIP-based identifiers when they are found from DNS. HIP-based identifiers when they are found from DNS.
If the application obtains LSIs or HITs that it treats as IP If the application obtains LSIs or HITs that it treats as IP
addresses, a few potential hazards arise. First, applications that addresses, a few potential hazards arise. First, applications that
perform referrals may pass the LSI to another system that has no perform referrals may pass the LSI to another system that has no
system context to resolve the LSI back to a host identifier or an IP system context to resolve the LSI back to a host identifier or an IP
address. Note that these are the same type of applications that will address. Note that these are the same type of applications that will
likely break if used over certain types of network address likely break if used over certain types of network address
translators (NATs). Second, applications may cache the results of translators (NATs). Second, applications may cache the results of
DNS queries for a long time, and it may be hard for a HIP system to DNS queries for a long time, and it may be hard for a HIP system to
skipping to change at page 8, line 32 skipping to change at page 7, line 4
addresses, a few potential hazards arise. First, applications that addresses, a few potential hazards arise. First, applications that
perform referrals may pass the LSI to another system that has no perform referrals may pass the LSI to another system that has no
system context to resolve the LSI back to a host identifier or an IP system context to resolve the LSI back to a host identifier or an IP
address. Note that these are the same type of applications that will address. Note that these are the same type of applications that will
likely break if used over certain types of network address likely break if used over certain types of network address
translators (NATs). Second, applications may cache the results of translators (NATs). Second, applications may cache the results of
DNS queries for a long time, and it may be hard for a HIP system to DNS queries for a long time, and it may be hard for a HIP system to
determine when to perform garbage collection on the LSI bindings. determine when to perform garbage collection on the LSI bindings.
However, when using HITs, the security of using the HITs for identity However, when using HITs, the security of using the HITs for identity
comparison may be stronger than in the case of using IP addresses. comparison may be stronger than in the case of using IP addresses.
Finally, applications may generate log files, and administrators or Finally, applications may generate log files, and administrators or
other consumers of these log files may become confused to find LSIs other consumers of these log files may become confused to find LSIs
or HITs instead of IP addresses. Therefore, it is recommended that or HITs instead of IP addresses. Therefore, it is recommended that
the HIP software logs the HITs, LSIs (if applicable), corresponding the HIP software logs the HITs, LSIs (if applicable), corresponding
IP addresses, and FQDN-related information so that administrators can IP addresses, and Fully Qualified Domain Name (FQDN)-related
correlate other logs with HIP identifiers. information so that administrators can correlate other logs with HIP
identifiers.
It may be possible for an LSI or HIT to be routable or resolvable, It may be possible for an LSI or HIT to be routable or resolvable,
either directly or through an overlay, in which case it would be either directly or through an overlay, in which case it would be
preferable for applications to handle such names instead of IP preferable for applications to handle such names instead of IP
addresses. However, such networks are out of scope of this document. addresses. However, such networks are out of scope of this document.
3.3. Discussion 3.3. Discussion
Solutions preserving the use of IP addresses in the applications have Solutions preserving the use of IP addresses in the applications have
the benefit of better support for applications that use IP addresses the benefit of better support for applications that use IP addresses
skipping to change at page 10, line 43 skipping to change at page 9, line 14
this approach is in actually finding the IP addresses to use, based this approach is in actually finding the IP addresses to use, based
on the HIT. Some type of HIT resolution service would be needed in on the HIT. Some type of HIT resolution service would be needed in
this case. A third challenge of this approach is in supporting this case. A third challenge of this approach is in supporting
callbacks and referrals to possibly non-HIP-aware hosts. However, callbacks and referrals to possibly non-HIP-aware hosts. However,
since most communications in this case would likely be to other HIP- since most communications in this case would likely be to other HIP-
aware hosts (else the initial HIP associations would fail to aware hosts (else the initial HIP associations would fail to
establish), the resulting referral problem may be that the peer host establish), the resulting referral problem may be that the peer host
supports HIP but is not able to perform HIT resolution for some supports HIP but is not able to perform HIT resolution for some
reason. reason.
4.2. Using a modified DNS name 4.2. Using a Modified DNS Name
Specifically, if the application requests to resolve "HIP- Specifically, if the application requests to resolve "HIP-
www.example.com" (or some similar prefix string), then the system www.example.com" (or some similar prefix string), then the system
returns an LSI, while if the application requests to resolve returns an LSI, while if the application requests to resolve
"www.example.com", IP address(es) are returned as usual. The use of "www.example.com", IP address(es) are returned as usual. The use of
a prefix rather than suffix is recommended, and the use of a string a prefix rather than suffix is recommended, and the use of a string
delimiter that is not a dot (".") is also recommended, to reduce the delimiter that is not a dot (".") is also recommended, to reduce the
likelihood that such modified DNS names are mistakenly treated as likelihood that such modified DNS names are mistakenly treated as
names rooted at a new top-level domain. Limits of domain name length names rooted at a new top-level domain. Limits of domain name length
or label length (255 or 63, respectively) should be considered when or label length (255 or 63, respectively) should be considered when
prepending any prefixes. prepending any prefixes.
4.3. Other techniques 4.3. Other Techniques
Alternatives to using a modified DNS name that have been experimented Alternatives to using a modified DNS name that have been experimented
with include the following. Command-line tools or tools with a with include the following. Command-line tools or tools with a
graphical user interface (GUI) can be provided by the system to allow graphical user interface (GUI) can be provided by the system to allow
a user to set the policy on which applications use HIP. Another a user to set the policy on which applications use HIP. Another
common technique, for dynamically linked applications, is to common technique, for dynamically linked applications, is to
dynamically link the application to a modified library that wraps the dynamically link the application to a modified library that wraps the
system calls and interposes HIP layer communications on them; this system calls and interposes HIP layer communications on them; this
can be invoked by the user by running commands through a special can be invoked by the user by running commands through a special
shell, for example. shell, for example.
5. Local address management 5. Local Address Management
The previous two sections focused mainly on controlling client The previous two sections focused mainly on controlling client
behavior (HIP initiator). We must also consider the behavior for behavior (HIP initiator). We must also consider the behavior for
servers. Typically, a server binds to a wildcard IP address and servers. Typically, a server binds to a wildcard IP address and
well-known port. In the case of HIP use with legacy server well-known port. In the case of HIP use with legacy server
implementations, there are again a few options. The system may be implementations, there are again a few options. The system may be
configured manually to always, optionally (depending on the client configured manually to always, optionally (depending on the client
behavior), or never use HIP with a particular service, as a matter of behavior), or never use HIP with a particular service, as a matter of
policy, when the server specifies a wildcard (IP) address. policy, when the server specifies a wildcard (IP) address.
skipping to change at page 12, line 29 skipping to change at page 10, line 18
(common in many HIP implementations). The application may use such (common in many HIP implementations). The application may use such
identifiers as addresses in subsequent socket calls. identifiers as addresses in subsequent socket calls.
Some applications may try to bind a socket to a specific local Some applications may try to bind a socket to a specific local
address, or may implement server-side access control lists based on address, or may implement server-side access control lists based on
socket calls such as getsockname() and getpeername() in the C-based socket calls such as getsockname() and getpeername() in the C-based
socket APIs. If the local address specified is an IP address, again, socket APIs. If the local address specified is an IP address, again,
the underlying system may be configured to still use HIP. If the the underlying system may be configured to still use HIP. If the
local address specified is a HIT (Section 4), the system should local address specified is a HIT (Section 4), the system should
enforce that connections to the local application can only arrive to enforce that connections to the local application can only arrive to
the specified HIT. If a system has many HITs, an application that the specified HIT. If a system has many HIs, an application that
binds to a single HIT cannot accept connections to the other HITs in binds to a single HIT cannot accept connections to the other HIs but
the system. the one corresponding to the specified HIT.
When a host has multiple HIs and the socket behavior does not When a host has multiple HIs and the socket behavior does not
prescribe the use of any particular HI as a local identifier, it is a prescribe the use of any particular HI as a local identifier, it is a
matter of local policy as to how to select a HI to serve as a local matter of local policy as to how to select a HI to serve as a local
identifier. However, systems that bind to a wildcard may face identifier. However, systems that bind to a wildcard may face
problems when multiple HITs or LSIs are defined. These problems are problems when multiple HITs or LSIs are defined. These problems are
not specific to HIP per se, but are also encountered in non-HIP not specific to HIP per se, but are also encountered in non-HIP
multihoming scenarios with applications not designed for multihoming. multihoming scenarios with applications not designed for multihoming.
As an example, consider a client application that sends an UDP As an example, consider a client application that sends a UDP
datagram to a server that is bound to a wildcard. The server datagram to a server that is bound to a wildcard. The server
application receives the packet using recvfrom() and sends a response application receives the packet using recvfrom() and sends a response
using sendto(). The problem here is that sendto() may actually use a using sendto(). The problem here is that sendto() may actually use a
different server HIT than the client assumes. The client will drop different server HIT than the client assumes. The client will drop
the response packet when the client implements access control on the the response packet when the client implements access control on the
UDP socket (e.g. using connect()). UDP socket (e.g., using connect()).
Reimplementing the server application using the sendmsg() and Reimplementing the server application using the sendmsg() and
recvmsg() to support multihoming (particularly considering the recvmsg() to support multihoming (particularly considering the
ancillary data) would be the ultimate solution to this problem, but ancillary data) would be the ultimate solution to this problem, but
with legacy applications is not an option. As a workaround, we make with legacy applications is not an option. As a workaround, we make
suggestion for servers providing UDP-based services with non- suggestion for servers providing UDP-based services with non-
multihoming capable services. Such servers should announce only the multihoming-capable services. Such servers should announce only the
HIT or public key that matches to the default outgoing HIT of the HIT or public key that matches to the default outgoing HIT of the
host to avoid such problems. host to avoid such problems.
Finally, some applications may create a connection to a local HIT. Finally, some applications may create a connection to a local HIT.
In such a case, the local system may use NULL encryption to avoid In such a case, the local system may use NULL encryption to avoid
unnecessary encryption overhead, and may be otherwise more permissive unnecessary encryption overhead, and may be otherwise more permissive
than usual such as excluding authentication, Diffie-Hellman exchange, than usual such as excluding authentication, Diffie-Hellman exchange,
and puzzle. and puzzle.
6. Security Considerations 6. Security Considerations
In this section we discuss the security of the system in general In this section, we discuss the security of the system in general
terms, outlining some of the security properties. However, this terms, outlining some of the security properties. However, this
section is not intended to provide a complete risk analysis. Such an section is not intended to provide a complete risk analysis. Such an
analysis would, in any case, be dependent on the actual application analysis would, in any case, be dependent on the actual application
using HIP, and is therefore considered out of scope. using HIP, and is therefore considered out of scope.
The scenarios outlined above differ considerably in their security The scenarios outlined above differ considerably in their security
properties. When the DNS is used, there are further differences properties. When the DNS is used, there are further differences
related to whether DNSSEC [RFC4033] is used or not, and whether the related to whether or not DNSSEC [RFC4033] is used, and whether the
DNS zones are considered trustworthy enough. Here we mean that there DNS zones are considered trustworthy enough. Here we mean that there
should exist a delegation chain to whatever trust anchors are should exist a delegation chain to whatever trust anchors are
available in the respective trees, and the DNS zone administrators in available in the respective trees, and the DNS zone administrators in
charge of the netblock should be trusted to put in the right charge of the netblock should be trusted to put in the right
information. information.
When IP addresses are used by applications to name the peer system, When IP addresses are used by applications to name the peer system,
the security properties depend on the configuration method. With the security properties depend on the configuration method. With
manual configuration, the security of the system is comparable to a manual configuration, the security of the system is comparable to a
non-HIP system with similar IPsec policies. The security semantics non-HIP system with similar IPsec policies. The security semantics
skipping to change at page 14, line 39 skipping to change at page 11, line 39
attacks. If the DNS is used, if both zones are secured (or the HITs attacks. If the DNS is used, if both zones are secured (or the HITs
are stored in the reverse DNS record) and the client trusts the are stored in the reverse DNS record) and the client trusts the
DNSSEC signatures, the system may provide a fairly high security DNSSEC signatures, the system may provide a fairly high security
level. However, much depends on the details of the implementation, level. However, much depends on the details of the implementation,
the security and administrative practices used when signing the DNS the security and administrative practices used when signing the DNS
zones, and other factors. zones, and other factors.
Using the forward DNS to map a domain name into an LSI is a case that Using the forward DNS to map a domain name into an LSI is a case that
is closest to the most typical use scenarios today. If DNSSEC is is closest to the most typical use scenarios today. If DNSSEC is
used, the result is fairly similar to the current use of certificates used, the result is fairly similar to the current use of certificates
with TLS. If DNSSEC is not used, the result is fairly similar to the with Transport Layer Security (TLS). If DNSSEC is not used, the
current use of plain IP, with the additional protection of data result is fairly similar to the current use of plain IP, with the
integrity, confidentiality, and prevention of connection hijacking additional protection of data integrity, confidentiality, and
that opportunistic HIP provides. If DNSSEC is used, data integrity prevention of connection hijacking that opportunistic HIP provides.
and data origin authentication services are added to the normal DNS If DNSSEC is used, data integrity and data origin authentication
query protocol, thereby providing more certainty that the desired services are added to the normal DNS query protocol, thereby
host is being contacted, if the DNS records themselves are providing more certainty that the desired host is being contacted, if
trustworthy. the DNS records themselves are trustworthy.
If the application is basing its operations on HITs, the connections If the application is basing its operations on HITs, the connections
become automatically secured due to the implicit channel bindings in become automatically secured due to the implicit channel bindings in
HIP. That is, when the application makes a connect(HIT) system call, HIP. That is, when the application makes a connect(HIT) system call,
the resulting packets will either be sent to a node possessing the either the resulting packets will be sent to a node possessing the
corresponding private key or the security association will fail to be corresponding private key or the security association will fail to be
established. established.
When the system provides (spoofs) LSIs or HITs instead of IP When the system provides (spoofs) LSIs or HITs instead of IP
addresses as the result of name resolution, the resultant fields may addresses as the result of name resolution, the resultant fields may
inadvertently show up in user interfaces and system logs, which may inadvertently show up in user interfaces and system logs, which may
cause operational concerns for some network administrators. cause operational concerns for some network administrators.
Therefore, it is recommended that the HIP software logs the HITs, Therefore, it is recommended that the HIP software logs the HITs,
LSIs (if applicable), corresponding IP addresses, and FQDN-related LSIs (if applicable), corresponding IP addresses, and FQDN-related
information so that administrators can correlate other logs with HIP information so that administrators can correlate other logs with HIP
identifiers. identifiers.
7. IANA Considerations 7. Acknowledgments
This document has no actions for IANA.
8. Acknowledgments
Jeff Ahrenholz, Gonzalo Camarillo, Alberto Garcia, Teemu Koponen, Jeff Ahrenholz, Gonzalo Camarillo, Alberto Garcia, Teemu Koponen,
Julien Laganier, and Jukka Ylitalo have provided comments on Julien Laganier, and Jukka Ylitalo have provided comments on
different versions of this draft. Erik Nordmark provided the different versions of this document. The document received
taxonomy of how applications use IP addresses in a previously expired substantial and useful comments during the review phase from David
Internet Draft. The document received substantial and useful Black, Lars Eggert, Peter Koch, Thomas Narten, and Pekka Savola.
comments during the review phase from David Black, Pekka Savola, Lars
Eggert, and Peter Koch.
9. Informative References 8. Informative References
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
"Host Identity Protocol", RFC 5201, April 2008. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6
for Overlay Routable Cryptographic Hash Identifiers Prefix for Overlay Routable Cryptographic Hash Identifiers
(ORCHID)", RFC 4843, April 2007. (ORCHID)", RFC 4843, April 2007.
[paper.tesla] [TESLA] Salz, J., Balakrishnan, H., and A. Snoeren, "TESLA: A
Salz, J., Balakrishnan, H., and A. Snoeren, "TESLA: A
Transparent, Extensible Session-Layer Architecture for Transparent, Extensible Session-Layer Architecture for
End-to-end Network Services", Proceedings of USENIX End-to-end Network Services", Proceedings of USENIX
Symposium on Internet Technologies and Systems (USITS), Symposium on Internet Technologies and Systems (USITS),
pages 211-224, March 2003. pages 211-224, March 2003.
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", [RFC1958] Carpenter, B., Ed., "Architectural Principles of the
RFC 1958, June 1996. Internet", RFC 1958, June 1996.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements", RFC
RFC 4033, March 2005. 4033, March 2005.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", Stevens, "Basic Socket Interface Extensions for IPv6", RFC
RFC 3493, February 2003. 3493, February 2003.
Appendix A. Changes from previous versions
This section is to be removed by the RFC Editor before publication.
It summarizes resolution of issues raised in the following reviews:
(1) IESG last call, (2) Gen-ART review, and (3) DNS directorate
review. Mobility and secdir reviews did not result in actionable
comments.
A.1. From version-01 to version-02
Better clarity in the abstract and introduction about the goal of the
draft; namely, that it is informational to help implementors and
early adopters think about and solve deployment issues (comment from
Pekka Savola).
Delete the second paragraph of 3 about the general applicability of
replacing IP addresses with LSIs and HITs at the socket layer.
(comment from Pekka Savola).
Delete comments in Section 3.2 on routable LSIs, as this is seen to
be out of scope and potentially controversial or incomplete (comment
from David Black).
Delete reference to Erik Nordmark's shim6 application referral draft,
since it is a dead draft (comment from David Black). Instead, Erik
is cited in the acknowledgments section for providing the taxonomy of
IP address usage scenarios.
Clarify (and reference the base spec) in Sec. 3.1 that use of the
opportunistic mode requires that systems not enforce that the
HIT-to-IP address bindings learned will pertain to subsequent
sessions to that IP address.
Section 3.2 drew comments from several reviewers. First, David Black
raised the issue that spoofing IP addresses with HITs or LSIs raises
risks that it may turn up in log records; this has been noted in the
text. The section on using a DNS suffix to signal the preferred use
of HIP was objected to by members of the DNS directorate and others
(including the co-author Pekka Nikander), due to concern that queries
to a new TLD might leak out. The current draft instead recommends a
DNS prefix instead of suffix, due to a suggestion by Thomas Narten.
In section 3.1, clarify recursion issues that may arise when doing
reverse+forward lookup of HIP records from DNS (comment from Pekka
Savola).
Clarify more specifically in security considerations section the
DNSSEC trust assumptions or security considerations (outline of text
provided by Pekka Savola, and similar comment raised by Peter Koch).
Clarified in security considerations section that IP address spoofing
could cause some operational difficulties if they unexpectedly show
up in log files or UIs (comment from David Black).
Clarified in Sec. 3.1 that opportunistic and DNS techniques can incur
additional latency when compared to plain IP (comment from Lars
Eggert)
Added third option to Section 3.2 for using DNS (transparently
fetching HIP resource records when doing other RR queries), suggested
by Lars Eggert and also by Olaf Kolkman.
Incorporated last-call comments from Miika Komu, which were all
handled in Section 3.4: i) clarify multihoming issue for servers with
multiple HITs, when receiving UDP, ii) clarify a problem that might
arise for applications that do parallel connect, and iii) suggest
that loopback HIP connections could use a NULL encryption.
Removed expired references and updated active references.
Incorporated additional review comments from Miika Komu, and some
suggested replacement text, and added him as a co-author.
A.2. From version-02 to version-03
DNSSEC clarifications added based on dns-dir review from Peter Koch
Editing pass through document. Organizationally, everything except
security considerations was in one section. The existing text of
Sections 3.1 through 3.3 was moved to new Sections 3 and 4, the
previous text of section 3.4 has been moved to section 5, and the
previous Section 4 (security considerations) is now Section 6.
Performed further wordsmithing and cleanup.
A.3. From version-03 to version-04 (current)
Add suggestion by David Black to also log IP addresses used in HIP [APP_REF] Nordmark, E., "Shim6 Application Referral Issues", Work in
conversations (Sections 3.2 and 7). Progress, July 2005.
Authors' Addresses Authors' Addresses
Thomas Henderson Thomas Henderson
The Boeing Company The Boeing Company
P.O. Box 3707 P.O. Box 3707
Seattle, WA Seattle, WA
USA USA
Email: thomas.r.henderson@boeing.com EMail: thomas.r.henderson@boeing.com
Pekka Nikander Pekka Nikander
Ericsson Research NomadicLab Ericsson Research NomadicLab
JORVAS FIN-02420 JORVAS FIN-02420
FINLAND FINLAND
Phone: +358 9 299 1 Phone: +358 9 299 1
Email: pekka.nikander@nomadiclab.com EMail: pekka.nikander@nomadiclab.com
Miika Komu Miika Komu
Helsinki Institute for Information Technology Helsinki Institute for Information Technology
Metsaenneidonkuja 4 Metsaenneidonkuja 4
Helsinki FIN-02420 Helsinki FIN-02420
FINLAND FINLAND
Phone: +358503841531 Phone: +358503841531
Email: miika@iki.fi EMail: miika@iki.fi
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 46 change blocks. 
219 lines changed or deleted 101 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/