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" <dmm-bounces@xxxxxxxx on behalf of worley@xxxxxxxxxxx> 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 <Marco.Liebsch@xxxxxxxxx> > 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 >dmm@xxxxxxxx >https://www.ietf.org/mailman/listinfo/dmm