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
>