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

["Bernie Volz (volz)" <[e-mail]>]

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.

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