Subject: [DMM] FW: Stephen Farrell's Discuss on draft-ietf-dmm-4283mnids-04: (with DISCUSS and COMMENT)

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 5 Apr 2017 15:23:03 +0000

Hi Charlie,

Please let the WG know how you plan to resolve this DISCUSS. Will be great if you can post your proposed changes to the group.

WG - Please provide your feedback and way-forward in this issue, by COB 19th of April.

Regards
Sri

From: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Date: Friday, March 24, 2017 at 10:30 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Hakima Chaouchi <[email-masked]<mailto:[email-masked]>>, Suresh Krishnan <[email-masked]<mailto:[email-masked]>>, Charlie Perkins <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] Stephen Farrell's Discuss on draft-ietf-dmm-4283mnids-04: (with DISCUSS and COMMENT)

Folks,

Please provide feedback on the following thread.

Request for MN-Id based on other access technology specific identifiers was initially triggered by Hakima Chaouchi; May be Hakima and others can comment on this.

Sri

From: Suresh Krishnan <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 13, 2017 at 8:14 PM
To: Charlie Perkins <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] Stephen Farrell's Discuss on draft-ietf-dmm-4283mnids-04: (with DISCUSS and COMMENT)
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Resent-Date: Mon, 13 Mar 2017 21:14:56 -0700

Hi all,

On Feb 28, 2017, at 4:32 PM, Charlie Perkins <[email-masked]<mailto:[email-masked]>> wrote:

Hello folks,

It has been suggested that the dmm WG members should to provide more support for the inclusion of the MNIDs that are listed in draft-ietf-dmm-4283mnids-04.

In order to resolve this issue, please send discussion to the [dmm] mailing list with thoughts about which of the types proposed in the draft are likely to require considerations about privacy when used in the Mobile Node Identifier option.  Also, for the proposed types, it has been requested to make some discussion about how their inclusion will help to improve the Internet.

This is a reminder to provide your inputs regarding the MNID types as Charlie has requested.

Thanks
Suresh

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 5 Apr 2017 16:37:52 +0100

On 05/04/17 16:30, Hakima Chaouchi wrote:
> Hi there,
> 
> Sorry for catching up the discussion late.

You're so late that I'm no longer on the IESG and hence
Suresh will I guess handle this now ex-DISCUSS:-)

Note though there were other discusses on the draft so
my leaving the IESG does not by itself unblock this.

So I'll leave it to Suresh to figure our the right next
steps. I'm happy to chat more about it then if that's
useful

Cheers,
S.

> 
> If I understood well the discussion; the question here is about 1) how
> those identifiers might violate the user privacy?  2) Is internet getting
> better by including those identifiers?
> 
> I will not discuss the case of IMSI for mobile cellular devices, but in the
> case of RFID I believe:
> 1) regarding point 1 related to privacy, in fact if a device with an RFID
> tag for instance a bank card has to send in clear its numbers as a MNID in
> a packet then of course there is an issue, but I believe that matching the
> MNID with the IP adress will be also secured inside the packet , first the
> identifiers has to be well defined and structured , then work on the
> protocol packet secure exchange of those identifiers.
> 
> 2) regarding point 2, we need to remind that Internet to be part of the
> game of Internet of Things trafic exchange then it has to consider all
> types of communicating devices, knowing that we are talking on the near
> future of billions of sensors, actuators, RFID tags talking, then Internet
> protocols will take care of that and having IDs coressponding to all these
> types is the way to go to better manage for instance the mobility of those
> devices as using the device ID as a non changing reference information, and
> changing the adresses while on move. Other protocols might benefit from
> this ID information such as service discovery or end to end signaling. I
> believe the IETF worked years ago on separating the identifier (locator)
> and the address, this was meant to help the fast mobility management but
> also securing the sender and reciever mutual authentication with trusted
> identifiers. May be  we should think about how to build a secure identifier
> of each node which will be built upon the original identifier (eg IMSI,
> RFID, ...etc) and another type of secure information. In that case privacy
> will be saved as the original identifier is not sent in clear? and more
> functionalities would be introduced using those identifiers. what do you
> think?
> 
> Regards,
> Hakima
> 
> 
> 
> 
> *---------------------------------------------*
> Hakima Chaouchi
> Professor
> Institut Mines Telecom
> Research Group: Emerging Networks and Services toward Internet of Things
> EU AIOTI Alliance member
> eMBA Leading innovation in the Digital World
> 
> 2017-02-16 2:27 GMT+01:00 Stephen Farrell <[email-masked]>:
> 
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-dmm-4283mnids-04: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/
>>
>>
>>
>> ----------------------------------------------------------------------
>> 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.
>>
>>
>> ----------------------------------------------------------------------
>> 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 <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.
>>
>>
>> _______________________________________________
>> dmm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dmm
>>
>