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.
- [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: [DMM] Review of draft-ietf-dmm-4283mnids-04 Charlie Perkins
- Re: [DMM] Review of draft-ietf-dmm-4283mnids-04 Sri Gundavelli (sgundave)
- Re: [DMM] 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: [DMM] [Gen-art] Review of draft-ietf-dmm-4283… Jari Arkko