Re: [DMM] Review of draft-ietf-dmm-4283mnids-04
Charlie Perkins <charles.perkins@earthlink.net> Thu, 02 February 2017 06:10 UTC
Return-Path: <charles.perkins@earthlink.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D0F1293E9; Wed, 1 Feb 2017 22:10:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.888
X-Spam-Level:
X-Spam-Status: No, score=-5.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L4=0.001, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSdI3YHjkYf3; Wed, 1 Feb 2017 22:10:18 -0800 (PST)
Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9B541293EB; Wed, 1 Feb 2017 22:10:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1486015817; bh=x3HXDok/hHhnrTVX8MxFMbwSR5qc/TAYBNkK DaTz6OA=; h=Received:Subject:To:References:Cc:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; b=Adjph8i HRWUukzM+PAZenxSiRoJEFlc43bMa1HkqlDDouUO/MPdOVURNH5dUTSVVgbMjmFbTBJ rxIdcBoI686HJqPukvthzIjuYVcm1GZupOJ3TYIk3LfcGfgAijAV0rtR38leIuuZtaw CrWIpE+W0qsbdXdtcuusMw+YmZxntKkWc3A+btJL8iCIIAYFfGpxLWVezbKMQuAciez RtMwc3Zcy+IA3jsPmG21scNDjVPli01/XNgK2ZCN5IAJR6tt+WBmAsMupJ/cx8fJmUt KKQCxcEzVvnIioUB4HTouqjapIzxvmCrNYZUD9I9ztdWoZC+CabM8pCI+7zHYgGT01A ==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=TcBMIhJbMY+uEKw7mtmEWPKj0m3/5Y2qKUsT9+tgGvDAfKsU7bU/AKdFxcAyvUfh9cdwuMDV+D+HykCG2ZJbh0p3eR4zNCtt9fC6luKDR3dOrRqWdMiAMKsqeuoNq2dS8yv1slqAmG/grwXx/nVGSKfZtSw2C9gRalFohqfPKPSSXEbaJxkHYeEUld+9YA2jWF45i7yXqim5tpgwY/i75GAw9iAjKd/SiS8x8/ej0SSQuu8To6XmpFYFnsHEALJwkg3BgqY+pnuHu/Y3UDRKMthvjTmjoI0PloMJ6oLegvAivWHvTdHq1z7xljPobtV1gr7bWM6SQyPS3s4cxQ+Ugg==; h=Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1cZAb1-0000v3-7i; Thu, 02 Feb 2017 01:10:15 -0500
Subject: Re: [DMM] Review of draft-ietf-dmm-4283mnids-04
To: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>, Dale Worley <worley@ariadne.com>, "gen-art@ietf.org" <gen-art@ietf.org>
References: <148589124578.6067.10086408452323670298.idtracker@ietfa.amsl.com> <D4B7FC35.258902%sgundave@cisco.com>
From: Charlie Perkins <charles.perkins@earthlink.net>
Message-ID: <17671de0-7238-3a3f-c5b6-d6e8bbd3a5e2@earthlink.net>
Date: Wed, 01 Feb 2017 22:10:06 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <D4B7FC35.258902%sgundave@cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac703c35547c62c55d8cd28b8f65ed96334350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/nYxD0_BtgIRpW_NkjRlYhSa3RwM>
Cc: "draft-ietf-dmm-4283mnids.all@ietf.org" <draft-ietf-dmm-4283mnids.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "dmm@ietf.org" <dmm@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Feb 2017 06:10:21 -0000
Hello Sri, The review was indeed super. I'll respond sometime in the next few days. Regards, Charlie P. On 2/1/2017 9:09 PM, Sri Gundavelli (sgundave) wrote: > 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@ietf.org > on behalf of worley@ariadne.com> 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@neclab.eu> >> 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@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm >
- Review of draft-ietf-dmm-4283mnids-04 Dale Worley
- Re: [DMM] Review of draft-ietf-dmm-4283mnids-04 Sri Gundavelli (sgundave)
- Re: [DMM] Review of draft-ietf-dmm-4283mnids-04 Charlie Perkins
- Re: [DMM] Review of draft-ietf-dmm-4283mnids-04 Suresh Krishnan
- Re: [DMM] Review of draft-ietf-dmm-4283mnids-04 Charlie Perkins
- Re: [DMM] Review of draft-ietf-dmm-4283mnids-04 Suresh Krishnan
- Re: Review of draft-ietf-dmm-4283mnids-04 Charlie Perkins
- Re: [DMM] Review of draft-ietf-dmm-4283mnids-04 Sri Gundavelli (sgundave)
- Re: Review of draft-ietf-dmm-4283mnids-04 Dale R. Worley
- Re: [DMM] Review of draft-ietf-dmm-4283mnids-04 Dale R. Worley
- Re: [DMM] Review of draft-ietf-dmm-4283mnids-04 Charlie Perkins
- Re: [DMM] Review of draft-ietf-dmm-4283mnids-04 Dale R. Worley
- Re: [DMM] Review of draft-ietf-dmm-4283mnids-04 Sri Gundavelli (sgundave)
- Re: [DMM] Review of draft-ietf-dmm-4283mnids-04 Charlie Perkins
- Re: [Gen-art] Review of draft-ietf-dmm-4283mnids-… Jari Arkko