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(_at_)blackberry(_dot_)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.