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

[Benoit Claise <[e-mail]>]

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.
>
>
>
>
> 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].
Ack.
Make sure to mention that the definition is identical to RFC 6757

Fine with the rest of the comments.

Regards, Benoit
>
> 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 inhttps://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.
>
>
>
> .