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

["Sri Gundavelli (sgundave)" <[e-mail]>]

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.