|
Hello Dale, Thanks for the thorough review. My follow-up comments are inline
below. On 1/31/2017 11:34 AM, Dale Worley
wrote:
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"? I will add some text according to your suggestion. My criterion for whether the identifier type was included in the document was whether or not anyone had asked for it to be included. - 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 It is not the jurisdiction of the MNIDs document to specify these identifiers, but citations for the specifications are located elsewhere in the document. I will also include those citations here. 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. I don't know why this happened, but I am happy to include an identifier type for IMEI as well as a citation for it. Thanks for catching this and looking through the archives!
Actually, I am O.K. either way on this matter. However, at this point in time it does not seem that we are likely to see any other link hardware address types to be used as MNIDs. 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. There is a sort of "hidden" disadvantage to long names, especially for tiny devices using constrained link layers. Namely, a longer name makes it more likely to require lower-layer fragmentation. I'm not sure that it should be the job of a layer-3 mobility entity to parse URNs and determine if two different flavors are supposed to be equivalent. Other than that, I don't have any real objection to reorganizing the namespace, but I'd like some additional confirmation that it's a good idea. 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. I am O.K. with this. I need to go find out where I got that language from, because I don't think I was the person who crafted it. 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. Thanks for this observation. I will make the corresponding revisions to the text. 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)! O.K. with your modification. The document just defines numbers for the types, not the types. 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. I will insert text from the relevant 3GPP documents to describe these identifiers. 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. O.K. Thanks for the suggestion. 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 Thanks for the text. I will use it. -- 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. This is a good idea. How about the following: For each RFID scheme except GID, there are three representations: I didn't originate the use of URI for the non-binary representation. The EPC document has the following language:
If I were to change it to URN, then I would have to go into some detail about why this document somehow disagrees with the EPC-Tag-Data document. Do you think that is necessary? 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. I read through some relevant text in the EPC-Tag-Data document and it seems O.K. to me, but nontrivial and it relies on digging through other even more arcane documents to be absolutely sure. I am pretty sure that the IETF document should not get into the business of augmenting the standards already in place from the external SDOs. 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. I hope that this document does not have to specify allocation procedures for the MNIDs. It seems to me that if a system designer wants to use one of the MNID types, that person will already know about how to request the allocation and would not need to rely on the MNIDs document for that information. Plus it's really out of scope. This document was always intended to be a simple tabulation of types already in use elsewhere and enabling IETF mobility management protocols to use the most natural identifier available for a mobile node. I hope that citing the defining documents for the identifier types will be enough to satisfy that. 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. As far as I have understood, the unicast IPv6 address in use as a MNID is already assigned to the device. I have not heard anyone asking for this to be an address for future assignment. I'll try to make that clear in the text. 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. I probably lifted that language directly from the IMSI spec, but I can make further clarification according to your suggestion. 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". O.K. I also lifted that language from elsewhere. 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. Here I am at a loss, because I was specifically requested to insert some descriptive but not normative text. I will ask the person who made the request to provide their feedback on the mailing list. For myself, I am more than happy to delete the text. 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. This text was meant to be generally descriptive, so that people wanting to include the Mobile Node Identifier Option with the relevant MNIDs could understand how the identifiers are actually used in various circumstances. I could replace constructions using "might" with "in some specifications" or "in some situations" if needed. Is it also necessary to include citations to the relevant documents of the external SDO? Regards, Charlie P. |