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

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 14 Oct 2015 19:20:04 +0000

Hi Alissa,

Are you Ok with this response. I realize the other 2 DICUSS positions/comments were tied to this DISCUSS and so wanted to close this first.

Regards
Sri

From: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 17, 2015 at 11:40 AM
To: Alissa Cooper <[email-masked]<mailto:[email-masked]>>, "Bernie Volz (volz)" <[email-masked]<mailto:[email-masked]>>
Cc: IESG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Alissa Cooper's Discuss on draft-ietf-dhc-access-network-identifier-10: (with DISCUSS)

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

Hi Bernie,

On Sep 14, 2015, at 2:29 PM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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.