End-Host Mobility and Multihoming with the Host Identity Protocol
draft-ietf-hip-mm-05
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
05 | (System) | post-migration administrative database adjustment to the Yes position for Sam Hartman |
2008-04-21
|
05 | (System) | This was part of a ballot set with: draft-ietf-hip-base, draft-ietf-hip-esp, draft-ietf-hip-registration, draft-ietf-hip-rvs |
2007-12-20
|
05 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2007-12-20
|
05 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2007-12-20
|
05 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2007-12-07
|
05 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2007-12-05
|
05 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2007-12-05
|
05 | Amy Vezza | IESG state changed to Approved-announcement sent |
2007-12-05
|
05 | Amy Vezza | IESG has approved the document |
2007-12-05
|
05 | Amy Vezza | Closed "Approve" ballot |
2007-12-05
|
05 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
2007-12-05
|
05 | (System) | IANA Action state changed to In Progress |
2007-12-03
|
05 | Sam Hartman | [Ballot Position Update] Position for Sam Hartman has been changed to Yes from Discuss by Sam Hartman |
2007-12-03
|
05 | Mark Townsley | [Note]: 'After Sam''s discuss is cleared, I need one more position recorded from Dan, Jon or Cullen to have the 2/3 necessary to approve these … [Note]: 'After Sam''s discuss is cleared, I need one more position recorded from Dan, Jon or Cullen to have the 2/3 necessary to approve these specs.' added by Mark Townsley |
2007-12-03
|
05 | Mark Townsley | Note field has been cleared by Mark Townsley |
2007-09-26
|
05 | Mark Townsley | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Mark Townsley |
2007-09-26
|
05 | Mark Townsley | [Note]: 'Awaiting -09, and then Mark to writeup IESG note' added by Mark Townsley |
2007-04-19
|
05 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation - Defer by Amy Vezza |
2007-04-19
|
05 | Chris Newman | [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman |
2007-04-19
|
05 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2007-04-19
|
05 | David Ward | [Ballot Position Update] Position for David Ward has been changed to Recuse from No Objection by David Ward |
2007-04-19
|
05 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
2007-04-19
|
05 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2007-04-18
|
05 | Sam Hartman | [Ballot Position Update] New position, Discuss, has been recorded by Sam Hartman |
2007-04-18
|
05 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2007-04-18
|
05 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2007-04-18
|
05 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk |
2007-04-17
|
05 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2007-04-16
|
05 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to Undefined from No Objection by Tim Polk |
2007-04-06
|
05 | (System) | Removed from agenda for telechat - 2007-04-05 |
2007-04-02
|
05 | Sam Hartman | State Changes to IESG Evaluation - Defer from IESG Evaluation by Sam Hartman |
2007-04-02
|
05 | Jari Arkko | [Ballot Position Update] New position, Recuse, has been recorded by Jari Arkko |
2007-03-26
|
05 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
2007-03-23
|
05 | Lars Eggert | [Ballot Position Update] New position, Recuse, has been recorded by Lars Eggert |
2007-03-15
|
05 | Mark Townsley | State Changes to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup by Mark Townsley |
2007-03-15
|
05 | Mark Townsley | Placed on agenda for telechat - 2007-04-05 by Mark Townsley |
2007-03-07
|
05 | Yoshiko Fong | IANA Additional Comments: based on the new version, IANA understood as follows. --- This document is requesting a registration in a registry that is created … IANA Additional Comments: based on the new version, IANA understood as follows. --- This document is requesting a registration in a registry that is created by #22417 Action #1: Upon approval of this document, the IANA will make the following assignments in the "HIP ParmeterTypes" registry located at http://www.iana.org/assignments/TBD sub-registry "Hip Parameter Types" value Type Reference ------------ ------------------------ 193 LOCATOR [RFC-hip-mm-05] Action #2: (Section 5.3) Upon approval of this document, the IANA will make the following assignments in the "HIP ParmeterTypes" registry located at http://www.iana.org/assignments/TBD sub-registry "Notify Message Type" value Type Reference ------------ ------------------------ 193 LOCATOR [RFC-hip-mm-05] We understand the above to be the only IANA Actions for this document. |
2007-03-07
|
05 | Yoshiko Fong | IANA additional Comments; Tom gave us the new IANA Consideration Section. --- "7. IANA Considerations This document defines a LOCATOR parameter for the Host Identity … IANA additional Comments; Tom gave us the new IANA Consideration Section. --- "7. IANA Considerations This document defines a LOCATOR parameter for the Host Identity Protocol [2]. This parameter is defined in Section 4 with a Type of 193. This document also defines a LOCATOR_TYPE_UNSUPPORTED Notify Message Type as defined in the Host Identity Protocol specification [2]. This parameter is defined in Section 5.3 with a Value of 46." |
2007-03-05
|
05 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2007-03-05
|
05 | (System) | New version available: draft-ietf-hip-mm-05.txt |
2007-02-14
|
05 | Yoshiko Fong | IANA Additional comments: IANA received a message from Tom. --- Comment resolution of the secdir review of this draft is likely to result in the … IANA Additional comments: IANA received a message from Tom. --- Comment resolution of the secdir review of this draft is likely to result in the request for a new Notify Message Type value in addition to the below Parameter Type. I will get back to you once the working group decides on a value (hopefully by March 1). |
2007-02-05
|
05 | Yoshiko Fong | IANA Last Call Comments: This document is requesting a registration in a registry that is created by draft-ietf-hip-registration. So the action is: Upon approval of … IANA Last Call Comments: This document is requesting a registration in a registry that is created by draft-ietf-hip-registration. So the action is: Upon approval of this document, the IANA will make the following assignments in the "HIP ParmeterTypes" registry located at http://www.iana.org/assignments/TBD sub-registry "Hip Parameter Types" value Type Reference ------------ ------------------------ 193 LOCATOR [RFC-hip-mm-04] We understand the above to be the only IANA Actions for this document. |
2007-01-30
|
05 | Mark Townsley | Merged with draft-ietf-hip-base by Mark Townsley |
2007-01-30
|
05 | Mark Townsley | [Note]: 'Waiting on secdir LC comments to be resolved' added by Mark Townsley |
2007-01-30
|
05 | Mark Townsley | -------- Original Message -------- Subject: secdir review of draft-ietf-hip-mm-04.txt Date: Mon, 29 Jan 2007 20:49:53 -0500 From: Jeffrey Hutzelman To: ietf@ietf.org, secdir@mit.edu, thomas.r.henderson@boeing.com … -------- Original Message -------- Subject: secdir review of draft-ietf-hip-mm-04.txt Date: Mon, 29 Jan 2007 20:49:53 -0500 From: Jeffrey Hutzelman To: ietf@ietf.org, secdir@mit.edu, thomas.r.henderson@boeing.com, David Ward , Gonzalo Camarillo CC: Jeffrey Hutzelman I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Overall, I found this document to be fairly straightforward and easy to understand, even without a deep background in HIP. It does introduce new security considerations associated with the ability to cause traffic destined for a host to be redirected to a new location. However, these are discussed and, provided HIP itself behaves as advertised, they are adequately addressed. I have a few comments and questions, but nothing to indicate this document should not be published as Experimental. Section 3.1.2: Mobility Overview > This UPDATE packet is acknowledged by the peer, and is > protected by retransmission. What does "protected by retransmission" mean here? ===== Section 3.3.2: Credit-Based Authorization > 2. An attacker can always cause unamplified flooding by sending > packets to its victim directly. This is frequently untrue. The network may be configured such that the attacker does not have direct connectivity to a victim, such as when the victim is inside a firewall and the attack is carried out via a host within within a "DMZ". Or, an attacker may attempt to create congestion on the link between two victims, where the attacher has better connectivity to both victims than they do to each other. IMHO this is not a show-stopper -- the hypothesis quoted above is true in a large number of cases, and it does appear to me that the credit-based authorization scheme described here will have a positive erffect in those cases without otherwise being harmful. However, it is worth pointing out that this is not a cure-all. ===== Section 4.2: Locator Type and Locator Are locator types critical? What happens when a host tries to add or move to a locator which is not supported by its peer? ===== Section 5.2: Sending LOCATORs > The announcement of link-local addresses is a policy decision; such > addresses used as Preferred locators will create reachability > problems when the host moves to another link. In fact, even a host which is not mobile should be careful to avoid advertising link-local addresses to peers not on the same link. ===== 6. Security Considerations > The HIP mobility mechanism provides a secure means of updating a > host's IP address via HIP UPDATE packets. Upon receipt, a HIP host > cryptographically verifies the sender of an UPDATE, so forging or > replaying a HIP UPDATE packet is very difficult (see [2]). > Therefore, security issues reside in other attack domains. I believe this is an accurate assessment. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf |
2007-01-29
|
05 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2007-01-18
|
05 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Jeffrey Hutzelman |
2007-01-18
|
05 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Jeffrey Hutzelman |
2007-01-17
|
05 | Jari Arkko | [Ballot Position Update] New position, Recuse, has been recorded by Jari Arkko |
2007-01-15
|
05 | Amy Vezza | Last call sent |
2007-01-15
|
05 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2007-01-15
|
05 | Mark Townsley | State Changes to Last Call Requested from AD Evaluation by Mark Townsley |
2007-01-15
|
05 | Mark Townsley | Last Call was requested by Mark Townsley |
2007-01-15
|
05 | Mark Townsley | [Ballot Position Update] New position, Yes, has been recorded for Mark Townsley |
2007-01-15
|
05 | Mark Townsley | Ballot has been issued by Mark Townsley |
2007-01-15
|
05 | Mark Townsley | Created "Approve" ballot |
2007-01-15
|
05 | (System) | Ballot writeup text was added |
2007-01-15
|
05 | (System) | Last call text was added |
2007-01-15
|
05 | (System) | Ballot approval text was added |
2006-10-30
|
05 | Mark Townsley | State Changes to AD Evaluation from Publication Requested by Mark Townsley |
2006-09-26
|
05 | Dinara Suleymanova | PROTO Write-up (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, … PROTO Write-up (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? The Document Shepherd for this document is Gonzalo Camarillo, who has personally reviewed this document and believes it is ready to be forwarded to the IESG for publication. (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? Yes, it has been thoroughly reviewed both inside and outside the WG. (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 those issues have been discussed in the WG and the WG has indicated that it still wishes to advance the document, detail those concerns here. No. (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? The whole WG is behind this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire will be entered into the ID Tracker.) No. (1.g) Has the Document Shepherd 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. Yes. (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]. Yes, this document has normative and informative references. The HIP WG has already requested the publication of all its normative dependencies. (1.i) 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 defines mobility and multihoming extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host-- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? No. 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? Yes, a number of vendors are already implementing this draft. |
2006-09-26
|
05 | Dinara Suleymanova | Draft Added by Dinara Suleymanova in state Publication Requested |
2006-06-26
|
04 | (System) | New version available: draft-ietf-hip-mm-04.txt |
2006-03-01
|
03 | (System) | New version available: draft-ietf-hip-mm-03.txt |
2005-07-19
|
02 | (System) | New version available: draft-ietf-hip-mm-02.txt |
2005-02-22
|
01 | (System) | New version available: draft-ietf-hip-mm-01.txt |
2004-10-19
|
00 | (System) | New version available: draft-ietf-hip-mm-00.txt |