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

From: Simon Josefsson <[email-masked]>
Date: Sat, 31 Aug 2013 23:21:25 +0200

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