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

"Alissa Cooper" <alissa@cooperw.in> Mon, 14 September 2015 21:10 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 131701A1B0D; Mon, 14 Sep 2015 14:10:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.1
X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id fQia7_Z6wLpA; Mon, 14 Sep 2015 14:10:30 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9411A0451; Mon, 14 Sep 2015 14:10:18 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper <alissa@cooperw.in>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.4.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150914211018.30653.52466.idtracker@ietfa.amsl.com>
Date: Mon, 14 Sep 2015 14:10:18 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/17b2yzdJOS1hif95kRIQXidudI8>
Cc: dhc-chairs@ietf.org, draft-ietf-dhc-access-network-identifier.shepherd@ietf.org, draft-ietf-dhc-access-network-identifier.ad@ietf.org, dhcwg@ietf.org, draft-ietf-dhc-access-network-identifier@ietf.org
Subject: [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
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, 14 Sep 2015 21:10:32 -0000

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:


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.