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

"Stephen Farrell" <stephen.farrell@cs.tcd.ie> Tue, 15 September 2015 16:14 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 6ED631A1BAC; Tue, 15 Sep 2015 09:14:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id NIRPrDfFmOND; Tue, 15 Sep 2015 09:14:44 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D001A00D0; Tue, 15 Sep 2015 09:14:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.4.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150915161444.1119.66773.idtracker@ietfa.amsl.com>
Date: Tue, 15 Sep 2015 09:14:44 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/ufI0ZcRqo_cxuVP8HV9vpo0Mips>
Cc: 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] Stephen Farrell'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: Tue, 15 Sep 2015 16:14:46 -0000

Stephen Farrell 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:


(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


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