draft-ietf-hip-via-02.txt   draft-ietf-hip-via-03.txt 
HIP Working Group G. Camarillo HIP Working Group G. Camarillo
Internet-Draft A. Keranen Internet-Draft A. Keranen
Intended status: Experimental Ericsson Intended status: Experimental Ericsson
Expires: December 24, 2010 June 22, 2010 Expires: December 31, 2010 June 29, 2010
Host Identity Protocol (HIP) Multi-hop Routing Extension Host Identity Protocol (HIP) Multi-hop Routing Extension
draft-ietf-hip-via-02.txt draft-ietf-hip-via-03.txt
Abstract Abstract
This document specifies two extensions to HIP to implement multi-hop This document specifies two extensions to HIP to implement multi-hop
routing. The first extension allows implementing source routing in routing. The first extension allows implementing source routing in
HIP. That is, a node sending a HIP packet can define a set of nodes HIP. That is, a node sending a HIP packet can define a set of nodes
that the HIP packet should traverse. The second extension allows a that the HIP packet should traverse. The second extension allows a
HIP packet to carry and record the list of nodes that forwarded it. HIP packet to carry and record the list of nodes that forwarded it.
Status of this Memo Status of this Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 24, 2010. This Internet-Draft will expire on December 31, 2010.
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 17 skipping to change at page 3, line 17
When HIP [RFC5201] is used in certain contexts, nodes need the When HIP [RFC5201] is used in certain contexts, nodes need the
ability to perform source routing. That is, a node needs the ability ability to perform source routing. That is, a node needs the ability
to send a HIP signaling packet that will traverse a set of nodes to send a HIP signaling packet that will traverse a set of nodes
before reaching its destination. Such features are needed, e.g., in before reaching its destination. Such features are needed, e.g., in
HIP BONE [I-D.ietf-hip-bone] overlay networks or if two nodes wish to HIP BONE [I-D.ietf-hip-bone] overlay networks or if two nodes wish to
keep a third, or more, HIP nodes on the signaling path. This keep a third, or more, HIP nodes on the signaling path. This
document defines an extension that provides HIP with this document defines an extension that provides HIP with this
functionality. functionality.
Additionally, when HIP signaling packets are routed through multiple Additionally, when HIP signaling packets are routed through multiple
nodes, some of these nodes (e.g., the destination node) need the nodes, some of these nodes (e.g., the destination host) need the
ability to know the nodes a particular packet traversed. This ability to know the nodes a particular packet traversed. This
document defines another extension that provides HIP with this document defines another extension that provides HIP with this
functionality. functionality.
These two extensions enable multi-hop routing in HIP. Before these These two extensions enable multi-hop routing in HIP. Before these
extensions were specified, there were standardized ways for extensions were specified, there were standardized ways for
supporting only a single intermediate node (e.g., a rendezvous server supporting only a single intermediate node (e.g., a rendezvous server
[RFC5204]) between the source of a HIP packet and its destination. [RFC5204]) between the source of a HIP packet and its destination.
2. Terminology 2. Terminology
skipping to change at page 7, line 49 skipping to change at page 7, line 49
This document updates the IANA Registry for HIP Parameter Types This document updates the IANA Registry for HIP Parameter Types
[RFC5201] by assigning new HIP Parameter Type values for the new HIP [RFC5201] by assigning new HIP Parameter Type values for the new HIP
Parameters: ROUTE_VIA and ROUTE_DST (defined in Section 4). This Parameters: ROUTE_VIA and ROUTE_DST (defined in Section 4). This
document also defines a new Notify Packet Type [RFC5201] document also defines a new Notify Packet Type [RFC5201]
UNKNOWN_NEXT_HOP in Section 3.3. UNKNOWN_NEXT_HOP in Section 3.3.
The ROUTE_DST and ROUTE_VIA parameters utilize bit flags, for which The ROUTE_DST and ROUTE_VIA parameters utilize bit flags, for which
IANA is to create and maintain a new sub-registry entitled "HIP Via IANA is to create and maintain a new sub-registry entitled "HIP Via
Flags" under the "Host Identity Protocol (HIP) Parameters" registry. Flags" under the "Host Identity Protocol (HIP) Parameters" registry.
Initial values for the registry are given in Table 1; future Initial values for the registry are given in Table 1; future
assignments are to be made through IETF Review [RFC5226]. assignments are to be made through IETF Review or IESG Approval
Assignments consist of the bit position and the name of the flag. [RFC5226]. Assignments consist of the bit position and the name of
the flag.
6. Security Considerations 6. Security Considerations
The standard HIP mechanisms (e.g., using signatures, puzzles, and the The standard HIP mechanisms (e.g., using signatures, puzzles, and the
ENCRYPTED parameter [RFC5201]) provide protection against ENCRYPTED parameter [RFC5201]) provide protection against
eavesdropping, replay, message insertion, deletion, modification, and eavesdropping, replay, message insertion, deletion, modification, and
man-in-the-middle attacks. Yet, the extensions described in this man-in-the-middle attacks. Yet, the extensions described in this
document allow nodes to route HIP messages via other nodes and hence document allow nodes to route HIP messages via other nodes and hence
possibly try to mount Denial of Service (DoS) attacks against them. possibly try to mount Denial of Service (DoS) attacks against them.
The following sections describe possible attacks and means to The following sections describe possible attacks and means to
skipping to change at page 9, line 33 skipping to change at page 9, line 34
Rendezvous Extension", RFC 5204, April 2008. Rendezvous Extension", RFC 5204, April 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[I-D.ietf-hip-bone] [I-D.ietf-hip-bone]
Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A., Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A.,
and A. Johnston, "HIP BONE: Host Identity Protocol (HIP) and A. Johnston, "HIP BONE: Host Identity Protocol (HIP)
Based Overlay Networking Environment", Based Overlay Networking Environment",
draft-ietf-hip-bone-06 (work in progress), April 2010. draft-ietf-hip-bone-07 (work in progress), June 2010.
[I-D.ietf-p2psip-base] [I-D.ietf-p2psip-base]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", draft-ietf-p2psip-base-08 (work in Base Protocol", draft-ietf-p2psip-base-08 (work in
progress), March 2010. progress), March 2010.
Authors' Addresses Authors' Addresses
Gonzalo Camarillo Gonzalo Camarillo
 End of changes. 6 change blocks. 
7 lines changed or deleted 8 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/