draft-ietf-hip-rfc4423-bis-00.txt   draft-ietf-hip-rfc4423-bis-01.txt 
Network Working Group R. Moskowitz Network Working Group R. Moskowitz
Internet-Draft ICSA labs Internet-Draft ICSA labs
Obsoletes: 4423 (if approved) August 17, 2010 Obsoletes: 4423 (if approved) August 24, 2010
Intended status: Standards Track Intended status: Standards Track
Expires: February 18, 2011 Expires: February 25, 2011
Host Identity Protocol Architecture Host Identity Protocol Architecture
draft-ietf-hip-rfc4423-bis-00 draft-ietf-hip-rfc4423-bis-01
Abstract Abstract
This memo describes a new namespace, the Host Identity namespace, and This memo describes a new namespace, the Host Identity namespace, and
a new protocol layer, the Host Identity Protocol, between the a new protocol layer, the Host Identity Protocol, between the
internetworking and transport layers. Herein are presented the internetworking and transport layers. Herein are presented the
basics of the current namespaces, their strengths and weaknesses, and basics of the current namespaces, their strengths and weaknesses, and
how a new namespace will add completeness to them. The roles of this how a new namespace will add completeness to them. The roles of this
new namespace in the protocols are defined. new namespace in the protocols are defined.
This document obsoletes RFC 4423 and addresses the concerns raised by This document obsoletes RFC 4423 and addresses the concerns raised by
the IESG, particularly that of crypto agility. It also incorporates the IESG, particularly that of crypto agility. It incorporates
lessons learned from the implementations of RFC 5201. lessons learned from the implementations of RFC 5201 and goes further
to explain how HIP works as a secure signalling channel.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 18, 2011. This Internet-Draft will expire on February 25, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 8 skipping to change at page 3, line 8
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Terms common to other documents . . . . . . . . . . . . . . 5 2.1. Terms common to other documents . . . . . . . . . . . . . . 5
2.2. Terms specific to this and other HIP documents . . . . . . . 5 2.2. Terms specific to this and other HIP documents . . . . . . . 5
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. A desire for a namespace for computing platforms . . . . . . 7 3.1. A desire for a namespace for computing platforms . . . . . . 7
4. Host Identity namespace . . . . . . . . . . . . . . . . . . 9 4. Host Identity namespace . . . . . . . . . . . . . . . . . . 9
4.1. Host Identifiers . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Host Identifiers . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Storing Host Identifiers in DNS . . . . . . . . . . . . . . 10 4.2. Storing Host Identifiers in DNS . . . . . . . . . . . . . . 10
4.3. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . . 11 4.3. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . . 11
4.4. Local Scope Identifier (LSI) . . . . . . . . . . . . . . . . 11 4.4. Local Scope Identifier (LSI) . . . . . . . . . . . . . . . . 11
5. New stack architecture . . . . . . . . . . . . . . . . . . . 11 5. New stack architecture . . . . . . . . . . . . . . . . . . . 11
skipping to change at page 3, line 30 skipping to change at page 3, line 30
6. End-host mobility and multi-homing . . . . . . . . . . . . . 13 6. End-host mobility and multi-homing . . . . . . . . . . . . . 13
6.1. Rendezvous mechanism . . . . . . . . . . . . . . . . . . . . 13 6.1. Rendezvous mechanism . . . . . . . . . . . . . . . . . . . . 13
6.2. Protection against flooding attacks . . . . . . . . . . . . 14 6.2. Protection against flooding attacks . . . . . . . . . . . . 14
7. HIP and IPsec . . . . . . . . . . . . . . . . . . . . . . . 14 7. HIP and IPsec . . . . . . . . . . . . . . . . . . . . . . . 14
8. HIP and NATs . . . . . . . . . . . . . . . . . . . . . . . . 15 8. HIP and NATs . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. HIP and TCP checksums . . . . . . . . . . . . . . . . . . . 16 8.1. HIP and TCP checksums . . . . . . . . . . . . . . . . . . . 16
9. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. HIP policies . . . . . . . . . . . . . . . . . . . . . . . . 16 10. HIP policies . . . . . . . . . . . . . . . . . . . . . . . . 16
11. Benefits of HIP . . . . . . . . . . . . . . . . . . . . . . 17 11. Benefits of HIP . . . . . . . . . . . . . . . . . . . . . . 17
11.1. HIP's answers to NSRG questions . . . . . . . . . . . . . . 18 11.1. HIP's answers to NSRG questions . . . . . . . . . . . . . . 18
12. Security considerations . . . . . . . . . . . . . . . . . . 20 12. Changes from RFC 4423 . . . . . . . . . . . . . . . . . . . 20
12.1. HITs used in ACLs . . . . . . . . . . . . . . . . . . . . . 21 13. Security considerations . . . . . . . . . . . . . . . . . . 20
12.2. Non-security considerations . . . . . . . . . . . . . . . . 22 13.1. HITs used in ACLs . . . . . . . . . . . . . . . . . . . . . 21
13. IANA considerations . . . . . . . . . . . . . . . . . . . . 22 13.2. Non-security considerations . . . . . . . . . . . . . . . . 22
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 23 14. IANA considerations . . . . . . . . . . . . . . . . . . . . 23
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 23
15.1. Normative References . . . . . . . . . . . . . . . . . . . . 23 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
15.2. Informative references . . . . . . . . . . . . . . . . . . . 23 16.1. Normative References . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . 24 16.2. Informative references . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The Internet has two important global namespaces: Internet Protocol The Internet has two important global namespaces: Internet Protocol
(IP) addresses and Domain Name Service (DNS) names. These two (IP) addresses and Domain Name Service (DNS) names. These two
namespaces have a set of features and abstractions that have powered namespaces have a set of features and abstractions that have powered
the Internet to what it is today. They also have a number of the Internet to what it is today. They also have a number of
weaknesses. Basically, since they are all we have, we try and do too weaknesses. Basically, since they are all we have, we try and do too
much with them. Semantic overloading and functionality extensions much with them. Semantic overloading and functionality extensions
have greatly complicated these namespaces. have greatly complicated these namespaces.
skipping to change at page 4, line 47 skipping to change at page 4, line 47
dynamic IP renumbering, aid in protocol translation / transition, and dynamic IP renumbering, aid in protocol translation / transition, and
reduce certain types of denial-of-service (DoS) attacks. reduce certain types of denial-of-service (DoS) attacks.
When HIP is used, the actual payload traffic between two HIP hosts is When HIP is used, the actual payload traffic between two HIP hosts is
typically, but not necessarily, protected with IPsec. The Host typically, but not necessarily, protected with IPsec. The Host
Identities are used to create the needed IPsec Security Associations Identities are used to create the needed IPsec Security Associations
(SAs) and to authenticate the hosts. When IPsec is used, the actual (SAs) and to authenticate the hosts. When IPsec is used, the actual
payload IP packets do not differ in any way from standard IPsec payload IP packets do not differ in any way from standard IPsec
protected IP packets. protected IP packets.
Much has been learned about HIP since [RFC4423] was published. This
document expands Host Identities beyond use to enable IP connectivity
and security to general interhost secure signalling at any protocol
layer. The signal may establish a security association between the
hosts, or simply pass information within the channel.
2. Terminology 2. Terminology
2.1. Terms common to other documents 2.1. Terms common to other documents
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
| Term | Explanation | | Term | Explanation |
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
| Public key | The public key of an asymmetric cryptographic key | | Public key | The public key of an asymmetric cryptographic key |
| | pair. Used as a publicly known identifier for | | | pair. Used as a publicly known identifier for |
| | cryptographic identity authentication. | | | cryptographic identity authentication. |
| | | | | |
| Private key | The private or secret key of an asymmetric | | Private key | The private or secret key of an asymmetric |
skipping to change at page 20, line 11 skipping to change at page 20, line 11
For most purposes, an approach where DNS names are resolved For most purposes, an approach where DNS names are resolved
simultaneously to HIs and IP addresses is sufficient. simultaneously to HIs and IP addresses is sufficient.
However, if it becomes necessary to resolve HIs into IP However, if it becomes necessary to resolve HIs into IP
addresses or back to DNS names, a flat resolution addresses or back to DNS names, a flat resolution
infrastructure is needed. Such an infrastructure could be infrastructure is needed. Such an infrastructure could be
based on the ideas of Distributed Hash Tables, but would based on the ideas of Distributed Hash Tables, but would
require significant new development and deployment. require significant new development and deployment.
12. Security considerations 12. Changes from RFC 4423
This section will summarize the changes made from [RFC4423].
13. Security considerations
HIP takes advantage of the new Host Identity paradigm to provide HIP takes advantage of the new Host Identity paradigm to provide
secure authentication of hosts and to provide a fast key exchange for secure authentication of hosts and to provide a fast key exchange for
IPsec. HIP also attempts to limit the exposure of the host to IPsec. HIP also attempts to limit the exposure of the host to
various denial-of-service (DoS) and man-in-the-middle (MitM) attacks. various denial-of-service (DoS) and man-in-the-middle (MitM) attacks.
In so doing, HIP itself is subject to its own DoS and MitM attacks In so doing, HIP itself is subject to its own DoS and MitM attacks
that potentially could be more damaging to a host's ability to that potentially could be more damaging to a host's ability to
conduct business as usual. conduct business as usual.
Resource exhausting denial-of-service attacks take advantage of the Resource exhausting denial-of-service attacks take advantage of the
skipping to change at page 21, line 38 skipping to change at page 21, line 43
not used because it would either have to have unique content, and not used because it would either have to have unique content, and
thus difficult to generate, resulting in yet another DoS attack, or thus difficult to generate, resulting in yet another DoS attack, or
just as spoofable as the ICMP message. Like in the previous case, just as spoofable as the ICMP message. Like in the previous case,
the defense against this attack is for the initiator to wait a the defense against this attack is for the initiator to wait a
reasonable time period to get a valid HIP packet. If one does not reasonable time period to get a valid HIP packet. If one does not
come, then the initiator has to assume that the ICMP message is come, then the initiator has to assume that the ICMP message is
valid. Since this is the only point in the HIP base exchange where valid. Since this is the only point in the HIP base exchange where
this ICMP message is appropriate, it can be ignored at any other this ICMP message is appropriate, it can be ignored at any other
point in the exchange. point in the exchange.
12.1. HITs used in ACLs 13.1. HITs used in ACLs
It is expected that HITs will be used in ACLs. Future firewalls can It is expected that HITs will be used in ACLs. Future firewalls can
use HITs to control egress and ingress to networks, with an assurance use HITs to control egress and ingress to networks, with an assurance
level difficult to achieve today. As discussed above in Section 7, level difficult to achieve today. As discussed above in Section 7,
once a HIP session has been established, the SPI value in an IPsec once a HIP session has been established, the SPI value in an IPsec
packet may be used as an index, indicating the HITs. In practice, packet may be used as an index, indicating the HITs. In practice,
firewalls can inspect HIP packets to learn of the bindings between firewalls can inspect HIP packets to learn of the bindings between
HITs, SPI values, and IP addresses. They can even explicitly control HITs, SPI values, and IP addresses. They can even explicitly control
IPsec usage, dynamically opening IPsec ESP only for specific SPI IPsec usage, dynamically opening IPsec ESP only for specific SPI
values and IP addresses. The signatures in HIP packets allow a values and IP addresses. The signatures in HIP packets allow a
skipping to change at page 22, line 28 skipping to change at page 22, line 32
HIP-aware NATs, however, are transparent to the HIP aware systems by HIP-aware NATs, however, are transparent to the HIP aware systems by
design. Thus, the host may find it difficult to notify any NAT that design. Thus, the host may find it difficult to notify any NAT that
is using a HIT in an ACL. Since most systems will know of the NATs is using a HIT in an ACL. Since most systems will know of the NATs
for their network, there should be a process by which they can notify for their network, there should be a process by which they can notify
these NATs of the change of the HIT. This is mandatory for systems these NATs of the change of the HIT. This is mandatory for systems
that function as responders behind a NAT. In a similar vein, if a that function as responders behind a NAT. In a similar vein, if a
host is notified of a change in a HIT of an initiator, it should host is notified of a change in a HIT of an initiator, it should
notify its NAT of the change. In this manner, NATs will get updated notify its NAT of the change. In this manner, NATs will get updated
with the HIT change. with the HIT change.
12.2. Non-security considerations 13.2. Non-security considerations
The definition of the Host Identifier states that the HI need not be The definition of the Host Identifier states that the HI need not be
a public key. It implies that the HI could be any value; for example a public key. It implies that the HI could be any value; for example
a FQDN. This document does not describe how to support such a non- a FQDN. This document does not describe how to support such a non-
cryptographic HI. A non-cryptographic HI would still offer the cryptographic HI. A non-cryptographic HI would still offer the
services of the HIT or LSI for NAT traversal. It would be possible services of the HIT or LSI for NAT traversal. It would be possible
to carry HITs in HIP packets that had neither privacy nor to carry HITs in HIP packets that had neither privacy nor
authentication. Since such a mode would offer so little additional authentication. Since such a mode would offer so little additional
functionality for so much addition to the IP kernel, it has not been functionality for so much addition to the IP kernel, it has not been
defined. Given how little public key cryptography HIP requires, HIP defined. Given how little public key cryptography HIP requires, HIP
should only be implemented using public key Host Identities. should only be implemented using public key Host Identities.
If it is desirable to use HIP in a low security situation where If it is desirable to use HIP in a low security situation where
public key computations are considered expensive, HIP can be used public key computations are considered expensive, HIP can be used
with very short Diffie-Hellman and Host Identity keys. Such use with very short Diffie-Hellman and Host Identity keys. Such use
makes the participating hosts vulnerable to MitM and connection makes the participating hosts vulnerable to MitM and connection
hijacking attacks. However, it does not cause flooding dangers, hijacking attacks. However, it does not cause flooding dangers,
since the address check mechanism relies on the routing system and since the address check mechanism relies on the routing system and
not on cryptographic strength. not on cryptographic strength.
13. IANA considerations 14. IANA considerations
This document has no actions for IANA. This document has no actions for IANA.
14. Acknowledgments 15. Acknowledgments
For the people historically involved in the early stages of HIP, see For the people historically involved in the early stages of HIP, see
the Acknowledgements section in the Host Identity Protocol the Acknowledgements section in the Host Identity Protocol
specification. specification.
During the later stages of this document, when the editing baton was During the later stages of this document, when the editing baton was
transfered to Pekka Nikander, the comments from the early transfered to Pekka Nikander, the comments from the early
implementors and others, including Jari Arkko, Tom Henderson, Petri implementors and others, including Jari Arkko, Tom Henderson, Petri
Jokela, Miika Komu, Mika Kousa, Andrew McGregor, Jan Melen, Tim Jokela, Miika Komu, Mika Kousa, Andrew McGregor, Jan Melen, Tim
Shepard, Jukka Ylitalo, and Jorma Wall, were invaluable. Finally, Shepard, Jukka Ylitalo, and Jorma Wall, were invaluable. Finally,
skipping to change at page 23, line 27 skipping to change at page 23, line 31
during the final stages of publication, most of which was during the final stages of publication, most of which was
incorporated but some of which the authors decided to ignore in order incorporated but some of which the authors decided to ignore in order
to get this document published in the first place. to get this document published in the first place.
The authors want to express their special thanks to Tom Henderson, The authors want to express their special thanks to Tom Henderson,
who took the burden of editing the document in response to IESG who took the burden of editing the document in response to IESG
comments at the time when both of the authors were busy doing other comments at the time when both of the authors were busy doing other
things. Without his perseverance this document might have never made things. Without his perseverance this document might have never made
it into an RFC form. it into an RFC form.
15. References 16. References
15.1. Normative References 16.1. Normative References
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the
Encapsulating Security Payload (ESP) Transport Format with Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", RFC 5202, April 2008. the Host Identity Protocol (HIP)", RFC 5202, April 2008.
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 5204, April 2008. Rendezvous Extension", RFC 5204, April 2008.
[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol [RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol
(HIP) Domain Name System (DNS) Extensions", RFC 5205, (HIP) Domain Name System (DNS) Extensions", RFC 5205,
April 2008. April 2008.
15.2. Informative references 16.2. Informative references
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997. RFC 2136, April 1997.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999. RFC 2535, March 1999.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766, Translation - Protocol Translation (NAT-PT)", RFC 2766,
skipping to change at page 24, line 24 skipping to change at page 24, line 29
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying [RFC4025] Richardson, M., "A Method for Storing IPsec Keying
Material in DNS", RFC 4025, March 2005. Material in DNS", RFC 4025, March 2005.
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, December 2005. Design Background", RFC 4225, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
[I-D.irtf-nsrg-report] [I-D.irtf-nsrg-report]
Lear, E. and R. Droms, "What's In A Name:Thoughts from the Lear, E. and R. Droms, "What's In A Name:Thoughts from the
NSRG", draft-irtf-nsrg-report-10 (work in progress), NSRG", draft-irtf-nsrg-report-10 (work in progress),
September 2003. September 2003.
[chiappa-endpoints] [chiappa-endpoints]
Chiappa, J., "Endpoints and Endpoint Names: A Proposed Chiappa, J., "Endpoints and Endpoint Names: A Proposed
Enhancement to the Internet Architecture", Enhancement to the Internet Architecture",
URL http://www.chiappa.net/~jnc/tech/endpoints.txt, 1999. URL http://www.chiappa.net/~jnc/tech/endpoints.txt, 1999.
 End of changes. 18 change blocks. 
24 lines changed or deleted 40 lines changed or added

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