Re: [hiaps] some discussion in the press...

[<[e-mail]>]

Dear all,
Regarding the potential differently interpretable postings on this list IMHO the job of the ML should be to enable discussion on issues with new and existing identities (which might also include service or session IDs beside host IDs IMO).
 
Main aspects are of course usefulness in enabling (new) services and improving service performance via (new) networks - but a topic of adequate importance is how to prevent their mis-use in terms of increased security threats, attack probability and frequency, decreased privacy and so on - as is subject of the links within the original thread.

Personally I think that with increased heterogeneity of networks, devices, services, application scenarios etc. the demand for differentiation (and therefore potential new flags, options, identities etc.) will grow to grant fulfilment of (user and operator) expectations towards next generation communication (also dubbed as beyond 4G). 

Therefore we should keep on discussing identity issues - e.g. here ... ;-)

Whether this would result in a call for a new/revived BoF seems to me to be another question to be raised only after the well-known criteria are fulfilled (see e.g. rfc5434) and we should not have such a pressure for the current discussions ... 

just my 2 Cents - if you disagree please speak up 

Thanks!
Best regards
Dirk

-----Original Message-----
From: hiaps [mailto:[e-mail]] On Behalf Of Behcet Sarikaya
Sent: Montag, 3. November 2014 16:32
To: joel jaeggli
Cc: [e-mail]; Mohamed Boucadair; Brandon Williams
Subject: Re: [hiaps] some discussion in the press...

On Sun, Nov 2, 2014 at 2:34 PM, joel jaeggli <[e-mail]> wrote:
> On 10/31/14 9:03 AM, [e-mail] wrote:
>> Hi Behcet,
>>
>> I'm still supportive of this work and actually I'd like to see some 
>> concrete progress. Saying that, I'm not sure Joel is asking for 
>> another BoF but perhaps I'm wrong here.
>
> I'm not.  somebody should reread the thread if they believe that.

Understood.

The point is hiaps list has been around for some time. I think that Joel was indicating that maybe it should be decided whether to close this list or to continue the discussions. If the latter is chosen, that is something that would lead to going to another BoF, or whatever is decided as the next step.

Joel, is this correct?

We need to clarify this as a number of people may jump in as a result.

Regards,

Behcet


>
>> Just like the "panic" with pervasive monitoring, there are several 
>> mailing lists that are alarmed with injection of the identifiers.
>> These practices are not new but these are "panic" cycles... The side 
>> effect of it is that these alarming news can pollute the HOST_ID work 
>> despite the fact that we are not asking for unique/stable identifiers 
>> nor asking to leak/reveal any customer ID, profile ID, etc.
>>
>> BTW, there IETF documents that already documents some practices of 
>> injecting identifiers, see for instance:
>> http://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-01#sectio
>> n-3.3 that is more close to what Joel shared in this list.
>>
>> Cheers, Med
>>
>> -----Message d'origine----- De : Behcet Sarikaya 
>> [mailto:[e-mail]] Envoyé : jeudi 30 octobre 2014 20:04 
>> À : joel jaeggli Cc : [e-mail]; BOUCADAIR Mohamed IMT/OLN; 
>> Brandon Williams Objet : Re: [hiaps] some discussion in the press...
>>
>> Hi Med, Brandon,
>>
>> Last time Med was on paternity leave and he could help. Brandon found 
>> out about hiaps late.
>>
>> Now, it is time for you two to say something regarding
>>
>>> a bof proposal that addresses the scope and privacy/pervasive 
>>> monitoring concerns and which has a critical mass of effort behind 
>>> it might certainly be worthy of consideration as bof.
>>
>>
>> Regards,
>>
>> Behcet On Wed, Oct 29, 2014 at 4:36 PM, joel jaeggli 
>> <[e-mail]> wrote:
>>> On 10/29/14 9:51 AM, Behcet Sarikaya wrote:
>>>> Hi Joel,
>>>>
>>>> On Wed, Oct 29, 2014 at 9:59 AM, joel jaeggli <[e-mail]>
>>>> wrote:
>>>>> On 10/29/14 7:10 AM, [e-mail] wrote:
>>>>>> Hi Brian,
>>>>>>
>>>>>> I echo your comment.
>>>>>>
>>>>>> None of the proposals inventoried in the HOST_ID effort is trying 
>>>>>> to do the same thing as X-UIDH header. Moreover, none of these 
>>>>>> proposals is endorsing the following headers (but not limited to) 
>>>>>> nor aims at revealing a customer ID, account ID, profile ID, 
>>>>>> etc.:
>>>>>>
>>>>>> HTTP_MSISDN, HTTP_X_MSISDN, HTTP_X_UP_CALLING_LINE_ID, 
>>>>>> HTTP_X_NOKIA_MSISDN, HTTP_X_HTS_CLID, HTTP_X_MSP_CLID, 
>>>>>> HTTP_X_NX_CLID, HTTP__RAPMIN, HTTP_X_WAP_MSISDN, HTTP_COOKIE, 
>>>>>> HTTP_X_UP_LSID, HTTP_X_H3G_MSISDN, HTTP_X_JINNY_CID, 
>>>>>> HTTP_X_NETWORK_INFO, ...
>>>>>>
>>>>>> Cheers, Med
>>>>>>
>>>>>> -----Message d'origine----- De : hiaps 
>>>>>> [mailto:[e-mail]] De la part de Brandon Williams 
>>>>>> Envoyé : mercredi 29 octobre 2014 14:55 À : joel jaeggli; 
>>>>>> [e-mail] Objet : Re: [hiaps] some discussion in the 
>>>>>> press...
>>>>>>
>>>>>> Agreed. Inserting a publicly visible user identifier is a bad 
>>>>>> idea. That's why all the proposals that have come from people on 
>>>>>> the hiaps list (to the best of my knowledge) have focused on 
>>>>>> relaying _host_ identifiers that are already publicly visible 
>>>>>> (generally the public IP address) through to the other side of 
>>>>>> middleboxes that are hiding such publicly visible identifiers. If 
>>>>>> there are proposals out there that violate this principle, I 
>>>>>> agree entirely that they should be abandoned.
>>>>>
>>>>> imho one of the assumptions I see in the work is that the host 
>>>>> identifier being relayed was previosuly not publicly visible, 
>>>>> hence the need for hostid injection.  That applies to nat 
>>>>> translation for example it also  applies to differentating between 
>>>>> prefix sharing UE's in IPV6 by something other than source 
>>>>> address.
>>>>>
>>>>> http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier
>>>>> -scenarios-07
>>>>>
>>>>>
> http://tools.ietf.org/html/rfc6269
>>>>>
>>>>> that's part of the reason for hiaps bof proposal to consider the 
>>>>> problem of securing such an identifier from differentiation by 
>>>>> surveillance.
>>>>
>>>> Absolutely.
>>>>
>>>> Should we revive the bof effort?
>>>
>>> you didn't hear me say that. I think you know where we left it.
>>>
>>> From my vantage point a bof proposal that addresses the scope and 
>>> privacy/pervasive monitoring concerns and which has a critical mass 
>>> of effort behind it might certainly be worthy of consideration as 
>>> bof.
>>>
>>>> I think that doing the standardization related to hosted in hiaps 
>>>> rather than intarea is the right way to go for IETF.
>>>
>>> We created this mailing list to have a place to discuss host 
>>> identification, we can use it for that or we can get rid of it.
>>>
>>>> Behcet
>>>>>
>>>>>> --Brandon
>>>>>>
>>>>>> On 10/29/2014 12:06 AM, joel jaeggli wrote:
>>>>>>> this is pretty much exactly what I would have expected from 
>>>>>>> injection on the wire of an identity token...
>>>>>>>
>>>>>>> http://webpolicy.org/2014/10/24/how-verizons-advertising-header-
>>>>>>> works/
>>>>>>>
>>>>>>>
>>>>>>>
> http://www.wired.com/2014/10/verizons-perma-cookie/
>>>>>>>
>>>>>>> http://www.forbes.com/sites/kashmirhill/2014/10/28/att-says-its-
>>>>>>> testing-unkillable-tracker-on-customers-smartphones/
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>
> _______________________________________________
>>>>> hiaps mailing list [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/hiaps
>>>>>
>>>>
>>>> _______________________________________________ hiaps mailing list 
>>>> [e-mail] https://www.ietf.org/mailman/listinfo/hiaps
>>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________ hiaps mailing list 
>>> [e-mail] https://www.ietf.org/mailman/listinfo/hiaps
>
>
>
>

_______________________________________________
hiaps mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/hiaps