Review of draft-ietf-dmm-4283mnids-04

[Dale Worley <[e-mail]>]

Reviewer: Dale Worley
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft.  The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document:  draft-ietf-dmm-4283mnids-04
Reviewer:  Dale R. Worley
Review Date:  31 Jan 2017
IETF LC End Date:  2 Feb 2017
IESG Telechat date:  16 Feb 2017

Summary:

       This draft is on the right track but has open issues,
described
       in the review.

Technical issues:

1. The Introduction states

   Other types of identifiers are in
   common use, and even referenced in RFC 4283.

For the reader's sanity, some sort of accounting needs to be made of
these "other types of identifiers", especially because each type of
identifier needs an identifier type number.  The text in 4283 is

   Some examples of identifiers
   include Network Access Identifier (NAI), Fully Qualified Domain
Name
   (FQDN), International Mobile Station Identifier (IMSI), and Mobile
   Subscriber Number (MSISDN).

Are there any other types "in common use"?

- NAI (type 1) is defined by 4283.
- Fully Qualified Domain Name (FQDN) seems not to be specified
- International Mobile Station Identifier (IMSI) (type 3) is defined
in
  this draft
- Mobile Subscriber Number (MSISDN) seems not to be specified

2. Is it intended to have an IMEI identifier type?  The introduction
mentions an IMEI type, but there is no specification for it, nor is
there an identifier type number assigned for it.

   ... types for IMSI
   [ThreeGPP-IDS], P-TMSI [ThreeGPP-IDS], IMEI [ThreeGPP-IDS], and
GUTI
   [ThreeGPP-IDS].

Initially I suspected it was it was present in an earlier revision
and
then later deleted without this reference being updated.  But all
versions of draft-ietf-dmm-4283mnids and its predecessor
draft-perkins-dmm-4283mnids mention IMEI in this way as one
identifier
type, but none specify it in any way.  The only discussion I can find
on the DMM mailing list of IMEI is:

   
https://mailarchive.ietf.org/arch/msg/dmm/pNmtaq6-JOQ4RuXy_D7Zc2JgvYk/?qid=d29575f767ce67a1e67a7767008ee6af

    From: Marco Liebsch <[e-mail]>
    To: DMM
    Date: Wed, 10 September 2014 13:29 UTC
    Re: [DMM] regarding the re-chartering..

    It seems the MNID is somehow overloaded to carry both,
node-specific
    IDs, e.g. MAC, as well as subscriber IDs, which is the IMSI.
    There may be value in adding the IMEI to the list of possible
types of
    node-specific IDs. 

Either the presence of IMEI in this list is a simple mistake that has
persisted in all versions of the draft, or specifying IMEI has always
been intended but has always been overlooked.

3. The definition of identifier types for both EUI-48 and EUI-64
suggests that it might be desirable to define an identifier type for
arbitrary hardware (link-level) addresses.  It seems that the natural
differentiator for that purpose is the "hardware type" used in ARP,
so
a EUI-48 address would be represented as

    MN identifier type (one octet) 5 (say)
    hardware type (two octets) 1
    EUI-48 (six octets)

and an EUI-64 similarly, with hardware type 27.

Although with only two subtypes in common use, generalizing this
might
not be worth the effort.

4. Several of the identifier types can be represented as URNs:

- IMEI can be represented as a URN as urn:gsma:imei:...
- all of the RFID types have a URN representation (called the
  "pure-identity URI" in the RFID specifications), which starts
  urn:epc:id:...

Since all URN types are ensured of being unique and persistent, it
seems that we could define a MNID type for URNs generally, and then
any RFID URI or an IMEI (as a URN) could be used as a value of that
type.

If this idea is adopted, it seems that the other 3GPP types (IMSI,
P-TMSI, and GUTI) should be given defined encodings as URNs in new
sub-namespaces of the "gsma" URN namespace, to parallel the encoding
of IMEIs defined in RFC 7254.

This consolidation could be significantly beneficial.  It allows MNID
to use any URN scheme as an identifier.  It reduces the three
different RFID representations to one.  It incorporates any future
expansion of RFID schemes (because all schemes will have a
pure-identity URN representation).  A disadvantage is that the URN
encodings are long, but the security considerations section states
that MNIDs are used only on the first registration at the home agent,
so there isn't much need for brevity.

Similarly, this approach incorporates any future expansion of mobile
identifiers that GSMA decides to define, as long as GSMA provides a
URN representation for it.

The most significant disadvantage is that some URN schemes allow
several character strings to "mean" the same URN.  In most URN
schemes, the allowed variation is limited to the case of letters, and
the common convention is to always use lower-case when there is a
choice, leading to a unique conventional canonical form for the URN.

5. Regarding the encoding of a string of digits into octets, it is
stated that "The last digit MUST be zero padded, if needed, for full
octet size."  This seems very unwise unless there is a 3GPP decree
that if a zero is appended to a valid IMSI, the resulting string is
never a valid IMSI.  Instead, I would specify that padding is by
filling the low-order 4 bits of the final octet with 0xF.  That
ensures that the encoding can be uniquely decoded into an IMSI.

6. There are four types of DUID specified, each with a distinct MNID
value.  However, DUIDs contain an initial two-octet type field which
distinguishes the various types of DUID, so providing them with
distinct MNID values is redundant.

Distinguishing the types and allowing only four of them to be used as
MNIDs seems to be contrary to the philosophy of DUID construction
(RFC
3315 section 9):

   Clients and servers MUST treat DUIDs as opaque values and MUST
only
   compare DUIDs for equality.  Clients and servers MUST NOT in any
   other way interpret DUIDs.  Clients and servers MUST NOT restrict
   DUIDs to the types defined in this document, as additional DUID
types
   may be defined in the future.

Of course, MNID isn't a DHCP operation, so it isn't subject to those
requirements, but I expect that devices will use the same DUID for
both mobile identification, and we don't want mobile identification
to
restrict future developments of DHCP.

I think this specification must treat DUIDs as opaque and use only
one
MNID type that allows all types of DUIDs as values.

Editorial issues:

Abstract

   Additional Identifier Types are proposed for use with the Mobile
Node
   Identifier Option for IPv6 (RFC 4283).

s/proposed/defined/
This document will define the new types (once it is approved)!

1.  Introduction

   ... types for IMSI
   [ThreeGPP-IDS], P-TMSI [ThreeGPP-IDS], IMEI [ThreeGPP-IDS], and
GUTI
   [ThreeGPP-IDS].

There is no description of P-TMSI identifiers, although it is
assigned
identifier type 4.

There is no description of GUTI identifiers, although it is assigned
identifier type 7.

3.  New Mobile Node Identifier Types

   The following types of identifiers are commonly used to identify
   mobile nodes.  For each type, references are provided with full
   details on the format of the type of identifier.

   The Tag Data standard promoted by Electronic Product Code(TM)
   (abbreviated EPC) supports several encoding systems or schemes
   including

   o  RFID-GID (Global Identifier),
   o  RFID-SGTIN (Serialized Global Trade Item Number),
   o  RFID-SSCC (Serial Shipping Container),
   o  RFID-SGLN (Global Location Number),
   o  RFID-GRAI (Global Returnable Asset Identifier),
   o  RFID-DOD (Department of Defense ID), and
   o  RFID-GIAI (Global Individual Asset Identifier).

   For each RFID scheme except GID, there are two variations: a
64-bit
   scheme (for example, SGLN-64) and a 96-bit scheme (SGLN-96).  GID
has
   only a 96-bit scheme.  Within each scheme, an EPC identifier can
be
   represented in a binary form or other forms such as URI.

   The following list includes the above RFID types as well as
various
   other common identifiers and several different types of DUIDs.

The organization of the text here seems to be poor -- section 3
enumerates the new identifier types, but much of the text at the
beginning of the section is about the RFID-EPC set of types.  It
seems
like a better organization is to use just paragraph 1 followed by
table 1, and move paragraphs 2-5 into section 4.9.

   The Tag Data standard promoted by Electronic Product Code(TM)
   (abbreviated EPC) supports several encoding systems or schemes
   including

The text is using "Tag Data", "EPC", and "RFID" in a way that is
intertwined but not explained.  I can see that it might be useful to
use all of the terms if they commonly used in the field (don't forget
to make them keywords for the RFC!), but you need to explain their
connection and distinction to the reader or make it clear that the
reader does not need to understand the differences among the terms.
E.g., this formulation ties all three terms together

   The Tag Data standard promoted by Electronic Product Code(TM)
   (abbreviated EPC) supports several encoding systems or schemes
   which are commonly used in RFID (radio-frequency identification)
   applications, including

--

   For each RFID scheme except GID, there are two variations: a
64-bit
   scheme (for example, SGLN-64) and a 96-bit scheme (SGLN-96).  GID
has
   only a 96-bit scheme.  Within each scheme, an EPC identifier can
be
   represented in a binary form or other forms such as URI.

The text uses "scheme" to mean the distinction between encoding
systems (GID, SGTIN, etc.) and and also to mean the distinction
between the 64-bit and 96-bit variations.  This ambiguity is unwise.
It matters here, because you say "within each scheme ... can be
represented in a binary form or ... URI".  Which meaning of "scheme"
are you using here?  I thought you meant the second meaning when I
first read the paragraph, but after reading external documents about
EPC, I now understand that that last sentence uses "scheme" to in the
first sense.

You need to be clearer here that there are three representations
used,
64-bit binary, 96-bit binary, and URI (URN, actually), and
representation is orthogonal to the seven RFID schemes, with the
exception that RFID-GID does not have a 96-bit binary representation.

I'm assuming that the Tag Data standard unambiguously defines the
serialization of the binary representations as a sequence of octets.
If it does not, this document MUST do that, or you will have an
endless nightmare of byte-order problems.

4.  Descriptions of MNID types

Identifier ownership is a general concern -- it's worth mentioning
for
each type of identifier where the assigner of the identifier obtains
delegation.  For an EUI, I expect the reader will assume that it's an
EUI assigned to the device under IEEE rules, and similarly for RFID
and 3GPP identifiers.  But for DUID identifiers, it's less clear. 
I'm
guessing that the DUID is one that is, or could be, used by the
device
for DHCP purposes.  For IPv6 addresses, it's even less clear, since
the IPv6 architecture doesn't assume that the association of
addresses
with devices is permanent.

4.1.  Description of the IPv6 address type

It would be good if the document described what the semantics of this
ID are.  Yes, it's a unicast IPv6 address, but what is the connection
between that address and the device?  I suspect the connection is
"the
device has been configured to expect that it will be assigned this
address as a long-term interface address", but there are other
possibilities.  E.g., I can imagine a mobile carrier obtaining a /64
prefix (there are plenty of them!) and then assigning addresses out
of
it simply to create a sequence of unique identifiers for devices, but
not using those addresses on packets.

Then again, perhaps you want to allow flexibility.  But in any case,
I
think you need to specify what the rules are for what address is
associated with what device.

4.2.  Description of the IMSI MNID type

What does "in network order" mean here?  As far as I know, there is
no
defined "network order" for 4-bit quantities, only for dividing
integers into octets and placing sequences of bits into octets.  I
assume you mean that in any octet, the high-order 4 bits are the
first
digit and the low-order 4 bits are the second digit, but I think you
need to state that explicitly.

4.3.  Description of the EUI-48 address type

   The IEEE EUI-48 address [IEEE802-eui48] is encoded as a 6 octet
   string containing the IEEE EUI-48 address.

Is "string" the correct word, this not being a sequence of
characters?
I would say "sequence of 6 octets" or simply "encoded as 6 octets".

4.9.  Description of the RFID types

This section needs to be revised.  It provides a lot of detail about
the RFID types, but it's not enough detail for a reader who doesn't
understand RFID to learn how any particular RFID scheme works.  E.g.,
the first paragraph says that GID contains three fields in the first
sentence, and that it contains four fields in the third sentence.
Despite this, the description isn't enough to allow the reader to
construct GID identifiers manually.

On the other hand, readers who already understand the RFID schemes
will find this text redundant.

I think that almost all of this text can be replaced by references to
the EPC documents, since these identifiers are opaque from the point
of view of mobile identification.

5.  Security Considerations

The base MNID specification, RFC 4283, gives these security
considerations (sec 4), which ought to be referenced and probably
summarized in this section:

   Moreover, MNIDs containing sensitive identifiers might only be
used
   for signaling during initial network entry.  Subsequent binding
   update exchanges might then rely on a temporary identifier
allocated
   during the initial network entry, perhaps using mechanisms not
   standardized within the IETF.  Managing the association between
long-
   lived and temporary identifiers is outside the scope of this
   document.

What is the meaning of the word "might" in paragraph 3?  I suspect
that the purpose is to qualify this paragraph with "One way to
address
these vulnerabilities is to only use MNIDs containing ...".  But if
that is the meaning, that expanded wording should be used.  Otherwise
the text reads as if it is hypothetical.

[END]