Has all concerns been addresses in -01? Myself, I did not find complete proposal for the one below and agree with Sri that such detail would be useful.
- Jouni *[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.* On Mon, Oct 12, 2015 at 4:55 PM, Charlie Perkins < [email protected]> wrote: > 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 be help* > > > 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 > >
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
