[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 [127.0.0.1]) 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-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 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: https://datatracker.ietf.org/doc/draft-ietf-dhc-access-network-identifier/ ---------------------------------------------------------------------- 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? ---------------------------------------------------------------------- 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.)
- [dhcwg] Stephen Farrell's Discuss on draft-ietf-d… Stephen Farrell