Subject: [secdir] review of draft-ietf-multimob-pmipv6-ropt-07

From: "Dan Harkins" <[email-masked]>
Date: Mon, 5 Aug 2013 11:27:16 -0700 (PDT)

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.

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 05 Aug 2013 23:28:53 +0200

Dear Dan,

Thanks a lot for your review. Please see some comments inline below.

> in section 2 for things like "MAG" and "LMA" (note: I am not a proxy

We reference in Section 2 the different documents where the terms used
in the document are originally defined. This is the case of MAG and LMA,
which are proxy mobile IPv6 specific entities. We believe that it is
better not to reproduce all those definitions in the document, but we
could do it if it helps improving the readability.

We will reduce the use of acronyms in -08, by expanding some of them.

>       define the experimental solution, that presumably use the new

The option is used to allow conveying dynamic policies to perform the
operational mode selection, but it is not mandatory to use the option,
as manual configuration is also possible. We describe this in section
3.3. Therefore, we believe that defining the option before would
probably not help. An alternative approach could be to move Section 3.3
before current 3.1 and 3.2. Do you think that would address your
comment?

>       values. Is there a registry for this mapping somewhere that might

The values are defined in MLDv2 (RFC 3810) and MLDv1 (RFC2170) specs.
Would the following revised text be more clear?

   Protocol:

      Field used to identify the multicast membership protocol in use,
      and the corresponding format of the next Multicast Address Record.
      This field maps the type codification used in the original MLD
      specifications for the Report message, namely for MLDv2 [RFC3810]
      the Protocol value MUST be 143, whereas for MLDv1 [RFC2710] the
      Protocol value MUST be 131.

By the way, thanks to your comment we have realized that there was a nit
in the values included in -07. The values are decimal (143 and 131) and
not hex (0x143 and 0x131) as in -07. This will be fixed in -08.

>   3. are bits really set to zero and set to one? I thought they were

Fixed.

>       security issues associated with that addition? If so, it might be

The addition of the new option does not address any security issue as
long as the signaling is properly secured reusing Proxy Mobile IPv6
mechanisms. We will add some text in -07 stating more clearly this point
(i.e., mentioning that the new mobility option defined in the document
is conveyed in the proxy binding acknowledge message, which is protected
by the IPsec security mechanism mandated by Proxy Mobile IPv6).

Thanks,

Carlos