Mobile Node Identifier Types for MIPv6
draft-ietf-dmm-4283mnids-08

[Ballot discuss]
I have updated my DISCUSS position. Thanks for addressing my question about identifier types that do not uniquely identify one node.

I previously supported Stephen's DISCUSS and I don't think the issues he raised have been addressed. The argument the document gives for standardizing options for privacy-sensitive identifiers is that it "will avoid additional look-up steps." Why is this sufficient justification given the slippery slope that Stephen describes? 

In my previous ballot I was also wondering if all of these identifiers are already in common use in MIPv6 without a standard, if there is some privacy improvement that standardization could contribute. I see the new requirement for payload encryption, but nothing about, e.g., encrypting the identifiers, or limiting their transmission to the initial binding, or generating a different cryptographic identifier for each new network attachment. So the benefit of  just standardizing the options as-is still seems outweighed by the potential privacy risks as this spec is defined.

After several calls to the WG both in the mailing list and at the in person meeting there has been no response on how to classify the different IDs into essential and non-essential and also which ones to encrypt or not. Provided the WG one month to respond.

IANA Considerations question sent to authors: In Table 2, all non-assigned values are marked "reserved," but according to rfc5226bis, "Reserved" means "not available for assignment." Should the term "Unassigned" be used instead?

[Ballot comment]
Author agreed to do the following change in the security considerations section:
OLD
"If used in the MNID extension as defined in this
  document, the packet including the MNID extension should be encrypted
  so that personal information or trackable identifiers would not be
  inadvertently disclosed to passive observers."
NEW
"If used in the MNID extension as defined in this
  document, the packet including the MNID extension MUST be encrypted
  so that personal information or trackable identifiers would not be
  inadvertently disclosed to passive observers."

[Ballot discuss]
The security considerations says some of these identifiers can carry sensitive information, and when they do you should encrypt. This leaves it to the reader to decide which might be sensitive. The draft should tell the reader which ones the working group thinks are sensitive, keeping in mind that if an identifier is sometimes sensitive, it usually needs to be treated as if always sensitive. (It's hard for deployed code to figure out when it is or isn't sensitive.)

[Ballot comment]
I agree with Stephen's, Alissa's, and Mirja's discusses. I especially agree that we should not standardize new identifiers without justifying each one.

Section 5 says this document does not impact existing security mechanisms. But it does add new data elements, and acknowledges some of them may be sensitive. Thus I think the "does not impact" assertion needs some supporting discussion. Are the existing mechanisms still adequate? Why?

There are a bunch of acronyms that would benefit from expansion on first mention.

[Ballot discuss]
I support Stephen's DISCUSS. I'm also wondering, if all of these identifiers are already in common use in MIPv6 without a standard, if there is some privacy improvement that standardization could contribute (e.g., encrypting the identifiers, or requiring transport encryption, or limiting their transmission to the initial binding, or ... other ideas the community may come up with). The benefit of  just standardizing the options as-is seems outweighed by the potential privacy risks as this spec is defined.

I'm also confused about the identifier types that do not uniquely identify one node, since I thought that was the point of these options. How are they meant to be used in MIPv6? Would you have multiple mobile node identity options in a single packet that, together, uniquely identify a node? I think this requires some elaboration in the text.

[Ballot discuss]

I don't consider that merely mentioning that there are some
privacy issues (maybe) is nearly sufficient here.  Instead I
would argue that any of these identifier types that could have
privacy implications need to be specifically justified or else
dropped. By specifically justified, I mean that there ought be
an argument (and a fairly holistic one) that the Internet is
better, and not worse, if we define a codepoint that allows
MIPv6 (and later, other protocols) to use that identifier.  I
do accept that my position is perhaps innovative, in terms of
IETF processes, so I'll split the discuss into two parts, one
process oriented and mostly for the IESG, and the second
relating to the content of the draft.

(1) For the IESG: is it ok that we introduce (codepoints for)
a slew of new long-term stable privacy-sensitive identifiers
just because they might someday be needed, or do we need to
have specific justification for defining such things? I would
argue the latter, but that may need us to validate that there
is IETF consensus for that somehow, and perhaps in the
meantime hold on to this draft. Part of my reasoning is that
once we define such codepoints (e.g. for IMSIs) then that
inevitably means that other protocols, and not just MIPv6,
will do the same eventually, so accepting this draft basically
means accepting that we end up commonly and perhaps
carelessly, passing such highly-sensitive information about on
the Internet in many protocols and in many contexts.  My
argument here I think does adhere to various of our BCPs that
do argue for security and privacy, but I do also accept that
this may be novel and to some extent goes against another of
our generally accepted ideas which is that we benefit from
folks documenting things even if those things are sub-optimal
in various ways. So I'd argue this is a real case for an IESG
discussion - I know what I think, but what do the rest of you
think?

(2) For the authors: to the extent you are willing to, and
want to get ahead of the discussion on point (1) above, can
you in fact provide an argument, for each of the identifiers
here that have privacy-sensitivity, that the Internet is better
overall if we define these codepoints knowing that if we do
define a way to represent e.g. an IMSI in MIPv6 that is likely
to be copied elsewhere? Note for the authors: I think it's
entirely fine for you to do nothing pending the discussion of
point (1) above, if that's your preference.

[Ballot comment]

While I'm entirely sympathetic to Mirja's discuss point, I
don't think that a statement here can really constrain how
these identifiers, once they are defined, are used in other
protocols. While there is a chance that some IESG sometime
might say "hold on, RFCxxxx (this doc) says you SHOULD encrypt
if  identifier is used" the chances that a future IESG
notice this isn't that high, but it's also even more likely
that the designers of future protocols will successfully argue
that since not all identifiers are privacy sensitive, their
specific protocol need not adhere to the SHOULD. In the end, I
think that should or SHOULD will be ineffective.

[Ballot discuss]
I would realy like to see the following changes in the security considerations section:
OLD
"If used in the MNID extension as defined in this
  document, the packet including the MNID extension should be encrypted
  so that personal information or trackable identifiers would not be
  inadvertently disclosed to passive observers."
NEW
"If used in the MNID extension as defined in this
  document, the packet including the MNID extension SHOULD be encrypted
  so that personal information or trackable identifiers would not be
  inadvertently disclosed to passive observers."
Or even better make it a MUST? Is there a reason for only having a SHOULD?

as well as the following change:
OLD
"Moreover, MNIDs containing sensitive identifiers might only be used
  for signaling during initial network entry. "
NEW
"Moreover, MNIDs containing sensitive identifiers MUST only be used
  for signaling during initial network entry and MUST NOT be leaked to
  other networks."

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-dmm-4283mnids-04.txt. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Mobile Node Identifier Option Subtypes subregistry of the Mobile IPv6 parameters registry located at:

https://www.iana.org/assignments/mobility-parameters/

a set of new subtypes will be registered as follows:

+-----------------+------------------------+---------------+
| Identifier Type | Identifier Type Number | Reference |
+-----------------+------------------------+---------------+
| IPv6 Address | 2 | [ RFC-to-be ] |
| IMSI | 3 | [ RFC-to-be ] |
| P-TMSI | 4 | [ RFC-to-be ] |
| EUI-48 address | 5 | [ RFC-to-be ] |
| EUI-64 address | 6 | [ RFC-to-be ] |
| GUTI | 7 | [ RFC-to-be ] |
| DUID-LLT | 8 | [ RFC-to-be ] |
| DUID-EN | 9 | [ RFC-to-be ] |
| DUID-LL | 10 | [ RFC-to-be ] |
| DUID-UUID | 11 | [ RFC-to-be ] |
| | 12-15 reserved | [ RFC-to-be ] |
| | 16 reserved | [ RFC-to-be ] |
| RFID-SGTIN-64 | 17 | [ RFC-to-be ] |
| RFID-SSCC-64 | 18 | [ RFC-to-be ] |
| RFID-SGLN-64 | 19 | [ RFC-to-be ] |
| RFID-GRAI-64 | 20 | [ RFC-to-be ] |
| RFID-DOD-64 | 21 | [ RFC-to-be ] |
| RFID-GIAI-64 | 22 | [ RFC-to-be ] |
| | 23 reserved | [ RFC-to-be ] |
| RFID-GID-96 | 24 | [ RFC-to-be ] |
| RFID-SGTIN-96 | 25 | [ RFC-to-be ] |
| RFID-SSCC-96 | 26 | [ RFC-to-be ] |
| RFID-SGLN-96 | 27 | [ RFC-to-be ] |
| RFID-GRAI-96 | 28 | [ RFC-to-be ] |
| RFID-DOD-96 | 29 | [ RFC-to-be ] |
| RFID-GIAI-96 | 30 | [ RFC-to-be ] |
| | 31 reserved | [ RFC-to-be ] |
| RFID-GID-URI | 32 | [ RFC-to-be ] |
| RFID-SGTIN-URI | 33 | [ RFC-to-be ] |
| RFID-SSCC-URI | 34 | [ RFC-to-be ] |
| RFID-SGLN-URI | 35 | [ RFC-to-be ] |
| RFID-GRAI-URI | 36 | [ RFC-to-be ] |
| RFID-DOD-URI | 37 | [ RFC-to-be ] |
| RFID-GIAI-URI | 38 | [ RFC-to-be ] |
| | 39-255 reserved | [ RFC-to-be ] |
+-----------------+------------------------+---------------+

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: suresh.krishnan@ericsson.com, max.ldp@alibaba-inc.com, draft-ietf-dmm-4283mnids@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org, "Dapeng Liu"
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (MN Identifier Types for RFC 4283 Mobile Node Identifier Option) to Proposed Standard


The IESG has received a request from the Distributed Mobility Management
WG (dmm) to consider the following document:
- 'MN Identifier Types for RFC 4283 Mobile Node Identifier Option'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-02-07. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


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




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The type of RFC being requested is Standards Track. The reason
is that this document is an extension of RFC 4238 which is a
Standard Track RFC.

The type of RFC is indicated in the title page header of the current
version of the draft.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  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.  This document proposes
  adding some basic types that are defined in various telecommunications
  standards, including types for IMSI, P-TMSI, IMEI, and GUTI.
  Also includes identifiers that are tied to the physical elements of the
  device (RFID, MAC address etc.)

Working Group Summary

    There is consensus in the WG to publish these documents.


Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?


  This document has been reviewed by some Mobile IP experts in
  the DMM working group and the WG thinks this extension is useful
  for deployment.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

  The document Shepherd is WG co-chair Dapeng Liu. The Responsible
  Area Director is Suresh Krishnan.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.


This document is the extension of RFC4283 and proposes to define more
types of identifiers as the Mobile Node Identifier. It does not have
other technical changes of RFC4283. The proposed new mobile node
identifiers includes IMSI, P-TMSI, IMEI, GUTI, RFID, MAC and IPv6 address etc.
This version of the document is ready for publication.



(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

This document has been discussed in the working group many times and
has been reviewed by several Mobile IP experts.



(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

This document does not need review from a particular or from broader
perspective since it does not define mechanism related to security,
operational complexity, AAA, DNS, DHCP, XML, internationalization etc.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

N/A

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

This document belongs to the maintenance work of Mobile IP in the charter
of DMM working group. There is a clear consensus for the publication of
this document from those who are working on Mobile IP and there is no
objections in the working group.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.


ID nits check result:
    Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 2 comments (--).



(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

This document does not define any MIB, media type, URI etc.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

Yes. This document will update RFC4283. RFC4283 is listed on the title
page, abstract and discussed in the introduction.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The new mobile node identifier types defined in the document should be
assigned values from the "Mobile Node Identifier Option Subtypes" registry.
(http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml#mobility-parameters-5)
Currently, only value 1 is used for Mobile Node Identifier Option Subtypes.
The IANA considerations section is consistent with the body of the document.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A

Folks,

This mail starts a two week WGLC #2 for the I-D
draft-ietf-dmm-4283mnids-01. The WGLC ends 16th September 2015 EOB Pacific
time.

Please, review the document and indicate your support or concerns on the
mailing list. If you have concerns or comments that you want to be
reflected in the draft text issue a ticket into the issue tracker as
well. We urge you to utilize the issue tracker for comments that you
want to be resolved.

- Dapeng and Jouni