draft-ietf-hip-rfc4423-bis-04.txt   draft-ietf-hip-rfc4423-bis-05.txt 
Network Working Group R. Moskowitz Network Working Group R. Moskowitz
Internet-Draft Verizon Internet-Draft Verizon
Obsoletes: 4423 (if approved) July 13, 2012 Obsoletes: 4423 (if approved) September 28, 2012
Intended status: Standards Track Intended status: Standards Track
Expires: January 14, 2013 Expires: April 1, 2013
Host Identity Protocol Architecture Host Identity Protocol Architecture
draft-ietf-hip-rfc4423-bis-04 draft-ietf-hip-rfc4423-bis-05
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.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 January 14, 2013. This Internet-Draft will expire on April 1, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 5, line 20 skipping to change at page 5, line 20
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. Public is |
| | a relative term here, ranging from known to peers |
| | only to known to the World. |
| | | | | |
| Private key | The private or secret key of an asymmetric | | Private key | The private or secret key of an asymmetric |
| | cryptographic key pair. Assumed to be known only | | | cryptographic key pair. Assumed to be known only |
| | to the party identified by the corresponding | | | to the party identified by the corresponding |
| | public key. Used by the identified party to | | | public key. Used by the identified party to |
| | authenticate its identity to other parties. | | | authenticate its identity to other parties. |
| | | | | |
| Public key | An asymmetric cryptographic key pair consisting | | Public key | An asymmetric cryptographic key pair consisting |
| pair | of public and private keys. For example, | | pair | of public and private keys. For example, |
| | Rivest-Shamir-Adelman (RSA) and Digital Signature | | | Rivest-Shamir-Adelman (RSA) and Digital Signature |
skipping to change at page 7, line 16 skipping to change at page 7, line 16
The Internet is built from three principal components: computing The Internet is built from three principal components: computing
platforms (end-points), packet transport (i.e., internetworking) platforms (end-points), packet transport (i.e., internetworking)
infrastructure, and services (applications). The Internet exists to infrastructure, and services (applications). The Internet exists to
service two principal components: people and robotic services service two principal components: people and robotic services
(silicon based people, if you will). All these components need to be (silicon based people, if you will). All these components need to be
named in order to interact in a scalable manner. Here we concentrate named in order to interact in a scalable manner. Here we concentrate
on naming computing platforms and packet transport elements. on naming computing platforms and packet transport elements.
There are two principal namespaces in use in the Internet for these There are two principal namespaces in use in the Internet for these
components: IP numbers, and Domain Names. Domain Names provide components: IP addresses, and Domain Names. Domain Names provide
hierarchically assigned names for some computing platforms and some hierarchically assigned names for some computing platforms and some
services. Each hierarchy is delegated from the level above; there is services. Each hierarchy is delegated from the level above; there is
no anonymity in Domain Names. Email, HTTP, and SIP addresses all no anonymity in Domain Names. Email, HTTP, and SIP addresses all
reference Domain Names. reference Domain Names.
The IP addressing namespace has been overloaded to name both The IP addressing namespace has been overloaded to name both
interfaces (at layer-3) and endpoints (for the endpoint-specific part interfaces (at layer-3) and endpoints (for the endpoint-specific part
of layer-3, and for layer-4). In their role as interface names, IP of layer-3, and for layer-4). In their role as interface names, IP
addresses are sometimes called "locators" and serve as an endpoint addresses are sometimes called "locators" and serve as an endpoint
within a routing topology. within a routing topology.
IP numbers name networking interfaces, and typically only when the IP addresses are numbers that name networking interfaces, and
interface is connected to the network. Originally, IP numbers had typically only when the interface is connected to the network.
long-term significance. Today, the vast number of interfaces use Originally, IP addresses had long-term significance. Today, the vast
ephemeral and/or non-unique IP numbers. That is, every time an number of interfaces use ephemeral and/or non-unique IP addresses.
interface is connected to the network, it is assigned an IP number. That is, every time an interface is connected to the network, it is
assigned an IP address.
In the current Internet, the transport layers are coupled to the IP In the current Internet, the transport layers are coupled to the IP
addresses. Neither can evolve separately from the other. IPng addresses. Neither can evolve separately from the other. IPng
deliberations were strongly shaped by the decision that a deliberations were strongly shaped by the decision that a
corresponding TCPng would not be created. corresponding TCPng would not be created.
There are three critical deficiencies with the current namespaces. There are three critical deficiencies with the current namespaces.
Firstly, dynamic readdressing cannot be directly managed. Secondly, Firstly, dynamic readdressing cannot be directly managed. Secondly,
anonymity is not provided in a consistent, trustable manner. anonymity is not provided in a consistent, trustable manner.
Finally, authentication for systems and datagrams is not provided. Finally, authentication for systems and datagrams is not provided.
skipping to change at page 9, line 42 skipping to change at page 9, line 42
'well known', some unpublished or 'anonymous'. A system may self- 'well known', some unpublished or 'anonymous'. A system may self-
assert its own identity, or may use a third-party authenticator like assert its own identity, or may use a third-party authenticator like
DNSSEC [RFC2535], PGP, or X.509 to 'notarize' the identity assertion DNSSEC [RFC2535], PGP, or X.509 to 'notarize' the identity assertion
to another namespace. It is expected that the Host Identifiers will to another namespace. It is expected that the Host Identifiers will
initially be authenticated with DNSSEC and that all implementations initially be authenticated with DNSSEC and that all implementations
will support DNSSEC as a minimal baseline. will support DNSSEC as a minimal baseline.
In theory, any name that can claim to be 'statistically globally In theory, any name that can claim to be 'statistically globally
unique' may serve as a Host Identifier. However, in the authors' unique' may serve as a Host Identifier. However, in the authors'
opinion, a public key of a 'public key pair' makes the best Host opinion, a public key of a 'public key pair' makes the best Host
Identifier. As will be specified in the Host Identity Protocol Base Identifier. As specified in the Host Identity Protocol [RFC5201-bis]
EXchange (BEX) [RFC5201-bis] specification, a public-key-based HI can specification, a public-key-based HI can authenticate the HIP packets
authenticate the HIP packets and protect them for man-in-the-middle and protect them for man-in-the-middle attacks. Since authenticated
attacks. Since authenticated datagrams are mandatory to provide much datagrams are mandatory to provide much of HIP's denial-of-service
of HIP's denial-of-service protection, the Diffie-Hellman exchange in protection, the Diffie-Hellman exchange in HIP BEX has to be
HIP BEX has to be authenticated. Thus, only public-key HI and authenticated. Thus, only public-key HI and authenticated HIP
authenticated HIP messages are supported in practice. messages are supported in practice.
In this document, the non-cryptographic forms of HI and HIP are In this document, the non-cryptographic forms of HI and HIP are
presented to complete the theory of HI, but they should not be presented to complete the theory of HI, but they should not be
implemented as they could produce worse denial-of-service attacks implemented as they could produce worse denial-of-service attacks
than the Internet has without Host Identity. There is on-going than the Internet has without Host Identity. There is on-going
research in challenge puzzles to use non-cryptographic HI, like research in challenge puzzles to use non-cryptographic HI, like
RFIDs, in an HIP exchange tailored to the workings of such RFIDs, in an HIP exchange tailored to the workings of such
challenges. challenges.
4.1. Host Identifiers 4.1. Host Identifiers
skipping to change at page 10, line 40 skipping to change at page 10, line 40
usable base for Host Identifiers. However, non-cryptographic names usable base for Host Identifiers. However, non-cryptographic names
should only be used in situations of high trust - low risk. That is should only be used in situations of high trust - low risk. That is
any place where host authentication is not needed (no risk of host any place where host authentication is not needed (no risk of host
spoofing) and no use of ESP. However, at least for interconnected spoofing) and no use of ESP. However, at least for interconnected
networks spanning several operational domains, the set of networks spanning several operational domains, the set of
environments where the risk of host spoofing allowed by non- environments where the risk of host spoofing allowed by non-
cryptographic Host Identifiers is acceptable is the null set. Hence, cryptographic Host Identifiers is acceptable is the null set. Hence,
the current HIP documents do not specify how to use any other types the current HIP documents do not specify how to use any other types
of Host Identifiers but public keys. of Host Identifiers but public keys.
The actual Host Identities are never directly used in any Internet The actual Host Identifiers are never directly used in any Internet
protocols. The corresponding Host Identifiers (public keys) may be protocols. The corresponding Host Identifiers (public keys) may be
stored in various DNS or LDAP directories as identified elsewhere in stored in various DNS or LDAP directories as identified elsewhere in
this document, and they are passed in the HIP base exchange. A Host this document, and they are passed in the HIP base exchange. A Host
Identity Tag (HIT) is used in other protocols to represent the Host Identity Tag (HIT) is used in other protocols to represent the Host
Identity. Another representation of the Host Identities, the Local Identity. Another representation of the Host Identities, the Local
Scope Identifier (LSI), can also be used in protocols and APIs. Scope Identifier (LSI), can also be used in protocols and APIs.
4.2. Host Identity Hash (HIH) 4.2. Host Identity Hash (HIH)
The Host Identity Hash is the cryptographic hash used in producing The Host Identity Hash is the cryptographic hash used in producing
the HIT from the HI. It is also the hash used through out the HIP the HIT from the HI. It is also the hash used through out the HIP
protocol for consistancy and simplicity. It is possible to for the protocol for consistancy and simplicity. It is possible to for the
two Hosts in the HIP exchange to use different hashes. two hosts in the HIP exchange to use different hashes.
Multiple HIHs within HIP are needed to address the moving target of Multiple HIHs within HIP are needed to address the moving target of
creation and eventual compromise of cryptographic hashes. This creation and eventual compromise of cryptographic hashes. This
significantly complicates HIP and offers an attacker an additional significantly complicates HIP and offers an attacker an additional
downgrade attack that is mitigated in the HIP protocol. downgrade attack that is mitigated in the HIP protocol.
4.3. Host Identity Tag (HIT) 4.3. Host Identity Tag (HIT)
A Host Identity Tag is a 128-bit representation for a Host Identity. A Host Identity Tag is a 128-bit representation for a Host Identity.
It is created from an HIH and other information, like an IPv6 prefix It is created from an HIH and other information, like an IPv6 prefix
and a hash identifier. There are two advantages of using the HIT and a hash identifier. There are two advantages of using the HIT
over using the Host Identifier in protocols. Firstly, its fixed over using the Host Identifier in protocols. Firstly, its fixed
length makes for easier protocol coding and also better manages the length makes for easier protocol coding and also better manages the
packet size cost of this technology. Secondly, it presents the packet size cost of this technology. Secondly, it presents the
identity in a consistent format to the protocol independent of the identity in a consistent format to the protocol independent of the
cryptographic algorithms used. cryptographic algorithms used.
There can be multiple HITs per Host Identifier when multiple hashes There can be multiple HITs per Host Identifier when multiple hashes
are supported. An Initator may have to initially guess which HIT to are supported. An Initator may have to initially guess which HIT to
use for the Responder, typically based on what it perfers, until it use for the Responder, typically based on what it prefers, until it
learns the appropriate HIT through the HIP exchange. learns the appropriate HIT through the HIP exchange.
In the HIP packets, the HITs identify the sender and recipient of a In the HIP packets, the HITs identify the sender and recipient of a
packet. Consequently, a HIT should be unique in the whole IP packet. Consequently, a HIT should be unique in the whole IP
universe as long as it is being used. In the extremely rare case of universe as long as it is being used. In the extremely rare case of
a single HIT mapping to more than one Host Identity, the Host a single HIT mapping to more than one Host Identity, the Host
Identifiers (public keys) will make the final difference. If there Identifiers (public keys) will make the final difference. If there
is more than one public key for a given node, the HIT acts as a hint is more than one public key for a given node, the HIT acts as a hint
for the correct public key to use. for the correct public key to use.
skipping to change at page 16, line 22 skipping to change at page 16, line 22
HITs (both HITs since a system can have more than one HIT). The SAs HITs (both HITs since a system can have more than one HIT). The SAs
need not to be bound to IP addresses; all internal control of the SA need not to be bound to IP addresses; all internal control of the SA
is by the HITs. Thus, a host can easily change its address using is by the HITs. Thus, a host can easily change its address using
Mobile IP, DHCP, PPP, or IPv6 readdressing and still maintain the Mobile IP, DHCP, PPP, or IPv6 readdressing and still maintain the
SAs. Since the transports are bound to the SA (via an LSI or a HIT), SAs. Since the transports are bound to the SA (via an LSI or a HIT),
any active transport is also maintained. Thus, real-world conditions any active transport is also maintained. Thus, real-world conditions
like loss of a PPP connection and its re-establishment or a mobile like loss of a PPP connection and its re-establishment or a mobile
handover will not require a HIP negotiation or disruption of handover will not require a HIP negotiation or disruption of
transport services [Bel1998]. transport services [Bel1998].
It should be noted that there are already BITW implementations. This It should be noted that there are already BITW implementations of HIP
is still consistant to the SA bindings above. providing virtual private network (VPN) services. This is still
consistent to the SA bindings above.
Since HIP does not negotiate any SA lifetimes, all lifetimes are Since HIP does not negotiate any SA lifetimes, all lifetimes are
local policy. The only lifetimes a HIP implementation must support local policy. The only lifetimes a HIP implementation must support
are sequence number rollover (for replay protection), and SA timeout. are sequence number rollover (for replay protection), and SA timeout.
An SA times out if no packets are received using that SA. An SA times out if no packets are received using that SA.
Implementations may support lifetimes for the various ESP transforms. Implementations may support lifetimes for the various ESP transforms.
8. HIP and MAC Security 8. HIP and MAC Security
The IEEE 802 standards have been defining MAC layered security. Many The IEEE 802 standards have been defining MAC layered security. Many
of these standards use EAP [RFC3748] as a Key Management System (KMS) of these standards use EAP [RFC3748] as a Key Management System (KMS)
transport, but some like IEEE 802.15.4 [IEEE.802-15-4.2006] leave the transport, but some like IEEE 802.15.4 [IEEE.802-15-4.2011] leave the
KMS and its transport as "Out of Scope". KMS and its transport as "Out of Scope".
HIP is well suited as a KMS in these environments. HIP is well suited as a KMS in these environments.
o HIP is independent of IP addressing and can be directly o HIP is independent of IP addressing and can be directly
transported over any network protocol. transported over any network protocol.
o Master Keys in 802 protocols are strictly pair-based with group o Master Keys in 802 protocols are strictly pair-based with group
keys transported from the group controller using pair-wise keys. keys transported from the group controller using pair-wise keys.
skipping to change at page 21, line 48 skipping to change at page 22, line 5
potentially could be more damaging to a host's ability to conduct potentially could be more damaging to a host's ability to conduct
business as usual. business as usual.
Resource exhausting denial-of-service attacks take advantage of the Resource exhausting denial-of-service attacks take advantage of the
cost of setting up a state for a protocol on the responder compared cost of setting up a state for a protocol on the responder compared
to the 'cheapness' on the initiator. HIP allows a responder to to the 'cheapness' on the initiator. HIP allows a responder to
increase the cost of the start of state on the initiator and makes an increase the cost of the start of state on the initiator and makes an
effort to reduce the cost to the responder. This is done by having effort to reduce the cost to the responder. This is done by having
the responder start the authenticated Diffie-Hellman exchange instead the responder start the authenticated Diffie-Hellman exchange instead
of the initiator, making the HIP base exchange 4 packets long. There of the initiator, making the HIP base exchange 4 packets long. There
are more details on this process in the Host Identity Protocol under are more details on this process in the Host Identity Protocol.
development.
HIP optionally supports opportunistic negotiation. That is, if a HIP optionally supports opportunistic negotiation. That is, if a
host receives a start of transport without a HIP negotiation, it can host receives a start of transport without a HIP negotiation, it can
attempt to force a HIP exchange before accepting the connection. attempt to force a HIP exchange before accepting the connection.
This has the potential for DoS attacks against both hosts. If the This has the potential for DoS attacks against both hosts. If the
method to force the start of HIP is expensive on either host, the method to force the start of HIP is expensive on either host, the
attacker need only spoof a TCP SYN. This would put both systems into attacker need only spoof a TCP SYN. This would put both systems into
the expensive operations. HIP avoids this attack by having the the expensive operations. HIP avoids this attack by having the
responder send a simple HIP packet that it can pre-build. Since this responder send a simple HIP packet that it can pre-build. Since this
packet is fixed and easily replayed, the initiator only reacts to it packet is fixed and easily replayed, the initiator only reacts to it
skipping to change at page 25, line 34 skipping to change at page 25, line 36
NomadicLab of Ericsson. Without their collective efforts HIP would NomadicLab of Ericsson. Without their collective efforts HIP would
have withered as on the IETF vine as a nice concept. have withered as on the IETF vine as a nice concept.
17. References 17. References
17.1. Normative References 17.1. Normative References
[RFC5201-bis] [RFC5201-bis]
Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
"Host Identity Protocol Version 2 (HIPv2)", "Host Identity Protocol Version 2 (HIPv2)",
draft-ietf-hip-rfc5201-bis-08 (work in progress), draft-ietf-hip-rfc5201-bis-09 (work in progress),
March 2012. July 2012.
[I-D.ietf-hip-rfc5202-bis] [I-D.ietf-hip-rfc5202-bis]
Jokela, P., Moskowitz, R., Nikander, P., and J. Melen, Jokela, P., Moskowitz, R., and J. Melen, "Using the
"Using the Encapsulating Security Payload (ESP) Transport Encapsulating Security Payload (ESP) Transport Format with
Format with the Host Identity Protocol (HIP)", the Host Identity Protocol (HIP)",
draft-ietf-hip-rfc5202-bis-00 (work in progress), draft-ietf-hip-rfc5202-bis-01 (work in progress),
September 2010. September 2012.
[I-D.ietf-hip-rfc5204-bis] [I-D.ietf-hip-rfc5204-bis]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", draft-ietf-hip-rfc5204-bis-01 (work Rendezvous Extension", draft-ietf-hip-rfc5204-bis-02 (work
in progress), March 2011. in progress), September 2012.
[I-D.ietf-hip-rfc5205-bis] [I-D.ietf-hip-rfc5205-bis]
Laganier, J., "Host Identity Protocol (HIP) Domain Name Laganier, J., "Host Identity Protocol (HIP) Domain Name
System (DNS) Extension", draft-ietf-hip-rfc5205-bis-01 System (DNS) Extension", draft-ietf-hip-rfc5205-bis-02
(work in progress), March 2011. (work in progress), September 2012.
[I-D.ietf-hip-rfc5206-bis] [I-D.ietf-hip-rfc5206-bis]
Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with
the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-03 the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-04
(work in progress), September 2011. (work in progress), July 2012.
17.2. Informative references 17.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.
skipping to change at page 26, line 49 skipping to change at page 27, line 4
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 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006. (HIP) Architecture", RFC 4423, May 2006.
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Keranen, "Basic Host Identity Protocol (HIP) Extensions Keranen, "Basic Host Identity Protocol (HIP) Extensions
for Traversal of Network Address Translators", RFC 5770, for Traversal of Network Address Translators", RFC 5770,
April 2010. April 2010.
[nsrg-report] [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.
[IEEE.802-15-4.2006] [IEEE.802-15-4.2011]
"Information technology - Telecommunications and "Information technology - Telecommunications and
information exchange between systems - Local and information exchange between systems - Local and
metropolitan area networks - Specific requirements - Part metropolitan area networks - Specific requirements - Part
15.4: Wireless Medium Access Control (MAC) and Physical 15.4: Wireless Medium Access Control (MAC) and Physical
Layer (PHY) Specifications for Low-Rate Wireless Personal Layer (PHY) Specifications for Low-Rate Wireless Personal
Area Networks (WPANs)", IEEE Standard 802.15.4, Area Networks (WPANs)", IEEE Standard 802.15.4,
September 2006, <http://standards.ieee.org/getieee802/ September 2011, <http://standards.ieee.org/getieee802/
download/802.15.4-2006.pdf>. download/802.15.4-2011.pdf>.
[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.
[Nik2001] Nikander, P., "Denial-of-Service, Address Ownership, and [Nik2001] Nikander, P., "Denial-of-Service, Address Ownership, and
Early Authentication in the IPv6 World", in Proceesings Early Authentication in the IPv6 World", in Proceesings
of Security Protocols, 9th International Workshop, of Security Protocols, 9th International Workshop,
Cambridge, UK, April 25-27 2001, LNCS 2467, pp. 12-26, Cambridge, UK, April 25-27 2001, LNCS 2467, pp. 12-26,
 End of changes. 22 change blocks. 
42 lines changed or deleted 46 lines changed or added

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