Mobile Node Identifier Types for MIPv6
RFC 8371

Note: This ballot was opened for revision 04 and is now closed.

(Stephen Farrell) Discuss

Discuss (2017-02-15 for -04)
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.
Comment (2017-02-15 for -04)
No email
send info
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 <that> 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.

Suresh Krishnan Yes

(Jari Arkko) No Objection

Comment (2017-02-16 for -04)
No email
send info
The discussion resulting from Dale's excellent Gen-ART review probably needs to move forward before this document is ready to be made an RFC.

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) (was Discuss) No Objection

Comment (2017-08-30 for -05)
No email
send info
Thanks for resolving my DISCUSS point.

(Benoît Claise) No Objection

Alissa Cooper (was Discuss) No Objection

Comment (2018-03-19)
No email
send info
Thanks for addressing my DISCUSS.

(Spencer Dawkins) No Objection

Comment (2017-02-15 for -04)
No email
send info
I'll watch the DISCUSSions from other ADs ...

(Joel Jaeggli) No Objection

Mirja Kühlewind (was Discuss) No Objection

Comment (2017-02-16 for -04)
No email
send info
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."

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Comment (2017-02-14 for -04)
No email
send info
Thanks for the changes per the SecDir review and Mirja's discuss.
https://www.ietf.org/mail-archive/web/secdir/current/msg07164.html

Alvaro Retana No Objection