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

Alissa Cooper <> Wed, 16 September 2015 12:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1DBDE1AD0A4 for <>; Wed, 16 Sep 2015 05:31:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sUiD_s4pf5kB for <>; Wed, 16 Sep 2015 05:30:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CB5F31A3B9F for <>; Wed, 16 Sep 2015 05:30:57 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 8279B219AA for <>; Wed, 16 Sep 2015 08:30:56 -0400 (EDT)
Received: from frontend2 ([]) by compute2.internal (MEProxy); Wed, 16 Sep 2015 08:30:56 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=yO5aYh0G3FGnQXvryFEKQU6y0Wg=; b=V/quc7 p75geevigP1g1E6AUDU+FNmWHWdIkA6JqYjkpg7FI2n2yskxnH1i8adRox2ZDKtM mF35ATMemLOFaydfbduLknJ14ZdDFC5D3yzjeMy/GR19qvGcVwUAFXSmi/5WHxjN 92U0QLodspuocnsxiXGRbttSHiIDa8NWi71ZI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=yO5aYh0G3FGnQXv ryFEKQU6y0Wg=; b=en+pm+SttMzrctojQ1+u77XjEhOnd9BIgjhMl/rxm8AgZpO UYWCAbmFPlCRHx3yPUi+auwjbrr3pCfWvfsLK7i6heWnC220cvwbj+hxcSi+zZP0 YHfL3WvAQQA5fOGGIDK+uNI8cCrhOxJDxvD4+i4PY/3miTzLrQCqSFDbp/ZU=
X-Sasl-enc: DOgM46Yy0rA2rw5bAdgj8Fa/JpmUdA+RDvQUVlb0hagC 1442406656
Received: from (unknown []) by (Postfix) with ESMTPA id 652B568018E; Wed, 16 Sep 2015 08:30:55 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Alissa Cooper <>
In-Reply-To: <>
Date: Wed, 16 Sep 2015 05:30:54 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: "Bernie Volz (volz)" <>
X-Mailer: Apple Mail (2.2104)
Archived-At: <>
Cc: "" <>, "" <>, IESG <>, "" <>, "" <>, "" <>
Subject: Re: [dhcwg] Alissa Cooper's Discuss on draft-ietf-dhc-access-network-identifier-10: (with DISCUSS)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Sep 2015 12:31:00 -0000

Hi Bernie,

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


> - Bernie (from iPad)
>> On Sep 14, 2015, at 5:10 PM, Alissa Cooper <> 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
>> 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.