Subject: [DMM] Review comments on draft-ietf-dmm-4283mnids-00.txt

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 12 Oct 2015 01:16:52 +0000

Hi Charlie,

Please see inline for my review comments.

Regards
Sri

Distributed Mobility Management [dmm]                         C. Perkins
Internet-Draft                                                 Futurewei
Expires: October 24, 2015                                 V. Devarapalli
                                                         Vasona Networks
                                                          April 22, 2015

     MN Identifier Types for RFC 4283 Mobile Node Identifier Option
                    draft-ietf-dmm-4283mnids-00.txt

Abstract

   Additional Identifier Types are proposed for use with the Mobile Node
   Identifier Option for MIPv6 (RFC 4283).

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 24, 2015.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Perkins & Devarapalli   Expires October 24, 2015                [Page 1]

Internet-Draft      MN Identifier Types for RFC 4283          April 2015

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  New Mobile Node Identifier Types  . . . . . . . . . . . . . .   2
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

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.

 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.

[Sri] References for IMSI, P-TMSI, IMEI, GUTI; May be 3GPP TS 23.003.

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

o RFID-GID (Global Identifier), o RFID-SGTIN (Serialized Global Trade Item Number), o RFID-SSCC (Serial Shipping Container), o RFID-GLN (Global Location Number), o RFID-GRAI (Global Returnable Asset Identifier), o RFID-DOD (Department of Defense) and o RFID-GIAI (Global Individual Asset Identifier). For each RFID scheme except GID, there are two variations: a 64-bit scheme (for example, GLN-64) and a 96-bit scheme (GLN-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 following list includes the above RFID types as well as various other common identifiers and several different types of DUIDs. Perkins & Devarapalli Expires October 24, 2015 [Page 2] Internet-Draft MN Identifier Types for RFC 4283 April 2015 o IPv6 Address [RFC2373] o IMSI [ThreeGPP-IDS] o P-TMSI [ThreeGPP-IDS] o GUTI [ThreeGPP-IDS] o EUI-48 address [IEEE802] o EUI-64 address [IEEE802] o DUID-LLT [RFC3315] o DUID-EN [RFC3315] o DUID-LL [RFC3315] o DUID-UUID [RFC6355] o 12-15 reserved o 16 reserved o RFID-SGTIN-64 [EPC-Tag-Data] o RFID-SSCC-64 [EPC-Tag-Data] o RFID-GLN-64 [EPC-Tag-Data] o RFID-GRAI-64 [EPC-Tag-Data] o RFID-DOD-64 [RFID-DoD-96] o RFID-GIAI-64 [EPC-Tag-Data] o 23 reserved o RFID-GID-96 [EPC-Tag-Data] o RFID-SGTIN-96 [EPC-Tag-Data] o RFID-SSCC-96 [EPC-Tag-Data] o RFID-GLN-96 [EPC-Tag-Data] o RFID-GRAI-96 [EPC-Tag-Data] o RFID-DOD-96 [RFID-DoD-96] o RFID-GIAI-96 [EPC-Tag-Data] o 31 reserved o RFID-GID-URI [EPC-Tag-Data] o RFID-SGTIN-URI [EPC-Tag-Data] o RFID-SSCC-URI [EPC-Tag-Data] o RFID-GLN-URI [EPC-Tag-Data] o RFID-GRAI-URI [EPC-Tag-Data] 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.

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.

   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. "

Perkins & Devarapalli Expires October 24, 2015 [Page 3] Internet-Draft MN Identifier Types for RFC 4283 April 2015 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

4.  IANA Considerations

   The new mobile node identifier types defined in the document should
   be assigned values from the "Mobile Node Identifier Option Subtypes"
   registry.  The following values should be assigned.

Perkins & Devarapalli   Expires October 24, 2015                [Page 4]

                     New Mobile Node Identifier Types

               +-----------------+------------------------+
               | Identifier Type | Identifier Type Number |
               +-----------------+------------------------+
               | IPv6 Address    | 2                      |
               | IMSI            | 3                      |
               | P-TMSI          | 4                      |
               | EUI-48 address  | 5                      |
               | EUI-64 address  | 6                      |
               | GUTI            | 7                      |
               | DUID-LLT        | 8                      |
               | DUID-EN         | 9                      |
               | DUID-LL         | 10                     |
               | DUID-UUID       | 11                     |
               |                 | 12-15 reserved         |
               |                 | 16 reserved            |
               | RFID-SGTIN-64   | 17                     |
               | RFID-SSCC-64    | 18                     |
               | RFID-GLN-64     | 19                     |
               | RFID-GRAI-64    | 20                     |
               | RFID-DOD-64     | 21                     |
               | RFID-GIAI-64    | 22                     |
               |                 | 23 reserved            |
               | RFID-GID-96     | 24                     |
               | RFID-SGTIN-96   | 25                     |
               | RFID-SSCC-96    | 26                     |
               | RFID-GLN-96     | 27                     |
               | RFID-GRAI-96    | 28                     |
               | RFID-DOD-96     | 29                     |
               | RFID-GIAI-96    | 30                     |
               |                 | 31 reserved            |
               | RFID-GID-URI    | 32                     |
               | RFID-SGTIN-URI  | 33                     |
               | RFID-SSCC-URI   | 34                     |
               | RFID-GLN-URI    | 35                     |
               | RFID-GRAI-URI   | 36                     |
               | RFID-DOD-URI    | 37                     |
               | 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.

Perkins & Devarapalli Expires October 24, 2015 [Page 5] Internet-Draft MN Identifier Types for RFC 4283 April 2015 5. References 5.1. Normative References [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005. [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005. [RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Authentication Protocol for Mobile IPv6", RFC 4285, January 2006. [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, August 2011. 5.2. Informative References [EPC-Tag-Data] EPCglobal Inc., , "EPC(TM) Generation 1 Tag Data Standards Version 1.1 Rev.1.27 http://www.gs1.org/gsmp/kc/epcglobal/tds/ tds_1_1_rev_1_27-standard-20050510.pdf", January 2005. [IEEE802] IEEE, , "IEEE Std 802: IEEE Standards for Local and Metropolitan Networks: Overview and Architecture", 2001. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFID-DoD-96] Department of Defense, , "United States Department of Defense Suppliers Passive RFID Information Guide (Version 15.0)", January 2010. Perkins & Devarapalli Expires October 24, 2015 [Page 6] Internet-Draft MN Identifier Types for RFC 4283 April 2015 [ThreeGPP-IDS] 3rd Generation Partnership Project, , "3GPP Technical Specification 23.003 V8.4.0: Technical Specification Group Core Network and Terminals; Numbering, addressing and identification (Release 8)", March 2009. Authors' Addresses Charles E. Perkins Futurewei Inc. 2330 Central Expressway Santa Clara, CA 95050 USA Phone: +1-408-330-4586 Email: [email-masked]<mailto:[email-masked]> 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 :)

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 12 Oct 2015 16:55:10 -0700

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:
> *[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,
> *[Sri] References for IMSI, P-TMSI, IMEI, GUTI; May be 3GPP TS 23.003.*

Will do.

> *[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.

> *[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.

              .......... /many lines deleted/ ..............

> *[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.

---

From: jouni korhonen <[email-masked]>
Date: Wed, 21 Oct 2015 14:11:54 -0700

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-masked]> wrote:

> *[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.*
>
>
> o RFID-GID (Global Identifier), o RFID-SGTIN (Serialized Global Trade Item
> Number),
>
>              .......... *many lines deleted* ..............
>
> *[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.*
>
>
> *[Sri] Besides the use of IMSI, the document also defines the use of other
>       sensitive identifiers such as IPv6..*
>
>
> *    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
>    when carrying this sub-option.
>
>    information."*
>       initial and subsequent binding updates. Clarification may be help*
>
>
>              .......... *many lines deleted* ..............
>
>                | RFID-GIAI-URI   | 38                     |
>                |                 | 39-255 reserved        |
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>
>