Last Call Review of draft-ietf-multimob-pmipv6-ropt-06
review-ietf-multimob-pmipv6-ropt-06-secdir-lc-harkins-2013-08-08-00

Request Review of draft-ietf-multimob-pmipv6-ropt
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-08-13
Requested 2013-06-20
Authors Juan-Carlos Zúñiga, Luis Contreras, Carlos Bernardos, Seil Jeon, Younghan Kim
Draft last updated 2013-08-08
Completed reviews Genart Last Call review of -06 by Alexey Melnikov (diff)
Genart Telechat review of -07 by Alexey Melnikov (diff)
Secdir Last Call review of -06 by Dan Harkins (diff)
Assignment Reviewer Dan Harkins
State Completed
Review review-ietf-multimob-pmipv6-ropt-06-secdir-lc-harkins-2013-08-08
Reviewed rev. 06 (document currently at 08)
Review result Has Nits
Review completed: 2013-08-08

Review
review-ietf-multimob-pmipv6-ropt-06-secdir-lc-harkins-2013-08-08

  Hello,

  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. My apologies
for the tardiness of this review.

  This draft describes an experimental way to use existing protocols
to address a tunnel convergence problem where multiple instance of
the same multicast traffic converges to the same Mobile Access
Gateway. It also defines a new option to support dynamic policy
subscriptions for use with the Proxy Binding Acknowledge message.
It is heavy on acronyms and could use some additional definitions
in section 2 for things like "MAG" and "LMA" (note: I am not a proxy
mobile IPv6 person).

  The draft is ready for publication but I do have a few comments:

  1. It would be easier to read if you move the definition of the new
      option before the description of the two operational modes that
      define the experimental solution, that presumably use the new
      option.

  2. the protocol field "maps the type codification used in the original
      MLD specification for the Report message" and gives two explicit
      values. Is there a registry for this mapping somewhere that might
      be better to point at?

  3. are bits really set to zero and set to one? I thought they were
      set (1) and cleared (0).

  4. the security considerations say that the draft just explains how to
      use existing protocols without modification and therefore does
      not introduce new security threats. That makes me think that the
      problem hasn't even been looked at. It is certainly possible to
      use existing protocols in a way that introduces security problems.
      Maybe expand on why there are none. Also, the draft introduces
      a new option for dynamic policy subscriptions. Are there no
      security issues associated with that addition? If so, it might be
      good to mention that.

  Again, sorry for the delay, I hope these comments are still useful.

  regards,

  Dan.