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

Charlie Perkins <charles.perkins@earthlink.net> Tue, 14 February 2017 05:19 UTC

Return-Path: <charles.perkins@earthlink.net>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9613E1293F2; Mon, 13 Feb 2017 21:19:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] 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 TUh48_2MheQo; Mon, 13 Feb 2017 21:19:53 -0800 (PST)
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6EDC12947B; Mon, 13 Feb 2017 21:19:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1487049591; bh=oQL8LJ6JXMs2JvYPClb8bnZ1wKrcwZo0B48V KdgI39Q=; 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=Go617Mm hd1IapmbNf1rZnFYJ+NFgTLvJvJGZSDcoHvEy7FsM1N5YXHLmAM2txhzKj+ct7vGrcq wxrihlgq/Vq9VKfmJePpsctYVGQ4sT7Qp6PTmJY5mL8gALlqNIwzHRwyOcSxBo2nUXf 6THOOVzSTp4EXwndtsVKCzNTKM8ntZX+iCGfQmPX4aj4qHthAQt0aZjUZPcVbAE/Rbt mY691TloIA9Hm4gW7lA3tO3nPx7zyb0t1hXgbgGnyfyN8Yl+//js/BxfqiVBLXr+2j8 sb9UP1t6X/znzX8cjNTkmE3ZNvqg5itiBvrsYAw+ZnKrlxzmH74L5B0aBJUCRBUIi2w ==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=DhvR0B69kFGg/8vEOlRmbCkPxhpttcNF9gEzxBAJRqrecxA14mhLcjDE2PoSUH8ljWjrnRcjEvL1zrh/fkYTgDIrc+F3wRVgLfF5DezlgtaS/uf15ScECCBD/xhIVBDr8dCY1bun12qWZMawMNBSJSjlvtePXzThnXLcKT0kadmRAB6Okn87Qs8x00xXkePANsBHOs/iu9g7oVFgk1AWKZ+93b6ImGd1cIui7JpGX5NFFw4i6xXhhhj7vixAfeb3Up5Jl+y85Wr5idXahLTPUF7Xox9MF8ytdvODpOn/o7lD3cOxafZR8xlN95AkfFQqqMqH/jbEJ5+Mz/uaVqEhgw==; 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-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1cdVWX-0005Kc-CJ; Tue, 14 Feb 2017 00:19:33 -0500
To: "Dale R. Worley" <worley@ariadne.com>
References: <87efz2wzoz.fsf@hobgoblin.ariadne.com>
From: Charlie Perkins <charles.perkins@earthlink.net>
Message-ID: <d59427a0-a105-9c10-9de1-86755386d43e@earthlink.net>
Date: Mon, 13 Feb 2017 21:19:27 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <87efz2wzoz.fsf@hobgoblin.ariadne.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7598ed599bdacb1532843c9b011678fe5350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/yRNxtoh-HtypzFIZgGxiaRiNosU>
Cc: gen-art@ietf.org, ietf@ietf.org, draft-ietf-dmm-4283mnids.all@ietf.org, dmm@ietf.org
Subject: Re: [DMM] Review of draft-ietf-dmm-4283mnids-04
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Feb 2017 05:19:55 -0000

Hello Dale,

Follow-up below...

On 2/12/2017 7:13 PM, Dale R. Worley wrote:
>
>> 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.
> There are a couple of reasons I like this idea.
>
> One is that EPC seems to have a policy of providing a URN form for all
> of the identifier classes it defines.  Making a single URN MNID type
> means that you've incorporated all future classes of identifier that EPC
> defines.
>
> A single URN MNID type would incorporate any of the defined URN
> namespaces that turn out to be useful for anybody.  This isn't so
> interesting for really large deployments, since they could ask for a new
> MNID type, but experimental or small-scale deployments may want to
> define their own identifiers, and URNs provide several convenient ways
> to do that.
>
> It removes a certain amount of redundancy, in that each RFID class now
> has three representations, for a total of 20 MNID types, whereas they
> could all be collapsed into one MNID type.
>
> The negatives I see are:
>
> Some URN schemes do not have a unique representation as a character
> string.  In practice, this is combated by either (1) Code that handles
> URNs of arbitrary namespace copies and compares them as character
> strings.  Users of such systems know to write URNs that have multiple
> representations in a canonical form.  Or, (2) Code that handles one or a
> small fixed set of URN namespaces knows the canonicalization/comparison
> rules for those namespaces.  Generally, using these processes doesn't
> cause problems in practice.  I expect that whatever receives the MNID
> and looks it up in appropriate databases would not be a constrained
> device, so it could process URNs carefully.
>
> If the link layer is constrained, longer identifiers may require
> fragmentation.  Changing a 96-bit binary representation into a URN seems
> to add something like 40 octets, given the examples I've found online.
> OTOH, it seems that the MNID is only transmitted when attaching to a
> network, and so having that one packet require extra work doesn't seem
> to be much of a penalty.
>
> The all-URN ides envisions embedding IMSI and possibly MSISDN into the
> gsma URN namespace.  (IMEI is already embedded as urn:gsma:imei:...)
> That would take additional specification, although I don't see that
> being controversial.  (Andrew Allen <aallen@blackberry.com> would be a
> good contact for doing this.)

I am hesitant to replace so many MNID types by a single URN type with 
substructure.  What would you think about replacing the existing 
RFID-*-URI types with a single URN type, but leaving the existing binary 
types?  This gets the benefit you suggest for future extensibility, but 
retains the shorter forms that may often be advantageous.



>>> 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?
> I'd definitely prefer some other term than "might".  I'm not sure why,
> but I think that it's because "might" isn't used much in specifications
>
> ....

I changed the text as follows:

>     Some MNIDs contain sensitive identifiers which, as used in protocols
>     specified by other SDOs, are only used for signaling during initial
>     network entry.  In such protocols, subsequent exchanges then rely on
>     a temporary identifier allocated during the initial network entry.
>     Managing the association between long-lived and temporary identifiers
>     is outside the scope of this document.


I can't remember exactly why this text was added - it was a long time 
ago.  But anyway the main point is to simply mention that there may be 
associations between some of the MNID types that might be important from 
a security standpoint, without meaning to go into examples.

Regards,
Charlie P.