[dhcwg] Benoit Claise's Discuss on draft-ietf-dhc-access-network-identifier-10: (with DISCUSS and COMMENT)

"Benoit Claise" <bclaise@cisco.com> Thu, 17 September 2015 10:47 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885A61B2CDB; Thu, 17 Sep 2015 03:47:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSr5peitOmUz; Thu, 17 Sep 2015 03:47:39 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1BAE1B2CBA; Thu, 17 Sep 2015 03:47:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benoit Claise <bclaise@cisco.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.4.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150917104739.20640.78892.idtracker@ietfa.amsl.com>
Date: Thu, 17 Sep 2015 03:47:39 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/PPTlefjM2p-Cr_lXCGtzcxTx3mA>
Cc: acmorton@att.com, dhc-chairs@ietf.org, draft-ietf-dhc-access-network-identifier.shepherd@ietf.org, draft-ietf-dhc-access-network-identifier.ad@ietf.org, dhcwg@ietf.org, draft-ietf-dhc-access-network-identifier@ietf.org
Subject: [dhcwg] Benoit Claise's Discuss on draft-ietf-dhc-access-network-identifier-10: (with DISCUSS and COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Sep 2015 10:47:41 -0000

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


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