Re: Review of draft-ietf-dmm-4283mnids-04

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 <[email protected]> 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.