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

"Bernie Volz (volz)" <> Mon, 14 September 2015 21:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EC7C51B2AAD; Mon, 14 Sep 2015 14:30:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ANaQsleVlpbs; Mon, 14 Sep 2015 14:30:01 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 409CB1B2ABA; Mon, 14 Sep 2015 14:29:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3436; q=dns/txt; s=iport; t=1442266195; x=1443475795; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rfrT4j9y2d/fFtBrvHBoOcvNRtdCKmPJHbUchqm60HM=; b=Tn//8N5LpFSmsAZvr6UZISqgNiDIjvtBfaKcIqwkPq7GbvFsXPPr7eXE jCDKhIsc/2tfeJvmvaGlEZ30uomOH02Q5UY23jhGGLUMQ2nBV39AYOly0 y5HtOvWMhcHV6C1x0BTfsYDrVR502Xh8Se1nHDO8c1RerYizD+6b2EO5A I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.17,531,1437436800"; d="scan'208";a="28854273"
Received: from ([]) by with ESMTP; 14 Sep 2015 21:29:54 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t8ELTsvn027412 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Sep 2015 21:29:54 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 14 Sep 2015 16:29:53 -0500
Received: from ([]) by ([]) with mapi id 15.00.1104.000; Mon, 14 Sep 2015 16:29:53 -0500
From: "Bernie Volz (volz)" <>
To: Alissa Cooper <>
Thread-Topic: Alissa Cooper's Discuss on draft-ietf-dhc-access-network-identifier-10: (with DISCUSS)
Thread-Index: AQHQ7zHMe8J8eUQKekG7Nnp36VG4tp48ipnr
Date: Mon, 14 Sep 2015 21:29:53 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>, The 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: Mon, 14 Sep 2015 21:30:03 -0000


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.

Also, this usage makes snooping harder - it is in the SPs network behind the relay agents.

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