Access-Network-Identifier Option in DHCP
draft-ietf-dhc-access-network-identifier-13

[Ballot comment]

I look forward to the planned discussion to see if we can further improve
the privacy and security properties of DHCP. Thanks for being willing
to have that discussion.

OLD DISCUSS TEXT BELOW:

(Sent mail 2016-01-10, checking on change vs. discuss)

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

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

(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?

OLD COMMENT TEXT BELOW

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

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

[Ballot discuss]

Thanks for the changes made in response to my and, in particular,
Alissa's discuss ballots.

Having looked back at the email thread I don't believe I got any
answer to the question "Did the DHC working group consider how
this information, when sent without adequate protection between
relay and dhcp server, could help in pervasive monitoring?"

I think the focus of the discussion has been on the applicability of
this being limited to "typically" one operator's network, which
does of course mean that the traffic is less at risk than had it
transited many networks. However, we have seen (Belgacom) that
the PM threat also applies within a single operator's network.
So I am still interested in the answer to the above question.

The DHC WG might consider this threat and still conclude that
a SHOULD statement about IPsec is the best we can do in practice,
but that isn't clear to me at present, so I'd still like to chat about
the PM threat. (Note: it's the WG's consideration of the threat
I'd like to chat about, not only about the potential of IPsec to
mitigate that threat.)

[Ballot comment]



OLD DISCUSS TEXT BELOW:

(Sent mail 2016-01-10, checking on change vs. discuss)

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

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

(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?

OLD COMMENT TEXT BELOW

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

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

[Ballot comment]
Thanks for addressing my discuss point. I've cleared the discuss.
--------------


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

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

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

-- 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?)

Editorial:

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

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

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

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

[Ballot discuss]
MY PREVIOUS DISCUSS:
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?

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].  It
      identifies the operator running the network attached to a specific
      interface of the mobile access gateway.

MY NEW DISCUSS:
I see that you have now used the Operator-Identier. Good.
However, it's not fully inline with the RFC 6757 definition. Why?
Why not refer to the RFC 6757 definition, and include it here for the convenience of the readers.
Also, what is the Enterprise ID  (two instances of this)?
  Operator Enterprise ID
      The operator's Enterprise ID (as described in Section 3) is
      Private Enterprise Number (PEN)

[Ballot comment]
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.

[Ballot discuss]

(Sent mail 2016-01-10, checking on change vs. discuss)

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

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

(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?

[Ballot comment]
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.

- 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):

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

[Ballot discuss]
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?

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].  It
      identifies the operator running the network attached to a specific
      interface of the mobile access gateway.

[Ballot comment]
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.

Document Writeup, template from IESG area on ietf.org, dated 11 March 2015.

draft-access-network-identifier-06 write-up

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper type
of RFC? Is this type of RFC indicated in the title page header?

  Proposed standard. This document specifies new access network
  identifier options and sub-options and their correspondent
  client/server behaviors in DHCPv4 and DHCPv6. The intended
  type is indicated in the document header.
 
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent examples
can be found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary:
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

  This document define new DHCPv4 and DHCPv6 options for access
  network identification that is added by Client or Relay agent
  in the DHCPv4 or DHCPv6 messages towards the server.  This
  information can be used to provide differentiated services
  and policing of traffic based on the access network to which
  a client is attached.

Working Group Summary:
Was there anything in WG process that is worth noting? For example,
was there controversy about particular points or were there decisions
where the consensus was particularly rough?

  This document was called draft-bhandari-dhc-access-network-identifier
  prior to its adoption. There was unanimous support for it in favor of
  adoption and none against), so this document was adopted in May
  2013. There was interest in this work posts since its adoption.
  There was never any opposition for this work.
 
  This document went through a relevant long document development
  period (10 months for individual document period, 21 month for WG
  document period) due to the authors lack of the DHC background
  expertise. The DHC expert, Bernie Volz, has joint in latest
  version so that the maturity of this document can be reached.

Document Quality:
Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was
a MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

  This document went through multiple reviews by multiple WG
  participants. The options, client's and server's behaviors are
  clearly defined. I'm not aware of any existing implementations.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Sheng Jiang is the document shepherd.
  Brian Haberman is the responsible AD.
 
(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for publication,
please explain why the document is being forwarded to the IESG.

  I reviewed this document twice from only the DHC perspective for
  -02 and -05 versions (and had other minor comments in between):
 
  http://www.ietf.org/mail-archive/web/dhcwg/current/msg15464.html
  http://www.ietf.org/mail-archive/web/dhcwg/current/msg16083.html 
 
  The issues raised in my reviews were promptly addressed by authors
  in -06 version along with the comments from other DHC WG members. This
  document is ready for publication in my opinion.
 
(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

  No.
 
(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

  No. This document has been carefully reviewed by DHC WG.
 
(6) Describe any specific concerns or issues that the Document Shepherd has with
this document that the Responsible Area Director and/or the IESG should be aware
of? For example, perhaps he or she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it. In any event,
if the WG has discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

  There are no outstanding issues.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

  Yes. The authors, Shwetha Bhandari, Sri Gundavelli, Mark Grayson,
  Bernie Volz and Jouni Korhonen confirmed that any and all appropriate
  IPR disclosures required for full conformance with the provisions of
  BCP 78 and BCP 79 have already been filed.
 
(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

  No.
 
(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?

  There was broad support for this document. It was reviewed by active WG
  participants. All changes were mostly minor.
 
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

  No. There was unanimous support for this work and nobody raised any objections.
 
(11) Identify any ID nits the Document Shepherd has found in this document. (See
http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be thorough.

  This document is now ID nits clean.
 
(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, media type, and URI type reviews.

  No MIB Doctor, media type, URI type or similar apply to this
  document.
 
(13) Have all references within this document been identified as either
normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?

  No. All normative references are published RFCs.
 
(15) Are there downward normative references references (see RFC 3967)? If so,
list these downward references to support the Area Director in the Last Call
procedure.

  No. There are no downard normative references.

(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.

  No. This document does not update any existing RFCs. This draft
  defines new options and extends, but not updates the base (RFC3315)
  DHCPv6 specification.

(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm
that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial contents for the
registry, that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC 5226).

  IANA is asked to assign 6 option codes for OPTION_ANI_ATT,
  OPTION_ANI_NETWORK_NAME, OPTION_ANI_AP_NAME, OPTION_ANI_AP_BSSID,
  OPTION_ANI_OPERATOR_ID and OPTION_ANI_OPERATOR_REALM; 6 sub-option
  codes of DHCP Relay Agent Sub-Option for Access Technology Type
  Sub-option, Access Network Name Sub-option, Access Point Name
  Sub-option, Access Point BSSID Sub-option, Operator-Identifier
  Sub-option and Operator-Realm Sub-option.
 
  All the necessary information is in the IANA considerations document. It is
  clear enough that the IANA will be able to implement it.
 
(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

  No such registry is requested in this document.
 
(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.

  There are no such parts to the document.

[Ballot discuss]
-- 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.

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

[Ballot comment]
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?

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

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

-- 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?)

Editorial:

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

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

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

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

[Ballot comment]

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

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

[Ballot discuss]


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

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

(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?

[Ballot comment]

- 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 the the other, whatever
you think is best.

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

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

[Ballot comment]
Thanks for addressing the questions raised int he SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg05811.html

There was mention of IPsec use when relaying this information and then a question from Stephen if this was actually used.  I'm guessing the answer is no since the protection is not mentioned in the draft, but wanted to confirm as that wasn't clear to me from the email thread.

Additionally, is there any advice given (possibly in other related specs, but I suspect having it here for the new values could be helpful) to assign obscure names to several of the values like the Access Point Identity (Name, BSSID) and Operator Id/Realm?  Obscuring only helps a little, but having names that don't necessarily advertise the usage of the associated network might be helpful.  Thanks.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dhc-access-network-identifier-08.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA has questions about the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the DHCP Relay Agent Sub-Option Codes subregistry of the Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry located at:

https://www.iana.org/assignments/bootp-dhcp-parameters/

six new sub-option codes are to be registered as follows:

Code: [ TBD-at-registration ]
Sub-Option Description: Access Technology Type Sub-option
Reference: [ RFC-to-be ]

Code: [ TBD-at-registration ]
Sub-Option Description: Access Network Name Sub-option
Reference: [ RFC-to-be ]

Code: [ TBD-at-registration ]
Sub-Option Description: Access Point Name Sub-option
Reference: [ RFC-to-be ]

Code: [ TBD-at-registration ]
Sub-Option Description: Access Point BSSID Sub-option
Reference: [ RFC-to-be ]

Code: [ TBD-at-registration ]
Sub-Option Description: Operator-Identifier Sub-option
Reference: [ RFC-to-be ]

Code: [ TBD-at-registration ]
Sub-Option Description: Operator-Realm Sub-option
Reference: [ RFC-to-be ]

NOTE:
Please change the following URL in the IANA Considerations section:

OLD:


NEW:


This will ensure the URL will always work and point to the most current
version/extension.

Second, in the Option Codes subregistry for DHCPv6 in the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry located at:

https://www.iana.org/assignments/dhcpv6-parameters/

six new option codes are to be registered as follows:

Value: [ TBD-at-registration ]
Description: OPTION_ANI_ATT
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
Description: OPTION_ANI_NETWORK_NAME
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
Description: OPTION_ANI_AP_NAME
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
Description: OPTION_ANI_AP_BSSID
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
Description: OPTION_ANI_OPERATOR_ID
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
Description: OPTION_ANI_OPERATOR_REALM
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

NOTE:
Please change the following URL in the IANA Considerations section:

OLD:
, as specified in [RFC3315]

NEW:
, as specified in [RFC3315]

This will ensure the URL will always work and point to the most current
version/extension.

IANA understands that these two actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Access Network Identifier Option in DHCP) to Proposed Standard


The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'Access Network Identifier Option in DHCP'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-06-09. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies the format and mechanism that is to be used
  for encoding access network identifiers in DHCPv4 and DHCPv6 messages
  by defining new access network identifier options and sub-options.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dhc-access-network-identifier/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dhc-access-network-identifier/ballot/


No IPR declarations have been submitted directly on this I-D.

Folks, the authors of draft-ietf-dhc-access-network-identifier (http://tools.ietf.org/html/draft-ietf-dhc-access-network-identifier-02)
feel it's ready for work group last call. Please review this draft and indicate whether or not you feel it is ready to be published.

At the time of this writing, there is no IPR reported against this draft. Please see http://www.ietf.org/mail-archive/web/dhcwg/current/msg14143.html for a reminder regarding IPR disclosure requirements.

Tomek and I will evaluate consensus after April 27, 2014.

Thanks,
Bernie & Tomek