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

["Sri Gundavelli (sgundave)" <[e-mail]>]

Hi Stephen,

Thank you for your response.


On 1/10/16, 1:53 PM, "Stephen Farrell" <[e-mail]> wrote:

>
>Hi Sri,
>
>Sorry for the slow response, I see you've posted -11 so this
>response is based on the diff from -10 to -11. Apologies if
>I've lost some context over the holidays, but I'm sure we can
>re-establish that quickly enough.


Not an issue. I understand, it was the holiday break. I had the same
issue, I need to close one thread.



>
>On 14/12/15 17:18, Sri Gundavelli (sgundave) wrote:
>> <Resending with the correct subject line>
>> 
>> 
>> From: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>
>> Date: Tuesday, December 8, 2015 at 3:06 PM To: Stephen Farrell
>> <[e-mail]<mailto:[e-mail]>> Cc:
>> "Bernie Volz (volz)" <[e-mail]<mailto:[e-mail]>>, IESG
>> <[e-mail]<mailto:[e-mail]>>,
>> "[e-mail]<mailto:[e-mail]>"
>> <[e-mail]<mailto:[e-mail]>>,
>> 
>>"[e-mail]<mailto:draft-
>>[e-mail]>"
>> 
>><[e-mail]<mailto:draft-
>>[e-mail]>>,
>> 
>>"[e-mail]<mailto:draft-ietf-d
>>[e-mail]>"
>> 
>><[e-mail]<mailto:draft-ietf-d
>>[e-mail]>>,
>> 
>>"[e-mail]<mailto:draft-ietf-dhc-
>>[e-mail]>"
>> 
>><[e-mail]<mailto:draft-ietf-dhc-
>>[e-mail]>>,
>> Brian Haberman
>> <[e-mail]<mailto:[e-mail]>>,
>> "<[e-mail]<mailto:[e-mail]>>"
>> <[e-mail]<mailto:[e-mail]>> Subject: Re: Ben Campbell's
>> Discuss on draft-ietf-dhc-access-network-identifier-10: (with
>> DISCUSS)
>> 
>> Hi Stephen,
>> 
>> Thank you for your review. We probably addressed most of these issues
>> as part of addressing Alissa's comments as there is overlap. Any
>> case, please let us know if you are not happy with the changes.
>
>I note that Alissa hasn't yet cleared her discuss and her mail
>from Dec 8th didn't seem to indicate that was about to happen.
>(Though the direction in which the discussion seems to be heading
>looks good.)


[Sri] We posted the updated version just couple of days back. My draft
editor did miss one email and missed some agreed text. But, my
understanding is that we have an agreement with Alissa on the text. I read
the thread again, at least that is my understanding.

https://www.ietf.org/mail-archive/web/dhcwg/current/msg17132.html



>
>> 
>> 
>> 
>> (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.
>> 
>> [Sri] I believe this issue is now resolved after discussions with
>> Alissa Cooper and the newly agreed text that introduces the "same
>> operator" assumption.
>
>Sorry, it's not clear to me that it does. Can you explain how
>the addition of "collocated" in section 2 resolves this? (Or
>if I got the change wrong, can you say what change addresses
>the issue?)

The information at risk is on the interface between the DHCP Relay and the
DHCP Server. The functions involved in this transaction and in the current
context are in the access network. In all SP Wi-Fi deployments the DHCP
server is in the access network and which is the MAG/TWAG and the DHCP
Relay is on the Wireless Termination point/AP. I'm not aware of any
deployment where the access network is operated by two operators. Per
Alissa's comment, if we have an applicability note that states this
assumption, I assumed IESG is OK to clear the DISCUSS.


Per Alissa¹s comment:
"
my thinking is that what would help here is an applicability statement
that explains that these options are being specified only for the purpose
of communicating access network identification between a DHCP relay agent
and a Mobile Access Gateway where the same operator typically operates
both.²

"The scope of applicability for this option is between a DHCP relay agent
and a Mobile Access Gateway where the same operator typically operates
both. Do you have difficulty to put a note about this limitation in scope
into the draft?"


NEW:
"This document specifies Dynamic Host Configuration Protocol for IPv4
   (DHCPv4) [RFC2131] and Dynamic Host Configuration Protocol for IPv6
   (DHCPv6) [RFC3315] options for access network identification that is
   added by Relay agent in the DHCPv4 or DHCPv6 messages towards the
   Server.  The scope of applicability for this option is between a DHCP
relay    agent and a mobile access gateway where the same operator
typically
operates both these functions"






>
>> 
>> 
>> (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.
>> 
>> 
>> [Sri] No, its not. We are still identifying the information that is
>> at risk in certain operating environments. We are also listing the
>> tools that operator has their disposal as per the below text. The
>> question is that determination on when the information is at risk, if
>> its an operator call, or IETF call. I'm OK, but I will let Bernie and
>> other DHCP experts comment on this MUST requirement.
>> 
>> 
>> "In deployments where this information is considered secure and when
>> such threat cannot be mitigated using IPsec [RFC4301] or other
>> security protocols, then the administrators have to consider
>> disabling the capability specified in this document on the DHCP
>> entities."
>
>Again, sorry for the loss of context, but I'm not getting how
>that addition resolves the issue, can you explain?


Both in RFC 6757 and in the below document, we have identified the
information which is at risk and the tools that can be used to protect it.
I though we are consist with respect to IPsec use.


Here is the text from RFC 6757:

"The Geo-Location sub-option carried in the Access Network Information
   option exposes the geo-location of the network to which the mobile
   node is attached.  This information is considered to be very
   sensitive, so care must be taken to secure the Proxy Mobile IPv6
   signaling messages when carrying this sub-option.  The base Proxy
   Mobile IPv6 specification [RFC5213] specifies the use of IPsec for
   securing the signaling messages, and those mechanisms can be enabled
   for protecting this information.  Operators can potentially apply
   IPsec Encapsulating Security Payload (ESP) with confidentiality and
   integrity protection for protecting the location information."



Here is the text from the current draft:

"In deployments where this information is considered secure and when
such threat cannot be mitigated using IPsec [RFC4301] or other
security protocols, then the administrators have to consider
disabling the capability specified in this document on the DHCP
entities."



RFC 5213:

IPsec is a mandatory-to-implement security
mechanism. However, additional documents may specify alternative
mechanisms and the mobility entities can enable a specific mechanism
for securing Proxy Mobile IPv6 signaling messages, based on either a
static configuration or after a dynamic negotiation using any
standard security negotiation protocols.













>
>> 
>> (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?
>> 
>> 
>> [Sri] Ok.
>> 
>> Looking at RFC 7268, SSID (Network-Id-Name attribute) can be present
>> in accounting records. So, this information is stored by network
>> functions.
>
>I don't see a change in section 7 - are you saying that none
>is needed?


Yes. This needs to go in. Sorry about that.


Regards
Sri





>
>Thanks and sorry again for the loss of context,
>Cheers,
>S.
>
>
>> 
>> 
>> 
>> *
>> 
>> 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.
>> 
>> 
>> 
>> [Sri] We resolved it; hope you are OK with the conclusion.
>> 
>> - 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.)
>> 
>> [Sri] I believe with all the text around "single operator", "IPsec"
>> and other assumptions, I think we have resolved this issue.
>> 
>> Thanks for the reviews.
>> 
>> Regards Sri
>> 
>>