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

[Alissa Cooper <[e-mail]>]

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.

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.

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

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.

Thanks,
Alissa

> On Sep 18, 2015, at 3:40 AM, Sri Gundavelli (sgundave) <[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 <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/ <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.
>> 
>>