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

[Simon Josefsson <[e-mail]>]

You wrote:

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

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

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

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

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

OK.

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

OK.

> >* The document really really should reference RFC 2460.
> 
> [Med] Done.

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

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

Thanks, this seems clearer to me.

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

I understand and completely agree!

/Simon