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

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Mon, 05 August 2013 21:29 UTC

Return-Path: <cjbc@it.uc3m.es>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B283D21F9D02; Mon, 5 Aug 2013 14:29:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyWMmH0j4cyi; Mon, 5 Aug 2013 14:29:02 -0700 (PDT)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 69ED721F9C7B; Mon, 5 Aug 2013 14:29:01 -0700 (PDT)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A403DCD6586; Mon, 5 Aug 2013 23:29:00 +0200 (CEST)
X-uc3m-safe: yes
X-uc3m-safe: yes
Received: from [10.3.251.252] (interdigital.vlan431.asr1.yyz1.gblx.net [208.49.79.242]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id D68A8CD641A; Mon, 5 Aug 2013 23:28:59 +0200 (CEST)
Message-ID: <1375738133.4571.19.camel@acorde.it.uc3m.es>
From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es>
To: Dan Harkins <dharkins@lounge.org>
Date: Mon, 05 Aug 2013 23:28:53 +0200
In-Reply-To: <af32bbd31aede24d7237b6b5023afc14.squirrel@www.trepanning.net>
References: <af32bbd31aede24d7237b6b5023afc14.squirrel@www.trepanning.net>
Organization: Universidad Carlos III de Madrid
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.4.4-3
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20060.002
X-Mailman-Approved-At: Mon, 05 Aug 2013 17:35:56 -0700
Cc: draft-ietf-multimob-pmipv6-ropt.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] review of draft-ietf-multimob-pmipv6-ropt-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: cjbc@it.uc3m.es
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Aug 2013 21:29:09 -0000

Dear Dan,

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

On Mon, 2013-08-05 at 11:27 -0700, Dan Harkins wrote:
>   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).

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.

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

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?

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

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
>       set (1) and cleared (0).

Fixed.

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

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
 
> 
>   Again, sorry for the delay, I hope these comments are still useful.
> 
>   regards,
> 
>   Dan.
> 
> 
> 
> 
>