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

From: "Stephen Farrell" <[email-masked]>
Date: Mon, 08 Feb 2016 04:11:40 -0800

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-identifier/

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

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 8 Feb 2016 17:44:09 +0000

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.

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 8 Feb 2016 18:08:57 +0000

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) <[email-masked]> wrote:
> 
>

---

From: Brian Haberman <[email-masked]>
Date: Mon, 8 Feb 2016 13:39:40 -0500

Hi Bernie & Sri,

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 8 Feb 2016 19:42:14 +0000

Brian:

I am not aware of such a specific discussion in the record ... 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).

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/oFlTXR0LZalQZy9W5nKs2ZVfVFM) - good or bad.

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.

- Bernie

-----Original Message-----
From: Brian Haberman [mailto:[email-masked]] 
Sent: Monday, February 08, 2016 1:40 PM
To: Bernie Volz (volz) <[email-masked]>; Sri Gundavelli (sgundave) <[email-masked]>
Cc: Stephen Farrell <[email-masked]>; The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
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:
>>> without adequate protection between relay and dhcp server, could 
>>> help in pervasive monitoring?"
>>

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

>> 2.) we have identified the interfaces where these information 
>> elements can possibly get exposed; interfaces where threats can be 
>> activated
>> 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
>>
>>> 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
>>> 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?"
>>>
>>> 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.
>>> 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.)
>>>
>>>
>>> (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.
>>>
>>> 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.
>>>
>>> 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.)
>>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 8 Feb 2016 22:19:20 +0000

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/oFlTXR0LZalQZy9W5nKs2ZVfVFM)
> - 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:[email-masked]] Sent: Monday, February 08, 2016
> 1:40 PM To: Bernie Volz (volz) <[email-masked]>; Sri Gundavelli
> (sgundave) <[email-masked]> Cc: Stephen Farrell
> <[email-masked]>; The IESG <[email-masked]>;
> [email-masked];
> [email-masked]; [email-masked]; [email-masked] Subject:
> Re: Stephen Farrell's Discuss on
> draft-ietf-dhc-access-network-identifier-13: (with DISCUSS and
> COMMENT)
> 
> Hi Bernie & Sri,
> 
>>> 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
>>>> could help in pervasive monitoring?"
>>> 
> 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
>>>  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
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> 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.
>>>> 
>>>> 
>>>> https://datatracker.ietf.org/doc/draft-ietf-dhc-access-network-ident
>>>>
>>>> 
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.
>>>> 
>>>>  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: 
>>>> --------------------------------------------------------------------
>>>>
>>>> 
--

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 8 Feb 2016 22:32:26 +0000

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:[email-masked]] 
Sent: Monday, February 08, 2016 5:19 PM
To: Bernie Volz (volz) <[email-masked]>; Brian Haberman <[email-masked]>; Sri Gundavelli (sgundave) <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Stephen Farrell's Discuss on draft-ietf-dhc-access-network-identifier-13: (with DISCUSS and COMMENT)

Hi Bernie,

Thanks for clarifying.

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

> 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

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.

> document and has been sent back to the WG several times now - but this 
> work also primarily focuses on the client to server communication.
> 
> 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.

> provide a pointer to the mailing list archives or meeting minutes 
> 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
>>> 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
>>> 
>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for more 
>>>> information about IESG DISCUSS and COMMENT positions.
>>>> 
>>>> 
ifier/
--
--
>>>> 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 
>>>> PM threat also applies within a single operator's network. So I am 
>>>> still interested in the answer to the above question.
>>>> 
--
--
>>>> 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 
>>>> (3) section 7: MAY store - this is possibly sensitive information 
>>>> so you ought say that it SHOULD NOT be stored unless needed, and if

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 8 Feb 2016 22:35:13 +0000

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:
>
> 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:[email-masked]] Sent: Monday, February 08, 2016
> 5:19 PM To: Bernie Volz (volz) <[email-masked]>; Brian Haberman
> <[email-masked]>; Sri Gundavelli (sgundave)
> <[email-masked]> Cc: The IESG <[email-masked]>;
>> 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).
> 
>>  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.
>> 
>> 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
> 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
>> 
>> [email-masked]; [email-masked]; [email-masked]
>> Subject: Re: Stephen Farrell's Discuss on 
>>>>> "Did the DHC working group consider how this information,
>>>>> server, could help in pervasive monitoring?"
>>>> 
>> and provide a pointer to the mailing list archives or meeting
>> minutes where this point was discussed.
>> 
>>>> 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
>>>> 
>>>> no explicit comments either supporting, or disagreeing with
>>>> these views.
>>>> 
>>>> 
>>>> Regards Sri
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> 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://datatracker.ietf.org/doc/draft-ietf-dhc-access-network-iden
>>>>>
>>>>> 
t
>>>>> 
>>>>> 
> ifier/
>>>>> 
>>>>> 
>>>>> 
>>>>> -------------------------------------------------------------------
>>>>>
>>>>> 
-
>>>>> 
>>>>> 
> --
>>>>> DISCUSS: 
>>>>> -------------------------------------------------------------------
>>>>>
>>>>> 
-
>>>>> 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?"
>>>>> 
>>>>> 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.
>>>>> 
>>>>> a SHOULD statement about IPsec is the best we can do in
>>>>> -------------------------------------------------------------------
>>>>>
>>>>> 
-
>>>>> 
>>>>> 
> --
>>>>> COMMENT: 
>>>>> -------------------------------------------------------------------
>>>>>
>>>>> 
-
>>>>> 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.
>>>>> 
>>>>> 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.
>>>>> 
>>>>> - 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.
>>>>> 
>>>>> 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.)
>>>> 
>>