End-Host Mobility and Multihoming with the Host Identity Protocol
draft-ietf-hip-mm-05

[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

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.

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."

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).

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.

-------- 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

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.