Re: [dhcwg] Stephen Farrell's Discuss on draft-ietf-dhc-access-network-identifier-13: (with DISCUSS and COMMENT)

[Stephen Farrell <[e-mail]>]

On 08/02/16 22:32, Bernie Volz (volz) wrote:
> Hi Stephen and Brian:
> 
> I've added an item to the list of agenda requests regarding this. See
> https://github.com/dhcwg/wg/wiki/IETF-95-(Buenos-Aires)-DHC-WG-Agenda:
>
>  DHCP Relay / Server Communication and Pervasive Monitoring - 10
> minutes
> 
> Title of session: DHCP Relay / Server Communication and Pervasive
> Monitoring Presenter: TBD (Likely Bernie Volz) Related Drafts: None 
> Time Required: 10 min Purpose of Session: There were several IESG
> discusses regarding draft-ietf-dhc-access-network-identifier and the
> security implications of Relay to Server communication, especially
> with regard to Pervasive Monitoring. As the WG recently developed the
> privacy drafts which focused primarily on client/server interaction,
> does the WG want to take on writing a document to review the
> Relay/Server security implications and how best to mitigate them. See
> https://datatracker.ietf.org/doc/draft-ietf-dhc-access-network-identifier/ballot/
> for more details. Submitter: Bernie Volz

Great, thanks. Let me know if I can help.

Cheers,
S.

> 
> - Bernie
> 
> -----Original Message----- From: Stephen Farrell
> [mailto:[e-mail]] Sent: Monday, February 08, 2016
> 5:19 PM To: Bernie Volz (volz) <[e-mail]>; Brian Haberman
> <[e-mail]>; Sri Gundavelli (sgundave)
> <[e-mail]> Cc: The IESG <[e-mail]>;
> [e-mail];
> [e-mail]; [e-mail]; [e-mail] Subject:
> Re: Stephen Farrell's Discuss on
> draft-ietf-dhc-access-network-identifier-13: (with DISCUSS and
> COMMENT)
> 
> 
> Hi Bernie,
> 
> On 08/02/16 19:42, Bernie Volz (volz) wrote:
>> Brian:
>> 
>> I am not aware of such a specific discussion in the record ...
> 
> Thanks for clarifying.
> 
>> that doesn't mean it wasn't had, but just that I am not aware of
>> any specific record. Note that these emails and others regarding
>> Stephen's discusses were sent to the DHC WG mailing list but did
>> not generate any comments (except those from the co-authors).
> 
> Yeah, that's a fair comment. I would hope that if list members had
> opinions, they'd express them.
> 
>> We generally view the information that is exchanged between a relay
>>  and server are in "one" operator's domain and that this can be
>> (and should be) secured (such as using IPsec and/or VPNs -- RFC
>> 3315 already outlines IPsec usage). And, that if some third party
>> can monitor this flow, there is a lot more that they can gather
>> that is much more sensitive than these particular options.
>> 
>> The current privacy drafts (draft-ietf-dhc-dhcpv6-privacy-03, 
>> draft-ietf-dhc-dhcp-privacy-03,
>> draft-ietf-dhc-anonymity-profile-06) have focused on the client
>> interaction as that is viewed as being the most susceptible to
>> pervasive monitoring (as typically it requires just listening for
>> packets, or entering promiscuous mode). We did send notification of
>> those 3 privacy drafts to the pervasive monitoring mailing list and
>> receive absolutely no feedback on them 
>> (https://mailarchive.ietf.org/arch/msg/perpass/oFlTXR0LZalQZy9W5nKs2ZV
>>
>> 
fVFM)
>> - good or bad.
> 
> Yes, getting more comment is often hard but I think those drafts were
> discussed a little on the perpass list before they were adopted by
> the DHCWG. If if helps I could ask again and see if that gets any
> more comment, happy to do that if you want, just let me know.
> 
>> 
>> The WG has been working on seDhcpv6 but that has been a challenging
>>  document and has been sent back to the WG several times now - but
>> this work also primarily focuses on the client to server
>> communication.
>> 
>> Finally, these options, as all relay and client options are just 
>> hitching a ride on the DHCP exchange. So if this is a serious issue
>>  that the IESG and/or Int Area Directors feel the DHC WG needs to 
>> address, we can discuss at IETF-95 to see if there is interest from
>>  the WG to attempt to address the relay to server communication
>> channel to assure it is secure and prevents pervasive monitoring.
> 
> That sounds reasonable too, thanks. I'm fine to clear this discuss
> and see how that conversation goes.
> 
> FWIW, while I'd personally not argue that DHCP relay<->server poses
> the absolutely most important privacy problem on the Internet, I do
> think the conversation could be useful - given this WG has already
> done the privacy and nymity drafts you mention above, it could be
> that this set of participants are more aware of the issues. (Or maybe
> not, but good if we find out:-)
> 
> Thanks, S.
> 
> 
>> 
>> - Bernie
>> 
>> -----Original Message----- From: Brian Haberman 
>> [mailto:[e-mail]] Sent: Monday, February 08, 2016 
>> 1:40 PM To: Bernie Volz (volz) <[e-mail]>; Sri Gundavelli 
>> (sgundave) <[e-mail]> Cc: Stephen Farrell 
>> <[e-mail]>; The IESG <[e-mail]>; 
>> [e-mail]; 
>> [e-mail]; [e-mail]; [e-mail]
>> Subject: Re: Stephen Farrell's Discuss on 
>> draft-ietf-dhc-access-network-identifier-13: (with DISCUSS and 
>> COMMENT)
>> 
>> Hi Bernie & Sri,
>> 
>> On 2/8/16 1:08 PM, Bernie Volz (volz) wrote:
>>> Agree with Sri's points. DHC wg would like to advance draft.
>>> 
>>> - Bernie (from iPhone)
>>> 
>>>> On Feb 8, 2016, at 12:44 PM, Sri Gundavelli (sgundave) 
>>>> <[e-mail]> wrote:
>>>> 
>>>> 
>>>> Thanks Stephen.  If I read this correctly, I assume this is the
>>>> only pending DISCUSS point.
>>>> 
>>>> 
>>>>> "Did the DHC working group consider how this information,
>>>>> when sent without adequate protection between relay and dhcp
>>>>> server, could help in pervasive monitoring?"
>>>> 
>>>> I will let chairs answer this question.
>> 
>> I would like a chair to explicitly answer Stephen's question above
>> and provide a pointer to the mailing list archives or meeting
>> minutes where this point was discussed.
>> 
>> Specifically, did the WG reach a consensus on the sensitive 
>> information elements and their vulnerability to pervasive
>> monitoring?
>> 
>> Regards, Brian
>> 
>>>> 
>>>> 
>>>> But, from my point view:
>>>> 
>>>> 1.) we have identified the information elements that are
>>>> sensitive in nature from privacy point of view 2.) we have
>>>> identified the interfaces where these information elements can
>>>> possibly get exposed; interfaces where threats can be
>>>> activated 3.) we have listed the deployment context (Ex: Single
>>>> operator) 4.) we have listed considerations on how to entities
>>>> have to deal with this data; points such as not to store the
>>>> data at DHCP server ..etc. 4.) we have listed the existing
>>>> tools that are available for the operator to mitigate that
>>>> threat
>>>> 
>>>> All of these points were discussed in the DHC WG and there were
>>>> no explicit comments either supporting, or disagreeing with
>>>> these views.
>>>> 
>>>> 
>>>> Regards Sri
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On 2/8/16, 4:11 AM, "Stephen Farrell" 
>>>>> <[e-mail]> wrote:
>>>>> 
>>>>> Stephen Farrell has entered the following ballot position
>>>>> for draft-ietf-dhc-access-network-identifier-13: 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-dhc-access-network-iden
>>>>>
>>>>> 
t
>>>>> 
>>>>> 
> ifier/
>>>>> 
>>>>> 
>>>>> 
>>>>> -------------------------------------------------------------------
>>>>>
>>>>> 
-
>>>>> 
>>>>> 
> --
>>>>> DISCUSS: 
>>>>> -------------------------------------------------------------------
>>>>>
>>>>> 
-
>>>>> 
>>>>> 
> --
>>>>> 
>>>>> 
>>>>> Thanks for the changes made in response to my and, in
>>>>> particular, Alissa's discuss ballots.
>>>>> 
>>>>> Having looked back at the email thread I don't believe I got
>>>>> any answer to the question "Did the DHC working group
>>>>> consider how this information, when sent without adequate
>>>>> protection between relay and dhcp server, could help in
>>>>> pervasive monitoring?"
>>>>> 
>>>>> I think the focus of the discussion has been on the
>>>>> applicability of this being limited to "typically" one
>>>>> operator's network, which does of course mean that the
>>>>> traffic is less at risk than had it transited many networks.
>>>>> However, we have seen (Belgacom) that the PM threat also
>>>>> applies within a single operator's network. So I am still
>>>>> interested in the answer to the above question.
>>>>> 
>>>>> The DHC WG might consider this threat and still conclude that
>>>>> a SHOULD statement about IPsec is the best we can do in
>>>>> practice, but that isn't clear to me at present, so I'd still
>>>>> like to chat about the PM threat. (Note: it's the WG's
>>>>> consideration of the threat I'd like to chat about, not only
>>>>> about the potential of IPsec to mitigate that threat.)
>>>>> 
>>>>> 
>>>>> -------------------------------------------------------------------
>>>>>
>>>>> 
-
>>>>> 
>>>>> 
> --
>>>>> COMMENT: 
>>>>> -------------------------------------------------------------------
>>>>>
>>>>> 
-
>>>>> 
>>>>> 
> --
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> OLD DISCUSS TEXT BELOW:
>>>>> 
>>>>> (Sent mail 2016-01-10, checking on change vs. discuss)
>>>>> 
>>>>> (1) Did the DHC working group consider how this information,
>>>>> when sent without adequate protection between relay and dhcp
>>>>> server, could help in pervasive monitoring? If so, what was
>>>>> the conclusion reached? We have seen http header field
>>>>> information sent between infrastructure nodes being
>>>>> intercepted for that purpose, so this has to be similarly at
>>>>> risk.  If the answer is that this is only to be used within a
>>>>> single network operator's setup (or a roaming arrangement)
>>>>> then that needs to be justified (as practical) and, if it can
>>>>> be justified (I'm not sure tbh), also made explicit.
>>>>> 
>>>>> (2) I had a DISCUSS on the draft that became rfc 6757 about 
>>>>> protection of this kind of data. In that context I think I
>>>>> was assured that everything (in PMIPv6) was IPsec protected
>>>>> so it was fine.  Why, in what we now know is a more threated
>>>>> environment, is it ok to now have weaker protection when I
>>>>> was assured then that IPsec was in fact quite usable in
>>>>> PMIPv6? I think you maybe need to put in a MUST use IPsec
>>>>> requirement for this to be as safe.
>>>>> 
>>>>> (3) section 7: MAY store - this is possibly sensitive
>>>>> information so you ought say that it SHOULD NOT be stored
>>>>> unless needed, and if stored, SHOULD be deleted as soon as
>>>>> possible. Storing sensitive information when not needed just
>>>>> shouldn't be considered acceptable anymore I think - is that
>>>>> reasonable?
>>>>> 
>>>>> OLD COMMENT TEXT BELOW
>>>>> 
>>>>> - I (strongly) support Alissa's DISCUSS and will be
>>>>> interested in watching how that is resolved. Some of my
>>>>> DISCUSS points do overlap though so from my POV feel free to
>>>>> mix'n'match the discussions. Or to process first one then the
>>>>> other, whatever you think is best.
>>>>> 
>>>>> - RFC6757 defines exactly this for PMIPv6. That implies that 
>>>>> PMIPv6 should not be used to illustrate or motivate this, as
>>>>> that problem is solved. Perhaps you would be better off if
>>>>> you limited the scope of this to be used for networks that
>>>>> are some kind of extension to PMIPv6 only? (You'd need to
>>>>> define what kind I think.)
>>>> 
>>