Re: [secdir] secdir review of draft-ietf-v6ops-mobile-device-profile-04

<mohamed.boucadair@orange.com> Mon, 02 September 2013 08:38 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 EBB1521E80A3; Mon, 2 Sep 2013 01:38:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.234
X-Spam-Level:
X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
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 H1vszhpryGRT; Mon, 2 Sep 2013 01:38:31 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7243811E81CB; Mon, 2 Sep 2013 01:36:35 -0700 (PDT)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id B7511264321; Mon, 2 Sep 2013 10:36:28 +0200 (CEST)
Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 9979027C046; Mon, 2 Sep 2013 10:36:28 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Mon, 2 Sep 2013 10:36:28 +0200
From: mohamed.boucadair@orange.com
To: Simon Josefsson <simon@josefsson.org>, "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" <draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org>
Date: Mon, 02 Sep 2013 10:36:23 +0200
Thread-Topic: secdir review of draft-ietf-v6ops-mobile-device-profile-04
Thread-Index: Ac6mkBaBpJwCb374SYyhCtkWT/I2iQBIPY1A
Message-ID: <94C682931C08B048B7A8645303FDC9F36EF0335DAE@PUEXCB1B.nanterre.francetelecom.fr>
References: <20130831232125.19f0ceb6@latte.josefsson.org>
In-Reply-To: <20130831232125.19f0ceb6@latte.josefsson.org>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.2.80316
Subject: Re: [secdir] secdir review of draft-ietf-v6ops-mobile-device-profile-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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, 02 Sep 2013 08:39:46 -0000

Dear Simon,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : Simon Josefsson [mailto:simon@josefsson.org]
>Envoyé : samedi 31 août 2013 23:21
>À : secdir@ietf.org; iesg@ietf.org; draft-ietf-v6ops-mobile-device-
>profile.all@tools.ietf.org
>Objet : secdir review of draft-ietf-v6ops-mobile-device-profile-04
>
>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.
>
>This (informational) document list a set of features a 3GPP device is
>supposed to be compliant with.  The document contain pointers to other
>protocols/specifications which contains the real security
>considerations for those protocols.  As such, I don't think there could
>be any significant security issue with this document.  Hence my take
>is that the document is Ready with nits (see below).

[Med] Thanks for the review.

>
>A notable point is that there is no discussion or references to IPSec

[Med] IPsec is not explicitly mentioned in this document as it is discussed in these two references cited in the "Security Considerations" section: rfc3316bis and rfc6092. Is there any particular change you want us make in the "Security Considerations" section? Thanks.

>in the document, nor any of the IPv6 "bugs" (e.g., RFC 5722 and RFC
>6946).  There may be other document that could be referenced that would
>lead to improved security, but it is hard to list them all.

[Med] We didn't included explicit references to RFC5722 and RFC6980 as those are already cited in rfc3316bis. "Security Considerations" refers explicitly to rfc3316bis. Is there any particular change you want us to make in "Security Considerations" section? Thanks.

>
>This document seems related to draft-ietf-v6ops-rfc3316bis which
>describe another IPv6 profile for 3GPP hosts.  The utility of having
>two different IPv6 profiles for 3GPP hosts could be discussed, but it
>is only a security issue in the marginal sense that complexity often
>leads to poor security.
>
>The security considerations of this document is only pointers to
>the security considerations of RFC3316bis, RFC6459, and RFC6092 which
>feels underwhelming to me -- especially since the RFC3316bis security
>consideration is for the particular profile that RFC3316bis defines.
>The security considerations of RFC3316bis wouldn't automatically apply
>to the profile defined by draft-ietf-v6ops-mobile-device-profile since
>the profiles are different.

[Med] The relationship between the two documents is explained in the introduction; in particular:

   This document defines a different profile than the one for general
   connection to IPv6 mobile networks defined in
   [I-D.ietf-v6ops-rfc3316bis]; in particular:

   o  It lists an extended list of required features while
      [I-D.ietf-v6ops-rfc3316bis] identifies issues and explains how to
      implement basic IPv6 features in a cellular context.

   o  It identifies also features to ensure IPv4 service delivery over
      an IPv6-only transport.

Because of this difference, this document points to the security considerations of rfc3316bis security section and to RFC6092 because Cellular Devices with LAN capabilities are within the scope of this document. 

>
>Other notes:
>
>* The document uses RFC 2119 language "for precision", although I don't
>  understand what it means for an Informational document to contain
>  MUST languages.

[Med] This use is not specific to this document; see for example: http://tools.ietf.org/html/rfc6092#section-1.2. A note was added to the document to explain this usage.

>
>* The document really really should reference RFC 2460.

[Med] Done.

>
>* The security consideration contains normative text (REQ#34) that
>  typically go into the core part of a document.

[Med] I made this change:

OLD:
   The security considerations identified in [I-D.ietf-v6ops-rfc3316bis]
   and [RFC6459] are to be taken into account.

   REQ#34:  If the cellular device provides LAN features, it SHOULD be
          compliant with the security requirements specified in
          [RFC6092].

NEW:
   The security considerations identified in [I-D.ietf-v6ops-rfc3316bis]
   and [RFC6459] are to be taken into account.

   Security-related considerations that apply when the cellular device
   provides LAN features are specified in [RFC6092].  

RFC6092 is already called out in the core part of the document.

>
>* I found REQ#32 a bit too generalized.  I believe it is common for
>  applications to be aware of whether connections are over IPv4 or IPv6
>  and behave differently.
>   >REQ#32:  Applications MUST be independent of the underlying IP
>   >       address family. This means applications must be IP version
>   >       agnostic.
>

[Med] I agree this is a too generalized requirements. We have it on purpose to encourage applications devs to avoid making assumptions on the underlying available connectivity. FWIW, our teams tested devices that support IPv6 connectivity... but that embed applications which are broken when IPv6 connectivity is enabled (e.g., ip address literals). An education effort is still needed to avoid this kind of brokenness. 

>/Simon