Re: [secdir] secdir review of draft-vinapamula-softwire-dslite-prefix-binding-07

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Fri, 07 August 2015 17:08 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A28E1A8823; Fri, 7 Aug 2015 10:08:20 -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 kLoUm5c9No6a; Fri, 7 Aug 2015 10:08:15 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id E486B1A1AB3; Fri, 7 Aug 2015 10:08:14 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id D8F4EF984; Fri, 7 Aug 2015 13:08:12 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 8FCB92012D; Fri, 7 Aug 2015 19:08:02 +0200 (CEST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Dan Harkins <dharkins@lounge.org>, iesg@ietf.org, secdir@ietf.org, draft-vinapamula-softwire-dslite-prefix-binding.all@tools.ietf.org
In-Reply-To: <d382a567352201437592e63f00180e93.squirrel@www.trepanning.net>
References: <d382a567352201437592e63f00180e93.squirrel@www.trepanning.net>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Fri, 07 Aug 2015 13:08:02 -0400
Message-ID: <87si7vt4b1.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/hL1xFJjwdT4P1CtHtErBzkv1rIY>
Subject: Re: [secdir] secdir review of draft-vinapamula-softwire-dslite-prefix-binding-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Aug 2015 17:08:20 -0000

On Fri 2015-08-07 12:13:30 -0400, Dan Harkins wrote:
>   [ draft-vinapamula-softwire-dslite-prefix-binding-07 ]

>   The main part of the solution is the introduction of a "Subscriber
> Mask" that allows a subscriber's CPE to be unambiguously identified
> when the mask is applied to a source IPv6 address. This identification
> allows for enforcement of per-subscriber policies even in the event of
> an address change.
>
>   The Security Considerations are sparse but address a potential
> DOS issue with a misbehaving user attempting to obtain additional
> resources by changing the address on its Basic Bridging Broadband
> element which seems to be the big issue here. All the other
> Security Considerations of DS-Lite apply and it refers to RFC 6333.

I'm a bit puzzled by this document.  The Introduction says:

   Note that in some deployments, CPE renumbering may be required to
   accommodate some privacy-related requirements to avoid assigning the
   same prefix to the same customer.  It is out of scope of this
   document to discuss such contexts.

And then there is no mention of this concern ever again.  There is no
Privacy Considerations section (though the Security Considerations
section does mention one privacy consideration unrelated to the concern
raised in the Introduction).

Is it acceptable to simply declare privacy considerations out-of-scope
for an I-D?  What are the "privacy-related requirements to avoid
assigning the same prefix to the same customer"?  in what deployments
should they be considered?

https://tools.ietf.org/html/rfc6973 says:

   The guidance provided here can and should be used to assess the
   privacy considerations of protocol, architectural, and operational
   specifications and to decide whether those considerations are to be
   documented in a stand-alone section, within the security
   considerations section, or throughout the document.

Why are we considering these concerns (as important today as ever) "out
of scope" for the draft-vinapamula-softwire-dslite-prefix-binding?  How
is a potential deployer of this situation supposed to know whether their
context is one of the contexts where they should avoid this draft?

To be clear: i'm not asking that the draft indicate how someone in one
of these privacy-sensitive contexts should approach enforcement of
per-subscriber policies.  But shouldn't the draft help a potential
deployer to decide whether they are in a context where they should or
should not apply the proposed standard?

       --dkg