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

["Bernie Volz (volz)" <[e-mail]>]

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

- 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.)
>>> 
>