Host Identity Protocol (HIP) Multi-Hop Routing Extension
draft-ietf-hip-via-03
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
03 | (System) | post-migration administrative database adjustment to the Yes position for Jari Arkko |
2012-08-22
|
03 | (System) | post-migration administrative database adjustment to the No Objection position for Adrian Farrel |
2010-08-24
|
03 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2010-08-24
|
03 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2010-08-24
|
03 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2010-08-23
|
03 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2010-08-23
|
03 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2010-07-19
|
03 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2010-07-19
|
03 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2010-07-19
|
03 | (System) | IANA Action state changed to In Progress |
2010-07-19
|
03 | Cindy Morgan | IESG state changed to Approved-announcement sent |
2010-07-19
|
03 | Cindy Morgan | IESG has approved the document |
2010-07-19
|
03 | Cindy Morgan | Closed "Approve" ballot |
2010-06-29
|
03 | (System) | New version available: draft-ietf-hip-via-03.txt |
2010-06-28
|
03 | Dan Romascanu | [Ballot comment] I think that this document (and the other hip documents) need to included a short explanation of the reasons for which the WG … [Ballot comment] I think that this document (and the other hip documents) need to included a short explanation of the reasons for which the WG was chartered to issue Experimental RFCs, what kind of experimentation should be planned for the protocol extension, what are the expected results, and whether there are deployment concerns or limitations that need to be taken into consideration by operators. If this information can be found in some other hip document a reference would be fine. |
2010-06-28
|
03 | Dan Romascanu | [Ballot discuss] |
2010-06-28
|
03 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu |
2010-06-28
|
03 | Dan Romascanu | [Ballot comment] I think that this document (and the other hip documents) need to included a short explanation of the reasons for which the WG … [Ballot comment] I think that this document (and the other hip documents) need to included a short explanation of the reasons for which the WG was chartered to issue Experimental RFCs, what kind of experimentation should be planned for the protocol extension, what are the expected results, and whether there are deployment concerns or limitations that need to be taken into consideration by operators. If this information can be found in some other hip document a reference would be fine. |
2010-06-28
|
03 | Dan Romascanu | [Ballot discuss] The document says nothing about how hosts are being configured to support this extension and how are the lists parameters configured. |
2010-06-23
|
03 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss by Adrian Farrel |
2010-06-22
|
03 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to Yes from Discuss by Jari Arkko |
2010-06-22
|
03 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2010-06-22
|
02 | (System) | New version available: draft-ietf-hip-via-02.txt |
2010-06-18
|
03 | (System) | Removed from agenda for telechat - 2010-06-17 |
2010-06-17
|
03 | Cindy Morgan | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan |
2010-06-17
|
03 | Adrian Farrel | [Ballot discuss] Fine work, but just some small points about source routing I couldn't work out. Is it OK for additional HIP hosts to be … [Ballot discuss] Fine work, but just some small points about source routing I couldn't work out. Is it OK for additional HIP hosts to be inserted in the sequence specified? That is, is the sequence a loose sequence that can be expanded? Does the destination HIP host have to be present in the sequence, or can the sequence "end early"? Do you need to worry about the possibility of the recorded list of hosts becoming too large? When symmetry is applied, do you need to use the source route as supplied, or the actual route as recorded? If the answer to the first question is "no" and the second question "yes", can additional HIP hosts be inserted between the last host in the sequence provided, and the destination host? Is this an ordered list (sequence) or just a list? The bit flags seem to imply that the sequence can be broken - is this by leaving out hosts, or by rearrangement? |
2010-06-17
|
03 | Adrian Farrel | [Ballot discuss] Fine work, but just some small points about source routing I couldn't work out. Is it OK for additional HIP hosts to be … [Ballot discuss] Fine work, but just some small points about source routing I couldn't work out. Is it OK for additional HIP hosts to be inserted in the sequence specified? That is, is the sequence a loose sequence that can be expanded? Does the destination HIP host have to be present in the sequence, or can the sequence "end early"? If the answer to the first question is "no" and the second question "yes", can additional HIP hosts be inserted between the last host in the sequence provided, and the destination host? Is this an ordered list (sequence) or just a list? The bit flags seem to imply that the sequence can be broken - is this by leaving out hosts, or by rearrangement? |
2010-06-17
|
03 | Adrian Farrel | [Ballot Position Update] New position, Discuss, has been recorded by Adrian Farrel |
2010-06-17
|
03 | Robert Sparks | [Ballot comment] Consider adding a pointer to the discussion of fragmentation in the primary HIP draft. |
2010-06-17
|
03 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks |
2010-06-17
|
03 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded by Sean Turner |
2010-06-17
|
03 | Tim Polk | [Ballot comment] Please ensure that the changes prompted by Catherine Meadows secdir are incorporated! |
2010-06-17
|
03 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
2010-06-17
|
03 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov |
2010-06-17
|
03 | Jari Arkko | [Ballot discuss] This is a good draft and I will ballot Yes on it. However, there were a few issues that I would like to … [Ballot discuss] This is a good draft and I will ballot Yes on it. However, there were a few issues that I would like to see corrected first: 1. IANA considerations section should describe what the policy is for allocating new bits from the flag field, and request IANA to create a name space for the bits. 2. The draft is using unclear/wrong terminology with regards to "host". For instance: Section: 3.1: When a host sending a HIP packet needs to record the hosts that are on the path that the HIP packet traverses, it includes an empty ROUTE_VIA parameter to the packet. Section 3.2: A host that needs to define the other hosts that should be on the path a HIP packet traverses adds a ROUTE_DST parameter to the HIP packet. Section 4: Both parameters have critical type (as defined in Section 5.2.1 of [RFC5201]) since the packet will not be properly routed unless all hosts on path recognize the parameters. The traditional meaning of a host is an end system, whereas here the node acts as a router. I would suggest that perhaps the term "node" would be more appropriate. RFC 5204 used both "node" and "server" in its descriptions. 3. Also, the draft is imprecise in its description of behaviors associated with packet reception: Section 3.1: A host that receives a packet with a ROUTE_VIA parameter SHOULD add its own HIT to the end of the ROUTE_VIA parameter, unless it is the receiver of the packet. Section 3.3: When a host receives a HIP packet that contains a ROUTE_DST parameter, it first looks up its own HIT from the route list. If host's own HIT is not in the list and the host is not the receiver of the packet, the packet was incorrectly forwarded and MUST be dropped. I am particularly reacting to the "... host receives ... if the host is not the receiver" language here. I think it would be better to say "... node receives a HIP packet ... the receiver's host identity tag is not one of the node's own HITs ..." or something along those lines. 4 .Section 1 should indicate that the draft deals only with the routing of the HIP signalling packets, not actual data packets. 5. Finally, the security considerations should cover more issues with source routing than just loops. See, e.g., http://tools.ietf.org/html/draft-savola-ipv6-rh-ha-security for some generic packet filtering and other issues around source routing. Also, the current draft seems susceptible to a similar issue that led to the deprecation of IPv6 routing headers. See RFC 5095 for the history. Assuming an otherwise 100-byte HIP packet, a host could add a 1400-byte ROUTE_DST parameter with 88 intermediate destinations. By sending out this one 1500 byte packet, it would be routed in the network 88 times. The draft does require that the same HIT not appear twice in the list, and this is an improvement over the IPv6 routing header situation. However, if a sufficient number of willing router nodes can be found in the Internet, significant amplification factors can still be reached. It would make sense to document this issue and perhaps even restrict the maximum number of destinations in ROUTE_DST. |
2010-06-17
|
03 | Jari Arkko | [Ballot discuss] IANA considerations section should describe what the policy is for allocating new bits from the flag field, and request IANA to create a … [Ballot discuss] IANA considerations section should describe what the policy is for allocating new bits from the flag field, and request IANA to create a name space for the bits. The draft is using unclear/wrong terminology with regards to "host". For instance: Section: 3.1: When a host sending a HIP packet needs to record the hosts that are on the path that the HIP packet traverses, it includes an empty ROUTE_VIA parameter to the packet. Section 3.2: A host that needs to define the other hosts that should be on the path a HIP packet traverses adds a ROUTE_DST parameter to the HIP packet. Section 4: Both parameters have critical type (as defined in Section 5.2.1 of [RFC5201]) since the packet will not be properly routed unless all hosts on path recognize the parameters. The traditional meaning of a host is an end system, whereas here the node acts as a router. I would suggest that perhaps the term "node" would be more appropriate. RFC 5204 used both "node" and "server" in its descriptions. Also, the draft is imprecise in its description of behaviors associated with packet reception: Section 3.1: A host that receives a packet with a ROUTE_VIA parameter SHOULD add its own HIT to the end of the ROUTE_VIA parameter, unless it is the receiver of the packet. Section 3.3: When a host receives a HIP packet that contains a ROUTE_DST parameter, it first looks up its own HIT from the route list. If host's own HIT is not in the list and the host is not the receiver of the packet, the packet was incorrectly forwarded and MUST be dropped. I am particularly reacting to the "... host receives ... if the host is not the receiver" language here. I think it would be better to say "... node receives a HIP packet ... the receiver's host identity tag is not one of the node's own HITs ..." or something along those lines. Section 1 should indicate that the draft deals only with the routing of the HIP signalling packets, not actual data packets. Finally, the security considerations should cover more issues with source routing than just loops. See, e.g., http://tools.ietf.org/html/draft-savola-ipv6-rh-ha-security for some generic packet filtering and other issues around source routing. Also, the current draft seems susceptible to a similar issue that led to the deprecation of IPv6 routing headers. See RFC 5095 for the history. Assuming an otherwise 100-byte HIP packet, a host could add a 1400-byte ROUTE_DST parameter with 88 intermediate destinations. By sending out this one 1500 byte packet, it would be routed in the network 88 times. The draft does require that the same HIT not appear twice in the list, and this is an improvement over the IPv6 routing header situation. However, if a sufficient number of willing router nodes can be found in the Internet, significant amplification factors can still be reached. It would make sense to document this issue and perhaps even restrict the maximum number of destinations in ROUTE_DST. |
2010-06-17
|
03 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko |
2010-06-16
|
03 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded by Peter Saint-Andre |
2010-06-16
|
03 | Russ Housley | [Ballot comment] Please consider the the editorial comments raised by Gen-ART Review by Ben Campbell on 2010-06-11: -- General: IDNITS turns up some … [Ballot comment] Please consider the the editorial comments raised by Gen-ART Review by Ben Campbell on 2010-06-11: -- General: IDNITS turns up some outdated references and boilerplate questions. Please check. -- Section 1, para 2, "HIP BONE": Please expand on first mention. -- Section 1, last paragraph: I'm not sure we can assume the reader knows what you mean by "customary sections." -- Section 3.2.2, para 3, last sentence, "Given that each operation requires the attacker to generate a new key pair, the attack is completely impractical": It would be better to avoid hyperbole when describing the practicality of an attack. Perhaps something to the effect of "impractical with current technology and techniques"? -- Section 3.4, para 2, last sentence, "with such straightforward approach": Missing article. -- Section 5.1, para 2, "The enrollment server of an overlay that were to use HITs derived from public keys as Node IDs could just authorize users to use the public keys and HITs associated to their nodes.": I have trouble parsing the first part of the sentence, around "that were to use". -- Section 5.3, para 1, "Nodes in an overlay need to establish connection with other nodes": Connections (singular/plural mismatch) -- Section 5.5, para before last bullet list, "It is assumed that areas not covered by a particular HIP BONE instance specification are specified by the peer protocol or elsewhere.": This seems more a requirement than an assumption. -- Section 6.1,"[ TBD by IANA; 980 ]": Does this mean IANA has already picked the number? Or is it a recommended number? (Pattern repeats for other registrations.) |
2010-06-16
|
03 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2010-06-16
|
03 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2010-06-16
|
03 | Dan Romascanu | [Ballot discuss] 1. I think that this document (and the other hip documents) need to included a short explanation of the reasons for which the … [Ballot discuss] 1. I think that this document (and the other hip documents) need to included a short explanation of the reasons for which the WG was chartered to issue Experimental RFCs, what kind of experimentation should be planned for the protocol extension, what are the expected results, and whether there are deployment concerns or limitations that need to be taken into consideration by operators. If this information can be found in some other hip document a reference would be fine. 2. The document says nothing about how hosts are being configured to support this extension and how are the lists parameters configured. |
2010-06-16
|
03 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu |
2010-06-16
|
03 | Ralph Droms | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Ralph Droms |
2010-06-14
|
03 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2010-06-11
|
03 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2010-06-09
|
03 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Catherine Meadows. |
2010-06-07
|
03 | Amanda Baber | IANA comments: Action 1: Upon approval of this document, IANA will make the following assignments in the "Host Identity Protocol (HIP) Parameters" registry located at … IANA comments: Action 1: Upon approval of this document, IANA will make the following assignments in the "Host Identity Protocol (HIP) Parameters" registry located at http://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml sub-registry "Parameter Types" Value Parameter Type Length Reference ----- -------------- ------ --------- TBD(971) ROUTE_VIA variable [RFC-hip-via-01] TBD(65525) ROUTE_DST variable [RFC-hip-via-01] Action 2: Upon approval of this document, IANA will make the following assignment in the "Host Identity Protocol (HIP) Parameters" registry located at http://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml sub-registry "Notify Message Types" Value Notify Message Type Reference ----- ------------------- --------- TBD(90) UNKNOWN_NEXT_HOP [RFC-hip-via-01] We understand the above to be the only IANA Actions for this document. |
2010-06-07
|
03 | Gonzalo Camarillo | [Ballot Position Update] New position, Recuse, has been recorded by Gonzalo Camarillo |
2010-06-03
|
03 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Catherine Meadows |
2010-06-03
|
03 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Catherine Meadows |
2010-05-28
|
03 | Amy Vezza | Last call sent |
2010-05-28
|
03 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2010-05-28
|
03 | Ralph Droms | Placed on agenda for telechat - 2010-06-17 by Ralph Droms |
2010-05-28
|
03 | Ralph Droms | Last Call was requested by Ralph Droms |
2010-05-28
|
03 | Ralph Droms | State Changes to Last Call Requested from AD Evaluation by Ralph Droms |
2010-05-28
|
03 | Ralph Droms | [Ballot Position Update] New position, Yes, has been recorded for Ralph Droms |
2010-05-28
|
03 | Ralph Droms | Ballot has been issued by Ralph Droms |
2010-05-28
|
03 | Ralph Droms | Created "Approve" ballot |
2010-05-28
|
03 | (System) | Ballot writeup text was added |
2010-05-28
|
03 | (System) | Last call text was added |
2010-05-28
|
03 | (System) | Ballot approval text was added |
2010-05-28
|
03 | Ralph Droms | State Changes to AD Evaluation from Publication Requested by Ralph Droms |
2010-05-28
|
03 | Ralph Droms | [Note]: 'David Ward (dward@juniper.net) is the document shepherd.' added by Ralph Droms |
2010-05-06
|
03 | Cindy Morgan | [Note]: 'David Ward (dward@juniper.net) is the document shepherd.' added by Cindy Morgan |
2010-05-06
|
03 | Cindy Morgan | (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the … (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? David Ward is the sheperd for this document. He believes it is ready. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been adequately reviewed. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. The are no concerns about this document and no IPR has been filed. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? It represents the consensus of the whole WG. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The document passes ID nits. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has both normative and informative references. All normative references are RFCs. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? The IANA considerations section is appropriate. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document does not use formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document specifies two extensions to HIP to implement multi-hop routing. The first extension allows implementing source routing in HIP. That is, a host sending a HIP packet can define a set of hosts that the HIP packet should traverse. The second extension allows a HIP packet to carry and record the list of hosts that forwarded it. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There was strong consensus on this document. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? There are prototype implementations of this spec. A few vendors have expressed interest in implementing this in the context of HIP BONE overlays. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' David Ward is the document shepherd for this document. Ralph Droms is the responsible AD for this document. |
2010-05-06
|
03 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
2010-05-06
|
03 | Cindy Morgan | [Note]: 'David Ward is the document shepherd' added by Cindy Morgan |
2010-03-08
|
01 | (System) | New version available: draft-ietf-hip-via-01.txt |
2009-10-27
|
00 | (System) | New version available: draft-ietf-hip-via-00.txt |