Securing Mobile IPv6 Route Optimization Using a Static Shared Key
RFC 4449

Note: This ballot was opened for revision 04 and is now closed.

(Brian Carpenter) No Objection

(Margaret Cullen) (was Discuss, No Objection, Yes) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

Comment (2005-10-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I think I'm confused. The document says in the Introduction:

   This mechanism is also limited to use only in
   scenarios where mobile nodes can be trusted to not misbehave, as the
   validity of the claimed care-of addresses is not verified.

In the applicability statement, it goes on to say:

  -  The correspondent node has good reason to trust the actions of
       the mobile node.  In particular, the correspondent node needs to
       be certain that the mobile node will not launch flooding attacks
       against a third party as described in [2].

But the Security Considerations don't contain any details about what happens
if this trust is misplaced.  draft-ietf-mip6-ro-sec-03 has quite a taxonomy
of potential issues; I would have thought that a basic run-through of those
would be useful.  Not that it needs to go through the whole document, but
a statement about whether any existing consideration (one of the flooding
attacks?)  are worsened by this approach or that none are would seem
like a valuable addition.


Charlie responded:

 do not agree with this.  It would be wrong to repeat the contents of
draft-ietf-mip6-ro-sec-NN here, and there isn't any real relevance.  The
point of the document is to provide a good way to secure Binding Updates,
and in fact my major complaint with draft-ietf-mip6-ro-sec-NN was that
it often seemed to imply that Mobile IPv6 was vulnerable to situations
caused by insecure Binding Updates.  That would be wrong, because a
crucial point of the design of Binding Update was to ensure security.
The cited document did not make that clear enough in my opinion, and
as a result people would run around acting very worried.  Keep in mind
that the cited Internet Draft was written _years_ after the Binding
Update was well-secured, so that this raised quite unwarranted fears.

Nevertheless, if you would like to see some specific text in the current
document under discussion, please send it to me and I reckon it would
go in, as a way of eliminating concerns from future readers with similar
worries.

(Sam Hartman) (was Discuss, No Objection) No Objection

(David Kessens) (was Discuss) No Objection

Comment (2005-07-07)
No email
send info
I received the following comments from Pekka Savola on the Ops Directorate:

minor editorial issues
----------------------

   When a Binding Update is to be authenticated using such a
   precomputable binding key (Kbm), the Binding Authorization Data
   suboption MUST be present.  The Nonce Indices option SHOULD NOT
   be present.  If it is present, the nonce indices supplied MAY be
   ignored and are not included as part of the calculation for the
   authentication data, which is to be carried exactly as specified
   in [1].


==> "MAY be ignored" ?  What is the alternative?  Shouldn't this
be "MUST be ignored" or "SHOULD be ignored"? (This seems like an
editorial issue, because AFAIR "may be ignored" in English can be
interpreted with at least two levels of normativeness)
 
   A correspondent node and a mobile node MAY use a precomputable
   binding management key (Kbm) to manage the authentication
   requirements for binding cache management messages.

==> I'd replace "MAY" with "may", because this doesn't seem to be
something that requires uppercasing.

(Allison Mankin) (was Discuss) No Objection

Comment (2005-10-04)
No email
send info
My Discuss is handled in to-come 04 (pretty simply because I just asked for a normative ref and didn't
say how to couch it); I clear in advance because Sam added a more detailed Discuss related to BCP 107
issues after mine.  

(I replied on Oct 3 to email from Basavaraj Patil dated Sep 29, to all the Discussant ADs and author)

From that mail:
>
> Allison Mankin:
> Discuss:
> [2005-07-07] I'll put in this Discuss because of Russ's absence.  My=20
> attention has been drawn for some
> Transport documents to the expertise in BCP 107 (RFC 4107), and=20
> especially given the fact that
> there is self-definition of the applicability of the trust model for=20
> this usage, the manual keys
> here at least seems to me to need to meet the cryptographic=20
> requirements in BCP 107, such as:
>
>   When manual key management is used, long-term shared secrets MUST be
>   unpredictable "random" values, ensuring that an adversary will have
>   no greater expectation than 50% of finding the value after searching
>   half the key search space.
>
> There are other discusses like this, but I'm not sure if they call for

> specifying the
> key generation procedure to ensure randomness.  There's also a SHOULD
in
> BCP 107 for a sufficiently long key.  BCP 107 may need to be normative

> here.

Done.

(Jon Peterson) (was No Record, No Objection) No Objection

Comment (2005-07-06 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
The Abstract might be a bit more concrete. Unusual way of splitting the references...

(Bert Wijnen) No Objection

Comment (2005-07-06 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
It seems to me that a normative reference to RFC2119 (use of RECOMMENDED
and MUST) needs to be added. And a citation of course.

(Alex Zinin) No Objection