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

Alissa Cooper <alissa@cooperw.in> Mon, 07 December 2015 22:42 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB7E1B2A37 for <dhcwg@ietfa.amsl.com>; Mon, 7 Dec 2015 14:42:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAFo-ItZthKa for <dhcwg@ietfa.amsl.com>; Mon, 7 Dec 2015 14:42:33 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7BA91B2A34 for <dhcwg@ietf.org>; Mon, 7 Dec 2015 14:42:32 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 42CFC20B89 for <dhcwg@ietf.org>; Mon, 7 Dec 2015 17:36:04 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 07 Dec 2015 17:36:04 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=8EZyA 39icnng3WRFTsRnIaCG0Jk=; b=qbehikWntZWGtVl2z5AW44FR7L+hMl2ZXv5yj wZ8L+ndoSgVh/l7EgOAG0UPEYHmVd68ID5m8/L+qc+xBc2KwGREZWBBu96qsDtGy 8+8VyQWB5mxLfPNizo5tfFw0kQ9mJqkwY65WhbPVB5U2BrACT7x8vfAaUlQ0DdqW O0D9iE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=8EZyA39icnng3WRFTsRnIaCG0Jk=; b=Jju6T ds4hZHY9ZQ8evWWTjX8oLWFXOspAlHMG2+i7f6ZY2z4A1zrXt4vqNHfQH6HR/Fcp +i/jX7FkEOwo4g4TtnVHr+8U4P2hGsx9NvFhmaJFjs9iysxxQHPmRUJK2GGBBbNZ 23LdW+8tZL61nKznDJlrJILdzoeQW/7vqlZ4Zc=
X-Sasl-enc: Mq2PmaF0I5fLAPd38/Qqhfuji+eecDmfxHQpv/5n3vI6 1449527763
Received: from dhcp-171-68-20-168.cisco.com (dhcp-171-68-20-168.cisco.com [171.68.20.168]) by mail.messagingengine.com (Postfix) with ESMTPA id CAF68C01903; Mon, 7 Dec 2015 17:36:02 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_DC1CD07E-2617-4522-A03B-C39F4245C1CF"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <D28226D3.1F7900%sgundave@cisco.com>
Date: Mon, 07 Dec 2015 14:36:01 -0800
Message-Id: <602FD3C4-9F15-44F5-AC4F-6E0F15B88637@cooperw.in>
References: <20150914211018.30653.52466.idtracker@ietfa.amsl.com> <34FDFAC6-9DE1-44FB-B4D0-EE501DC6B557@cisco.com> <4D710102-913D-4FEF-9B74-4F3674979212@cooperw.in> <D2203E8E.1D837C%sgundave@cisco.com> <7384526D-59AF-4F48-9F5B-D9D8B6A39679@cooperw.in> <D28226D3.1F7900%sgundave@cisco.com>
To: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/WK6v5p9UZDcE9W17jnBfRK6lNo8>
Cc: "Bernie Volz (volz)" <volz@cisco.com>, "dhc-chairs@ietf.org" <dhc-chairs@ietf.org>, "draft-ietf-dhc-access-network-identifier.shepherd@ietf.org" <draft-ietf-dhc-access-network-identifier.shepherd@ietf.org>, IESG <iesg@ietf.org>, "draft-ietf-dhc-access-network-identifier.ad@ietf.org" <draft-ietf-dhc-access-network-identifier.ad@ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>, "draft-ietf-dhc-access-network-identifier@ietf.org" <draft-ietf-dhc-access-network-identifier@ietf.org>
Subject: Re: [dhcwg] Alissa Cooper's Discuss on draft-ietf-dhc-access-network-identifier-10: (with DISCUSS)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2015 22:42:38 -0000

Hi Sri,

> On Nov 30, 2015, at 4:35 PM, Sri Gundavelli (sgundave) <sgundave@cisco.com> wrote:
> 
> Hi Alissa,
> 
> I some how missed this email. Please see inline.
> 
> 
> From: Alissa Cooper <alissa@cooperw.in <mailto:alissa@cooperw.in>>
> Date: Monday, November 2, 2015 at 10:53 PM
> To: Sri Gundavelli <sgundave@cisco.com <mailto:sgundave@cisco.com>>
> Cc: "Bernie Volz (volz)" <volz@cisco.com <mailto:volz@cisco.com>>, IESG <iesg@ietf.org <mailto:iesg@ietf.org>>, "dhc-chairs@ietf.org <mailto:dhc-chairs@ietf.org>" <dhc-chairs@ietf.org <mailto:dhc-chairs@ietf.org>>, "draft-ietf-dhc-access-network-identifier.shepherd@ietf.org <mailto:draft-ietf-dhc-access-network-identifier.shepherd@ietf.org>" <draft-ietf-dhc-access-network-identifier.shepherd@ietf.org <mailto:draft-ietf-dhc-access-network-identifier.shepherd@ietf.org>>, "draft-ietf-dhc-access-network-identifier.ad@ietf.org <mailto:draft-ietf-dhc-access-network-identifier.ad@ietf.org>" <draft-ietf-dhc-access-network-identifier.ad@ietf.org <mailto:draft-ietf-dhc-access-network-identifier.ad@ietf.org>>, "draft-ietf-dhc-access-network-identifier@ietf.org <mailto:draft-ietf-dhc-access-network-identifier@ietf.org>" <draft-ietf-dhc-access-network-identifier@ietf.org <mailto:draft-ietf-dhc-access-network-identifier@ietf.org>>, "jiangsheng@huawei.com <mailto:jiangsheng@huawei.com>" <jiangsheng@huawei.com <mailto:jiangsheng@huawei.com>>, "dhcwg@ietf.org <mailto:dhcwg@ietf.org>" <dhcwg@ietf.org <mailto:dhcwg@ietf.org>>
> 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) <sgundave@cisco.com <mailto:sgundave@cisco.com>> 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" <alissa@cooperw.in <mailto:alissa@cooperw.in>> wrote:
>> 
>>> Hi Bernie,
>>> 
>>>> On Sep 14, 2015, at 2:29 PM, Bernie Volz (volz) <volz@cisco.com <mailto:volz@cisco.com>> 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 <alissa@cooperw.in <mailto:alissa@cooperw.in>> 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.
>>> 
>>> 
>