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

From: Fred Baker <[email-masked]>
Date: Sun, 1 Sep 2013 14:54:56 -0700

Wearing shepherd hat...

I assume you'll have an updated document posted soon. Please work with Simon and make sure he's satisfied with the updates.

On Aug 31, 2013, at 2:21 PM, Simon Josefsson <[email-masked]> wrote:

> 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).
> 
> A notable point is that there is no discussion or references to IPSec
> 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.
> 
> 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.
> 
> 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.
> 
> * The document really really should reference RFC 2460.
> 
> * The security consideration contains normative text (REQ#34) that
>  typically go into the core part of a 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.
> 
> /Simon

If at first the idea is not absurd, then there is no hope for it.  
Albert Einstein

---

From: <[email-masked]>
Date: Mon, 2 Sep 2013 10:36:23 +0200

Dear Simon,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : Simon Josefsson [mailto:[email-masked]]
>Envoyé : samedi 31 août 2013 23:21
>À : [email-masked]; [email-masked]; draft-ietf-v6ops-mobile-device-
>[email-masked]
>Objet : secdir review of draft-ietf-v6ops-mobile-device-profile-04
>

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

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

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

>  understand what it means for an Informational document to contain

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

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

>   >       address family. This means applications must be IP version

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

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 2 Sep 2013 16:31:18 +0200

You wrote:

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

No -- that was a general observation.  However both rfc3316bis and
rfc6092 are informative references in your document, so what you say
above combined with...

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

...what you say here makes it sounds as if rfc3316bis should be a
normative reference to me.  It seems like reading rfc3316bis is
essential to get a good understanding of this document.

> >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.
> 
>       [I-D.ietf-v6ops-rfc3316bis] identifies issues and explains how
> to implement basic IPv6 features in a cellular context.
> 
> 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.

OK.

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

OK.

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

Thanks.  Having a normative reference to 2460 also takes care of my
concern about not referring to RFC 5722 and RFC 6946.

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

Thanks, this seems clearer to me.

> >  applications to be aware of whether connections are over IPv4 or
> > IPv6 and behave differently.
> [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. 

I understand and completely agree!

/Simon

---

From: <[email-masked]>
Date: Tue, 3 Sep 2013 07:52:16 +0200

Hi Simon,

Ok to move rfc3316bis to the normative references. 

I implemented all the changes we agreed. FWIW, I will send you a message when the new revision is available online.

Many thanks for your review. Much appreciated.

Cheers,
Med

>Envoyé : lundi 2 septembre 2013 16:31
>À : BOUCADAIR Mohamed IMT/OLN
>Cc : [email-masked]; [email-masked]; draft-ietf-v6ops-mobile-device-
>Objet : Re: secdir review of draft-ietf-v6ops-mobile-device-profile-04
>
>You wrote:
>