Hello Sri,
Thanks for that terrific review. Please see my follow-up below and
request for
additional discussion.
On 10/11/2015 6:16 PM, Sri Gundavelli (sgundave) wrote:
1. Introduction
The Mobile Node Identifier Option for MIPv6 [RFC4283] has proved to
be a popular design tool for providing identifiers for mobile nodes
during authentication procedures with AAA protocols such as Diameter
[RFC3588]. To date, only a single type of identifier has been
specified, namely the MN NAI. Other types of identifiers are in
common use, and even referenced in RFC 4283.
*[Sri] Some text on the motivation for defining new Types may be
helpful. Document is not just standardizing the currently
in-use/popular identifier types, its also introducing new types are
not in use. The reasons/interest for defining identifiers that are
tied to the physical elements of the device (RFID, MAC address ..etc)
and how it helps in deployment of the technology may be useful. Few
lines of text will really help.*
Here is the paragraph with some new text:
In this document, we
propose adding some basic types that are commonly in use in various
telecommunications standards, including the IMSI, P-TMSI, IMEI, GUTI,
and IEEE MAC-layer addresses. In addition, we include the IPv6
address itself as a legitimate mobile node identifier.
Defining identifiers that are tied to the physical elements of the
device (RFID, MAC address etc.) help in deployment of Mobile IP
because in many cases such identifiers are the most natural means
for uniquely identifying the device, and will avoid additional
look-up steps that might be needed if other identifiers were used.
including the IMSI, P-TMSI, IMEI, GUTI,
and IEEE MAC-layer addresses. In addition, we include the IPv6
address itself as a legitimate mobile node identifier.
*[Sri] References for IMSI, P-TMSI, IMEI, GUTI; May be 3GPP TS 23.003.*
Will do.
2. New Mobile Node Identifier Types
The following types of identifiers are commonly used to identify
mobile nodes. For each type, references are provided with full
details on the format of the type of identifer.
EPC supports several encoding systems or schemes including
*[Sri] EPC? EPC Tag Standards I assume, not the Evolved Packet Core.
Reference to [EPC-Tag-Data] will help *
Will do.
o RFID-GID (Global Identifier),
o RFID-SGTIN (Serialized Global Trade Item Number),
.......... /many lines deleted/ ..............
o RFID-DOD-URI [RFID-DoD-96]
o RFID-GIAI-URI [EPC-Tag-Data]
o 39-255 reserved
*[Sri] This is a major issue. > I was hoping to see a sub-section for
each of the types. We cannot > standardize a identifier type without
providing any explanation on the > identifier type or the references
to the base definitions. This can > be painful, but I'd have a small
section for each of the types. It can > be 3 line text on the a.)
Definition b.) Format c.) Example format d.) > Reference to the base
spec that defines those identifiers.*
This might be dangerous, because it would be a partial respecification for
for identifiers outside the general expertise of this group. But I will
try to think of something. Contributed text will be very much appreciated.
3. Security Considerations
This document does not introduce any security mechanisms, and does
not have any impact on existing security mechanisms. Insofar as the
selection of a security association may be dependent on the exact
form of a mobile node identifier, additional specification may be
necessary when the new identifier types are employed with the general
AAA mechanisms for mobile node authorizations.
Some identifiers (e.g., IMSI) are considered to be private
information. If used in the MNID extension as defined in this
document, the packet including the MNID extension should be encrypted
*[Sri] Besides the use of IMSI, the document also defines the use of
other sensitive identifiers such as IPv6..*
Do you think that IPv6 addresses are more sensitive than IPv4 addresses?
*Mention of the available tools for privacy protection may be helpful.
Some thing along these lines, or better text:*
*"This information is considered to be very sensitive, so care must be
taken to secure the Mobile IPv6/Proxy Mobile IPv6 signaling messages
when carrying this sub-option. The base Proxy Mobile IPv6
specification [RFC5213] specifies the use of IPsec for securing the
signaling messages, and those mechanisms can be enabled for protecting
this information. Operators can potentially apply IPsec Encapsulating
Security Payload (ESP) with confidentiality and integrity protection
for protecting the location information."*
**
I am O.K. with that text. However, the same considerations apply to
RFC 4283, so that the initial paragraph is still sort-of correct. Should
I make a statement that our understanding of various vulnerabilities
has led to the desire for better security surrounding identification
features?
so that personal information or trackable identifiers would not be
inadvertently disclosed to passive observers. Moreover, MNIDs
containing sensitive identifiers might only be used for signaling
during initial network entry. Subsequent binding update exchanges
would then rely on a temporary identifier allocated during the
initial network entry.
*[Sri] The MAG/MN can certainly obtain an temporary identifier as part
of he access authentication and can use the same in the signaling.
But, I'M unaware of any spec where the MN identifier changes between
initial and subsequent binding updates. Clarification may behelp*
I put in some clarifying text:
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.
4.
New Mobile Node Identifier Types
+-----------------+------------------------+
| Identifier Type | Identifier Type Number |
+-----------------+------------------------+
| IPv6 Address | 2 |
.......... /many lines deleted/ ..............
| RFID-GIAI-URI | 38 |
| | 39-255 reserved |
+-----------------+------------------------+
Table 1
See Section 2 for details about the identifer types.
*[Sri] But, Section 2 has no text on the above types.*
Point noted, although there is a little bit of explanatory text.
Section 2 does have citations. How about:
See Section 2 for additional information about the identifier types.
Plus, if more text is required about the types, then section 2 would
indeed have details.
Vijay Devarapalli
Vasona Networks
2900 Lakeside Drive, Suite 180
Santa Clara, CA 95054
USA
*[Sri] Vijay ? Who is that ? References to people from ancient history
and who are currently dormant can be silently omitted :) *
Well, I asked Vijay if he wanted to remain as co-author and he told me
he did want to remain.
Regards,
Charlie P.
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
