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

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

Hi Alissa,


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

My comment was about not making any assumptions in protocol documents on who operates what network function.  At the end of the day its about how these paths are secured and less about who operates them. But, its OK, we can add this note.


OLD:

   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.


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



Regards
Sri


From: Alissa Cooper <[e-mail]<mailto:[e-mail]>>
Date: Monday, December 7, 2015 at 2:36 PM
To: Sri Gundavelli <[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:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: Alissa Cooper's Discuss on draft-ietf-dhc-access-network-identifier-10: (with DISCUSS)

Hi Sri,

On Nov 30, 2015, at 4:35 PM, Sri Gundavelli (sgundave) <[e-mail]<mailto:[e-mail]>> wrote:

Hi Alissa,

I some how missed this email. Please see inline.


From: Alissa Cooper <[e-mail]<mailto:[e-mail]>>
Date: Monday, November 2, 2015 at 10:53 PM
To: Sri Gundavelli <[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:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: Alissa Cooper's Discuss on draft-ietf-dhc-access-network-identifier-10: (with DISCUSS)

Hi Sri,

Thanks. I get the use case for AP MAC address now and the relationship between this draft and RFC 6757.

Your response on the scoping questions is quite different from Bernie’s. If the intention really is to use these options in a wide variety of system architectures, I don’t believe the security considerations as specified are sufficient to protect the information in the options.

On the other hand, if the scope is limited in the way Bernie alluded to, 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 lack of any strong normative security requirements can be justified in that realm of applicability I think.

[Sri] The operating environment is about an access network operated by a single operator. MAG is in the access network and the L2 termination devices are in the access network; that is the case in all currently known deployment models.  The current spec just focusses on this aspect and the example and the context is all about this scenario. You can ignore my previous explanation, if it appeared more that that. With the IESG proposed changes, we now have clearly identified the information elements at risk and the security requirement of needing IPsec with privacy protection for protecting that information elements.  I do not think explicit applicability-note is  needed, IMHO, as it is difficult to model protocols bringing roaming relations into the scope.

I don’t think the modeling you mention is necessary in order to write an applicability statement, if I understand you correctly. 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?

Thanks,
Alissa

>From the past IESG inputs and discussions, the general view was not to bring roaming relations into mobility protocols as that can muddle the waters. We always viewed roaming relation is more about sharing of security relation and so we avoided modeling of roaming relationships in mobility specs.  But, given that the MAG and DHCP Relay agent are in the access network, this should address your key concern.



Even if the applicability statement gets added, I still think the security considerations should make normative recommendations. Here are some suggestions for the problematic text I called out in my DISCUSS:

OLD

   DHCP itself is inherently insecure and thus link-
   layer confidentiality and integrity protection should be employed to
   reduce the risk of disclosure and tampering.

NEW

   DHCP itself is inherently insecure and thus link-
   layer confidentiality and integrity protection SHOULD be employed to
   reduce the risk of disclosure and tampering.


[Sri] Ok.



OLD
DHCP server administrators are
   strongly advised to configure DHCP servers that use this option to
   communicate with their relay agents using IPsec, as described in
   Section 21.1 of [RFC3315].

NEW
DHCP server administrators SHOULD configure DHCP servers that use this option to
   communicate with their relay agents using IPsec, as described in
   Section 21.1 of [RFC3315].


[Sri] OK


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

NEW
In deployments where this information cannot be secured using IPsec [RFC4301] or
   other security protocols, administrators SHOULD disable the capability specified in this document on the DHCP entities.

[Sri] OK.



If you are OK, we can close this with the below changes.

Regards
Sri



On Sep 18, 2015, at 3:40 AM, Sri Gundavelli (sgundave) <[e-mail]<mailto:[e-mail]>> wrote:

Hi Alissa,

Thanks for your review comments.

If I may summarize the issues raised in your DISCUSS, it is pointing to three key discussion points.

1.) Access Network Information elements
2.) Application and use-cases of the options
3.) Securing the information / aka DHCP security

#1 The options that we defined in DHCP for carrying these ANI elements are subset of the ANI options that we have defined in RFC6757. There we have defined Network Identifier, Geo-Location and Operator Identifier options and the options here are just the subset of the same, missing ones are already present in DHCP.  The structure, semantics and the options and security implications of exposing them to an intruder are identical to what was defined in RFC6757. What is different here is the change of protocol and the network elements carrying these IE’s. RFC 6757, carries them between MAG and LMA, with out any assumption on how the MAG can possibly obtain them and here we fix that by allowing the DHCP elements carry the same and have the network elements such as TWAG/MAG carry them to the PGW/LMA over PMIP/GTP interfaces. There are no new IE definitions, these are the same elements from RFC6757.

#2 This is a generic DHCP option and can be used in any system architecture. It is true, the use-case that is driving this requirement is WLAN-EPC integration/SP Wi-Fi architectures, but it has wider applicability. There is lot of value around exposing the information of the network to which a user is attached. This is fundamental to many location-based services.

- Portal Page customization based on the user-location. Lets say, Starbucks wants to present a portal page which is different for a user attached to an Access Point in Starbucks Seatlle, vs Starbucks in San Jose. If the AP identity is present, the backend infra can generate a portal page customized for that location, or redirect the user to a different URL.

- Taking the 3GPP SaMOG architecture for WLAN-EPC integration.We have extended 3GPP S2a PMIP/GTP interfaces for signaling the WLAN user’s location. The extensions proposed for DHCP here allows the MAG/TWAG to obtain the same over DHCP, so it can signal this to the PGW/LMA over S2a interface. The P-GW may signal this information to attached elements, (e.g., using Gx to signal the PCRF) when a user’s location has changed. The Wi-Fi location is similar to the User Location Information (ULI) field. ULI is specified to support CGI, SAI, RAI, TAI, ECGI and LAI (Cellar access identifiers).

- Taking Wi-Fi calling as an example and when deployed in a trusted Wi-Fi network where the operator own the Wi-Fi access network, there some operators want to restrict the use of Wi-Fi calling from certain locations/or use different charging tariff.  Knowing the AP identity offers such capability. This is also essential for E-911/emergency services. Some one makes a call for ambulance and says he is getting heart attack, the E911 responder should be reasonably sure where that call is coming from.


#3 DHCP Security, as I understand is a sensitive topic. From my point of view, there are tools and  IPSec is one such tool. IPSec can be used between the DHCP Relay and the Server and nothing stops me from realizing that. The enabled security policy can be  with integrity, privacy and non repudiation. There is also the option to disable this support on DHCP server. It can just ignore them. To the point, why DHCP is used. In many deployment models that is the only interface between a AP and the TWAG/MAG and leveraging the same helps.


   The information elements that this draft is exposing is the client's
   access-network information.  These pertain to the access network to
   which the client is attached, such as Access Technology Type (Ex:
   WLAN, Ethernet...etc), Access Point Identity (Name, BSSID), Operator
   Id/Realm.  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.



Alissa CooperDiscuss
Discuss (2015-09-14)

I have some questions about this draft. They derive from the position that some of the values in the options specified can reveal sensitive information about the mobile user. I would put access network name (especially when it's SSID, since people put identifying information in SSIDs), access point name, and BSSID in that category at a minimum.

The draft specifies DHCP options for downstream use in PMIPv6 scenarios, but makes no mention about actually limiting the use of these options to those scenarios. It's not clear to me whether those limits could be achieved in any case, since an AP won't know a priori whether it is being deployed in a service-provider-WiFi or cellular context or not. So what is the authors' expectation about the breadth of deployment of these options? Every DHCP stack? Something less than that? Furthermore, are any of the individual fields required or optional? RFC 6757 indicates that within PMIPv6 only the ATT is required.

Given the drawbacks discussed in Section 9, why was DHCP the protocol chosen for this? Is there no other protocol that APs speak to MAGs that has confidentiality, integrity protection, and authentication support? If DHCP is the only choice, why are none of the security fixes normatively required ("confidentiality and integrity protection should be employed," "DHCP server administrators are strongly advised to configure DHCP servers ... using IPsec," "administrators have to consider disabling the capability specified")?

Why would an LMA need the MAC address of the AP? Are there examples of policies that mobile networks have in place that apply differently to two devices connected to the same SSID but different APs, for example? I looked for this in RFC 6757 too but did not see it. Given the potential sensitivity of this field it seems like a justification for sharing it in an eavesdroppable way needs to be provided.

St





On 9/16/15, 5:30 AM, "Alissa Cooper" <[e-mail]<mailto:[e-mail]>> wrote:

Hi Bernie,

On Sep 14, 2015, at 2:29 PM, Bernie Volz (volz) <[e-mail]<mailto:[e-mail]>> wrote:
Alissa:
These options are only added and processed between dhcp relay-agents and servers. No dhcp clients need changing.
As the operator typically runs both the relays and servers, they should know when to configure use of these options (sub-options) based on their network needs. Also, unless there is some reason the servers needs this information, there is no need to configure use.

Thanks. Could all of the above be made normative requirements in the draft? Still wouldn’t make me super comfortable, but at least the draft would have a clear discussion of the limitations in deployment and expectations placed on admins.

Also, this usage makes snooping harder - it is in the SPs network behind the relay agents.

Not sure what snooping you’re referring to.

Still wondering about the rest of my questions below.

Thanks,
Alissa

- Bernie (from iPad)
On Sep 14, 2015, at 5:10 PM, Alissa Cooper <[e-mail]<mailto:[e-mail]>> wrote:
Alissa Cooper has entered the following ballot position for
draft-ietf-dhc-access-network-identifier-10: 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:
----------------------------------------------------------------------
I have some questions about this draft. They derive from the position
that some of the values in the options specified can reveal sensitive
information about the mobile user. I would put access network name
(especially when it's SSID, since people put identifying information in
SSIDs), access point name, and BSSID in that category at a minimum.
The draft specifies DHCP options for downstream use in PMIPv6 scenarios,
but makes no mention about actually limiting the use of these options to
those scenarios. It's not clear to me whether those limits could be
achieved in any case, since an AP won't know a priori whether it is being
deployed in a service-provider-WiFi or cellular context or not. So what
is the authors' expectation about the breadth of deployment of these
options? Every DHCP stack? Something less than that? Furthermore, are any
of the individual fields required or optional? RFC 6757 indicates that
within PMIPv6 only the ATT is required.
Given the drawbacks discussed in Section 9, why was DHCP the protocol
chosen for this? Is there no other protocol that APs speak to MAGs that
has confidentiality, integrity protection, and authentication support? If
DHCP is the only choice, why are none of the security fixes normatively
required ("confidentiality and integrity protection should be employed,"
"DHCP server administrators are strongly advised to configure DHCP
servers ... using IPsec," "administrators have to consider disabling the
capability specified")?
Why would an LMA need the MAC address of the AP? Are there examples of
policies that mobile networks have in place that apply differently to two
devices connected to the same SSID but different APs, for example? I
looked for this in RFC 6757 too but did not see it. Given the potential
sensitivity of this field it seems like a justification for sharing it in
an eavesdroppable way needs to be provided.