Re: [DMM] Review of draft-ietf-dmm-4283mnids-04

["Sri Gundavelli (sgundave)" <[e-mail]>]

Thank you Dale for a great review.


Charlie/Authors - Can you please respond to Dale and address these
comments.


Regards
Sri


On 1/31/17, 11:34 AM, "dmm on behalf of Dale Worley" <[e-mail]
on behalf of [e-mail]> wrote:

>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]
>
>
>_______________________________________________
>dmm mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dmm