Charlie Perkins <charles(_dot_)perkins(_at_)earthlink(_dot_)net> writes:
Are there any other types "in common use"?
I will add some text according to your suggestion. My criterion for
whether the identifier type was included in the document was whether or
not anyone had asked for it to be included.
A good criterion -- if it's commonly used, likely someone would have
asked.
- 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
It is not the jurisdiction of the MNIDs document to specify these
identifiers, but citations for the specifications are located elsewhere
in the document. I will also include those citations here.
What I was noting was that 4283 says:
Mobile IPv6
nodes need the capability to identify themselves using an identity
other than the default home IP address. Some examples of identifiers
include Network Access Identifier (NAI), Fully Qualified Domain Name
(FQDN), International Mobile Station Identifier (IMSI), and Mobile
Subscriber Number (MSISDN).
but that taking 4283 and this document together, there is no way to
specify FQDN or MSISDN as MN identifiers. If in practice, people don't
use either of those, then the situation is OK, though 4283 is
inaccurate. But if people do use FQDNs or MSISDNs as MN identifiers,
should those be added to this document? (I can't find them specified
elsewhere.)
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.
I don't know why this happened, but I am happy to include an identifier
type for IMEI as well as a citation for it. Thanks for catching this
and looking through the archives!
I'm not saying, "Add it because I think it's a good idea to use IMEIs.",
I'm saying, "Your introduction says that you define an MNID type for
IMEIs, but you don't." Perhaps there is no need for IMEIs, but in that
case, the introduction needs to be edited.
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
Actually, I am O.K. either way on this matter. However, at this point
in time it does not seem that we are likely to see any other link
hardware address types to be used as MNIDs.
I agree with you there, although I wouldn't be entirely surprised if a
new mobile network introduced a new link-layer address. But there
doesn't seem to be much value in making the change I suggested, other
than for generality.
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.)
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.
I am O.K. with this. I need to go find out where I got that language
from, because I don't think I was the person who crafted it.
I suspect this is really an editorial mistake, but I had to treat it as
technical because I couldn't rule out that it was a design question.
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.
Thanks for this observation. I will make the corresponding revisions to
the text.
Give that there has been only 4 types of DUID defined in 13 years, I
don't expect much need for extensibility, but it seems to me that if
devices take their MNID from their platform's DHCP implementation,
there is a risk that the protocol will fail if someone uses a
proprietary/experimental DUID type.
Editorial issues:
Trimming everything I have no further comment on:
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)!
O.K. with your modification. The document just defines numbers for the
types, not the types.
True... So really "Additional Identifier Type Numbers are defined for
use ..."
--
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.
This is a good idea. How about the following:
For each RFID scheme except GID, there are three representations:
- a 64-bit binary representation (for example, SGLN-64)
- a 96-bit binary representation (SGLN-96).
- a representation as a URI
That's close, but it doesn't assert the representations for GID.
Better:
For each RFID there are three representations:
- a 64-bit binary representation (for example, SGLN-64)
(except for GID)
- a 96-bit binary representation (SGLN-96).
- a representation as a URI (a URN, actually)
(Though all of this discussion can be removed of the binary
representations are removed in favor of the URN representation.)
I didn't originate the use of URI for the non-binary representation. The
EPC document has the following language:
All categories of URIs are represented as Uniform Reference Names
(URNs) as defined by [RFC2141], where the URN Namespace is epc.
If I were to change it to URN, then I would have to go into some detail
about why this document somehow disagrees with the EPC-Tag-Data
document. Do you think that is necessary?
We do want to stay aligned with EPC, otherwise there would be chaos.
And technically, all URNs are URIs. But approaching the subject from
the IETF, it makes a lot more sense that RFID schemes are represented as
URNs rather than general URIs. It seems to me to be quite sufficient to
notify the reader in some appropriate place that these URIs are URNs.
See the last line of the text I suggested above for one way to do it.
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.
I read through some relevant text in the EPC-Tag-Data document and it
seems O.K. to me, but nontrivial and it relies on digging through other
even more arcane documents to be absolutely sure. I am pretty sure that
the IETF document should not get into the business of augmenting the
standards already in place from the external SDOs.
Oh, yes, we don't want to duplicate EPC's work. I just wanted to know
that you've checked that EPC does define a sequence of octets, rather
than only a sequence of *bits*, which would leave the ordering of the
bits within the octets unspecified.
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.
I hope that this document does not have to specify allocation procedures
for the MNIDs. It seems to me that if a system designer wants to use
one of the MNID types, that person will already know about how to
request the allocation and would not need to rely on the MNIDs document
for that information. Plus it's really out of scope. This document was
always intended to be a simple tabulation of types already in use
elsewhere and enabling IETF mobility management protocols to use the
most natural identifier available for a mobile node. I hope that citing
the defining documents for the identifier types will be enough to
satisfy that.
OK, I can agree with you there. The only identifier which doesn't seem
to have a "natural" ownership scheme is IPv6 addresses; I think of IPv6
addressed as being assigned to a device every time it is initialized,
rather than being a way to identify the device. But you address that in
the item below.
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.
As far as I have understood, the unicast IPv6 address in use as a MNID
is already assigned to the device. I have not heard anyone asking for
this to be an address for future assignment. I'll try to make that
clear in the text.
OK, if that's the case, then the usage is clear, as is how the device
obtains ownership of an address.
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.
I probably lifted that language directly from the IMSI spec, but I can
make further clarification according to your suggestion.
It's likely that in the context of the IMSI spec that "network order"
means high-to-low for all sizes quantities, but I've not seen that used
in IETF context, so it's probably worth clarifying just to be thorough.
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.
Here I am at a loss, because I was specifically requested to insert some
descriptive but not normative text. I will ask the person who made the
request to provide their feedback on the mailing list. For myself, I am
more than happy to delete the text.
OK, if people have asked for descriptions, I can see the value in that.
But you might want to check that your phrasing makes sense to someone
who isn't already familiar with the EPC schemes.
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
If the external documents show how MNIDs will be used, and if that
context shows why the security problems are small, then I'd definitely
reference them.
One point that is not clear to me. The above quoted paragraph suggests
that MNIDs are only transmitted during initial network entry. But
reading it again, I'm led to guess that they are currently also used for
"binding update exchanges". And you are suggesting that their use in
binding update exchanges could be eliminated by using temporary
identifiers?
If the first case is true, you can make the statement more definitive
as simply:
Currently, MNIDs are only be used for signaling during initial
network entry. [external reference]
If the second case is true, you want to make it clearer that the current
risks are (slightly) higher:
Currently, MNIDs are only be used for signaling during initial
network entry and binding update exchanges. [external reference]
Future work could ensure that MNIDs are only be used for signaling
during initial network entry by having subsequent binding update
exchanges rely on a temporary identifier allocated during the
initial network entry, perhaps using mechanisms not standardized
within the IETF. [perhaps delete that last phrase as not really
adding anything?] Managing the association between long-lived and
temporary identifiers is outside the scope of this document.
Dale