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

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 8 Dec 2015 22:34:10 +0000

Hi  Ben,

Thanks for your review. Please see inline.

-- 4.3.2

The name of an 802.11 access point can imply the users location with a fair bit of precision, making it effectively count as location data. The draft needs  more discussion of the privacy implications of that.

[Sri] I believe this issue is now resolved after discussions with Alissa Cooper and the newly agreed text.

-- 6:
This section seems underspecified. There seems to be a missing discussion about interdependencies among options. For example, For example, network name is meaningless without the technology type. What is the minimum needed to be coherent?

[Sri] Agree. Its mainly the ATT that must be present with certain options. In each of those option section, we will state this explicitly.

I support  Stephen's and Alissa's discusses, and look forward to their resolution.

-- 4.3.1:
This mentions how to interpret the network name for 802.11, 3GPP, and 3GPP2 networks. Is the use of this sub-option limited to those technology types? How should it be interpreted for other types?

[Sri] This covers all the currently defined access technologies in ATT registry (CDMA, GSM and WLAN based access networks). For new ATT values that are yet to be defined the network name has to be interpreted as defined in the document that introduces those ATT values.

-4.3.2, Access-Point Name
The paragraph refers to the MAC address of a device. Which device is it talking about? (e.g. end-device, base station, DHCP relay)

[Sri] Its the MAC address one of the interfaces of the access point.

OLD:

      In some deployments, the Access-Point
      Name can be set to the string representation of the Media Access
      Control (MAC) address as specified in [RFC6991] mac-address string
      type of the device or some unique identifier that can be used by
      the policy systems in the operator network to unambiguously
      identify the device.  The encoding MUST be UTF-8 as described in
      [RFC3629].

NEW:

      In some deployments, the Access-Point
      Name can be set to the string representation of the Media Access
      Control (MAC) address as specified in [RFC6991] mac-address string
      type of the device or some unique identifier that can be used by
      the policy systems in the operator network to unambiguously
      identify the device. The MAC address is typically from one of the

      interfaces of the access point.  The encoding MUST be UTF-8 as described in

      [RFC3629].

-- 4.4.1:
[SMI] probably needs to be a normative reference.

[Sri] Ok

-- 7, first sentence:
This seems to be making a MUST level requirement for servers that do not implement this draft. Is this a new MUST, or is already specified elsewhere? (If the latter, then citation?)

[Sri] I believe its existing behavior.

RFC 3315 and RFC 2131 ? Bernie ?

   "If DHCPv4 server does not understand the option defined in Section 4
   it MUST ignore the DHCPv4 Access Network Identifier option received; this is as specified in the base documents RFC2131 and RFC3315"

Editorial:

-- 1, paragraph 2, First sentence:
Missing article for DHCP relay agent
s/add/adds/

[Sri] OK.

-- 2, 2nd paragraph:
Lots of missing articles for MAG.

[Sri] OK

-- 3, SSID definition:
s/the IEEE/an IEEE/
s/one network to the other/ one network from another/

[Sri] OK

-- 5.1, reserved:
The reader's "now" may be years from the authors' "now" :-) I suggest something to the effect of "At the time of this writing"

Ok.

OLD:

      An 8-bit field that is unused for now.  The value MUST be
      initialized to 0 by the sender and MUST be ignored by the
      receiver.

NEW:

     An 8-bit field that is unused at the time of writing this draft. The value MUST be
      initialized to 0 by the sender and MUST be ignored by the
      receiver.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 8 Dec 2015 23:06:37 +0000

Hi Stephen,

Thank you for your review. We probably addressed most of these issues as part of addressing Alissa's comments as there is overlap. Any case, please let us know if you are not happy with the changes.

(1) Did the DHC working group consider how this information,
when sent without adequate protection between relay and dhcp
server, could help in pervasive monitoring? If so, what was the
conclusion reached? We have seen http header field information
sent between infrastructure nodes being intercepted for that
purpose, so this has to be similarly at risk.  If the answer is
that this is only to be used within a single network operator's
setup (or a roaming arrangement) then that needs to be
justified (as practical) and, if it can be justified (I'm not
sure tbh), also made explicit.

[Sri] I believe this issue is now resolved after discussions with Alissa Cooper and the newly agreed text that introduces the "same operator" assumption.

(2) I had a DISCUSS on the draft that became rfc 6757 about
protection of this kind of data. In that context I think I was
assured that everything (in PMIPv6) was IPsec protected so it
was fine.  Why, in what we now know is a more threated
environment, is it ok to now have weaker protection when I was
assured then that IPsec was in fact quite usable in PMIPv6? I
think you maybe need to put in a MUST use IPsec requirement for
this to be as safe.

[Sri] No, its not. We are still identifying the information that is at risk in certain operating environments. We are also listing the tools that operator has their disposal as per the below text. The question is that determination on when the information is at risk, if its an operator call, or IETF call. I'm OK, but I will let Bernie and other DHCP experts comment on this MUST requirement.

   "In deployments where this information is considered secure
   and when such threat cannot be mitigated using IPsec [RFC4301] or
   other security protocols, then the administrators have to consider
   disabling the capability specified in this document on the DHCP
   entities."

(3) section 7: MAY store - this is possibly sensitive
information so you ought say that it SHOULD NOT be stored
unless needed, and if stored, SHOULD be deleted as soon as
possible. Storing sensitive information when not needed just
shouldn't be considered acceptable anymore I think - is that
reasonable?

[Sri] Ok.

Looking at RFC 7268, SSID (Network-Id-Name attribute) can be present in accounting records. So, this information is stored by network functions.

  *

I (strongly) support Alissa's DISCUSS and will be interested
in watching how that is resolved. Some of my DISCUSS points do
overlap though so from my POV feel free to mix'n'match the
discussions. Or to process first one then the other, whatever
you think is best.

[Sri] We resolved it; hope you are OK with the conclusion.

- RFC6757 defines exactly this for PMIPv6. That implies that
PMIPv6 should not be used to illustrate or motivate this, as
that problem is solved. Perhaps you would be better off if you
limited the scope of this to be used for networks that are some
kind of extension to PMIPv6 only? (You'd need to define what
kind I think.)

[Sri] I believe with all the text around "single operator", "IPsec" and other assumptions, I think we have resolved this issue.

Thanks for the reviews.

Regards
Sri

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 8 Dec 2015 23:53:06 +0000

Hi Benoit,

Thank you for your review. Please see inline.  Please let us know if you are OK with the suggested text for resolving the issues.

I would like to discuss the following point.
You define the "Vendor ID" and then the Operator Enterprise ID. Why don't you reuse the RFC 6757 Operator-Identifier?

Sri] I believe we made a mistake here. Thanks for catching this.  There is just Operator Id  and not vendor id.

OLD:

   Vendor ID

      The Vendor ID is the SMI Network Management Private Enterprise
      Code of the IANA-maintained Private Enterprise Numbers registry
      [SMI].

NEW:

   Operator-Identifier

      The Operator-Identifier is the Structure of Management Information
      (SMI) Network Management Private Enterprise Code of the IANA-
      maintained "Private Enterprise Numbers" registry [SMI<https://tools.ietf.org/html/rfc6757#ref-SMI>].  It
      identifies the operator running the network attached to a specific
      interface of the mobile access gateway.

OLD:

   Operator Enterprise ID
      The operator's Vendor ID (as described in Section 3) is Private
      Enterprise Number (PEN) [SMI].

NEW:

   Operator Enterprise ID
      The operator's Enterprise ID (as described in Section 3) is a Private
      Enterprise Number (PEN) [SMI].

I'm been confused by the following text and the figure 1, as it doesn't mention the dhcp relay-agents and servers

   The PMIPv6 extension as specified in [RFC6757] defines PMIPv6 options
   to carry access network identifiers in PMIPv6 signaling from Mobile
   Access Gateway (MAG) to LMA.  MAG can learn this information from
   DHCP options as inserted by DHCP Relay agent before MAG.  If MAG
   relays DHCP messages to LMA as specified in [RFC5844] this
   information can be inserted by MAG towards LMA in the forwarded DHCP
   messages.

   Figure 1 illustrates an example Proxy Mobile IPv6 deployment where
   Access Points (AP) acting as a DHCP relay agent inserts access
   network identifiers in DHCP messages relayed from the connected
   clients.  The mobile access gateway learns this information over DHCP
   and delivers the information elements related to the access network
   to the local mobility anchor over Proxy Mobile IPv6 signaling
   messages.  In this example, the additional information could comprise
   the SSID of the used IEEE 802.11 network and the identities of the
   operators running the IEEE 802.11 access network infrastructure.

Discussing with Sri and Mark, I discovered my source of confusion.
There are two cases, as discussed in https://tools.ietf.org/html/rfc5844#section-3.4:

   This specification supports the following two DHCP deployment
   configurations.

   o  DHCP relay agent co-located with the mobile access gateway.

   o  DHCP server co-located in the mobile access gateway.

Either the DHCP server is on the LMA, and the MAG just forwards the DHCP message to the LMA. The LMA receives the
access network identifiers from DHCP (the MAG just forwards the DHCP message, modified by the AP)
Or the DHCP server is on the MAG, and then the PMIPv6 extension carries the access network identifiers to the LMA, learned with DHCP from the AP.
However, in the context of WLAN-EPC interworking, the only supported mode is DHCP server collocation on the MAG. Hence the figure 1 focuses on this case.

The text and the figure should be improved IMO.

[Sri] Sure. We can identify the DHCP Relay function on the AP and the DHCP Server on the MAG.

OLD:

   Figure 1 illustrates an example Proxy Mobile IPv6 deployment where
   Access Points (AP) acting as a DHCP relay agent inserts access
   network identifiers in DHCP messages relayed from the connected
   clients.  The mobile access gateway learns this information over DHCP
   and delivers the information elements related to the access network
   to the local mobility anchor over Proxy Mobile IPv6 signaling
   messages.  In this example, the additional information could comprise
   the SSID of the used IEEE 802.11 network and the identities of the
   operators running the IEEE 802.11 access network infrastructure.

NEW:

   Figure 1 illustrates an example Proxy Mobile IPv6 deployment where
   Access Points (AP) acting as a DHCP relay agent inserts access
   network identifiers in DHCP messages relayed from the connected
   clients.  The DHCP Server collocated on the mobile access gateway learns this information over DHCP
   and delivers the information elements related to the access network
   to the local mobility anchor over Proxy Mobile IPv6 signaling
   messages.  In this example, the additional information could comprise
   the SSID of the used IEEE 802.11 network and the identities of the
   operators running the IEEE 802.11 access network infrastructure.

- I agree with Al Morton, in his OPS-DIR review.
This draft specifies the optional capability in DHCP to identify
access network ID and operator ID for the possible application of policy
on operator-specific handling, traffic management, or differentiated
services. Often these are carefully planned and controlled networking
capabilities, so some form of ID integrity protection would be welcome.
Thus, it's worrisome when the authors remind us in the Security
Considerations section (9):

[Sri] Ok.

OLD:

   DHCP server administrators are
   strongly advised to configure DHCP servers that use this option to
   communicate with their relay agents using IPsec, as described in
   Section 21.1 of [RFC3315].

NEW:

   DHCP server administrators are
   strongly advised to configure DHCP servers that use this option to
   communicate with their relay agents using IPsec security
   association(s) offering integrity protection, as described in
   Section 21.1 of [RFC3315].

   ...DHCP itself is inherently unsecure and
   thus link-layer confidentiality and integrity protection should be
   employed to reduce the risk of disclosure and tampering.

maybe  s/should/SHOULD/ ? or stronger?  Other solutions or explanation welcome.

[Sri] Ok.

DHCP itself is inherently insecure and thus link-layer confidentiality and integrity protection should be employed to reduce the risk of disclosure and tampering.

NEW:

DHCP itself is inherently insecure and thus link-layer confidentiality and integrity protection SHOULD be employed to reduce the risk of disclosure and tampering.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 10 Dec 2015 08:53:32 +0100

Hi Sri,
> Hi Benoit,
>
> Thank you for your review. Please see inline.  Please let us know if 
> you are OK with the suggested text for resolving the issues.
>
>
>
>
> Vendor ID The Vendor ID is the SMI Network Management Private 
> Enterprise Code of the IANA-maintained Private Enterprise Numbers 
> registry [SMI].
> NEW:
> Operator-Identifier The Operator-Identifier is the Structure of 
> Management Information (SMI) Network Management Private Enterprise 
> Code of the IANA- maintained "Private Enterprise Numbers" registry 
> [SMI <https://tools.ietf.org/html/rfc6757#ref-SMI>]. It identifies the 
> operator running the network attached to a specific interface of the 
> mobile access gateway.
> OLD:
> Operator Enterprise ID The operator's Vendor ID (as described in 
> Section 3) is Private Enterprise Number (PEN) [SMI].
> NEW:
> Operator Enterprise ID The operator's Enterprise ID (as described in 
> Section 3) is a Private Enterprise Number (PEN) [SMI].
Ack.
Make sure to mention that the definition is identical to RFC 6757

Fine with the rest of the comments.

Regards, Benoit
> There are two cases, as discussed inhttps://tools.ietf.org/html/rfc5844#section-3.4:
>
> Access Points (AP) acting as a DHCP relay agent inserts access network 
> identifiers in DHCP messages relayed from the connected clients. The 
> mobile access gateway learns this information over DHCP and delivers 
> the information elements related to the access network to the local 
> mobility anchor over Proxy Mobile IPv6 signaling messages. In this 
> example, the additional information could comprise the SSID of the 
> used IEEE 802.11 network and the identities of the operators running 
> the IEEE 802.11 access network infrastructure.
>
> NEW:
> Access Points (AP) acting as a DHCP relay agent inserts access network 
> identifiers in DHCP messages relayed from the connected clients. The 
> DHCP Server collocated on the mobile access gateway learns this 
> information over DHCP and delivers the information elements related to 
> the access network to the local mobility anchor over Proxy Mobile IPv6 
> signaling messages. In this example, the additional information could 
> comprise the SSID of the used IEEE 802.11 network and the identities 
> of the operators running the IEEE 802.11 access network infrastructure.
>
>
> DHCP server administrators are strongly advised to configure DHCP 
> servers that use this option to communicate with their relay agents 
> using IPsec, as described in Section 21.1 of [RFC3315].
> NEW:
> DHCP server administrators are strongly advised to configure DHCP 
> servers that use this option to communicate with their relay agents 
> using IPsec security association(s) offering integrity protection, as 
> described in Section 21.1 of [RFC3315].
> DHCP itself is inherently insecure and thus link-layer confidentiality 
> and integrity protection should be employed to reduce the risk of 
> disclosure and tampering.
> NEW:
> DHCP itself is inherently insecure and thus link-layer confidentiality 
> and integrity protection SHOULD be employed to reduce the risk of 
> disclosure and tampering.
>
>
>
> .

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 10 Dec 2015 09:48:42 +0000

Hi Benoit,

Thanks.

Regards
Sri
PS: Apologies – Wrong subject line.

From: "Benoit Claise (bclaise)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, December 9, 2015 11:53 PM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: "Bernie Volz (volz)" <[email-masked]<mailto:[email-masked]>>, IESG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Brian Haberman <[email-masked]<mailto:[email-masked]>>, "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Ben Campbell's Discuss on draft-ietf-dhc-access-network-identifier-10: (with DISCUSS)

Hi Sri,
Hi Benoit,

OLD:

   Vendor ID

NEW:

   Operator-Identifier

OLD:

   Operator Enterprise ID

NEW:

   Operator Enterprise ID

Ack.

Regards, Benoit

OLD:

NEW:

[Sri] Ok.

OLD:

NEW:

[Sri] Ok.

NEW:

.

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 14 Dec 2015 15:48:44 -0600

Hi, thanks for the response. More comments inline. I removed sections 
that don't seem to need further discussion.

Thanks!

Ben.

On 8 Dec 2015, at 16:34, Sri Gundavelli (sgundave) wrote:

> Hi  Ben,
> -- 4.3.2
>
> The name of an 802.11 access point can imply the users location with a 
> fair bit of precision, making it effectively count as location data. 
> The draft needs  more discussion of the privacy implications of that.
>
>

I saw proposed text clarifying the scope and making some of the security 
guidance normative. I support that in general, but I don't think it 
solves the specific privacy issue around 802.11 access point names. Did 
that discussion involve text describing the privacy implications of  
that? If so, I missed it. In any case, it would be helpful to see the 
new text in the context of a draft update.

>
>
> -- 6:
> This section seems underspecified. There seems to be a missing 
> discussion about interdependencies among options. For example, For 
> example, network name is meaningless without the technology type. What 
> is the minimum needed to be coherent?
>
>
> [Sri] Agree. Its mainly the ATT that must be present with certain 
> options. In each of those option section, we will state this 
> explicitly.

That will probably address this issue. Do you have proposed text (or a 
revised I-D)?

[...]
>
> -- 4.3.1:
> This mentions how to interpret the network name for 802.11, 3GPP, and 
> 3GPP2 networks. Is the use of this sub-option limited to those 
> technology types? How should it be interpreted for other types?
>
>
> [Sri] This covers all the currently defined access technologies in ATT 
> registry (CDMA, GSM and WLAN based access networks). For new ATT 
> values that are yet to be defined the network name has to be 
> interpreted as defined in the document that introduces those ATT 
> values.

Did I miss guidance to the expert reviewer for that registry that these 
things need to be defined? Does RFC 5213 have such guidance? That is, if 
someone registers a new ATT value for use with RFC 5213, would they know 
they need to define how to interpret the network name?

[...]
>
> -- 7, first sentence:
> This seems to be making a MUST level requirement for servers that do 
> not implement this draft. Is this a new MUST, or is already specified 
> elsewhere? (If the latter, then citation?)
>
>
> it MUST ignore the DHCPv4 Access Network Identifier option received; 
> this is as specified in the base documents RFC2131 and RFC3315"

I suggest dropping the 2119 MUST. For example:

"RFCs 2131 and 3315 require that the DHCPv4 server ignore the DHCPv4 
Access Network Identifier option if it does not understand the option 
defined in Section 4"

[...]