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

[Alissa Cooper <[e-mail]>]

Hi Bernie,

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