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

"Dan Harkins" <dharkins@lounge.org> Wed, 12 August 2015 05:43 UTC

Return-Path: <dharkins@lounge.org>
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 204191B2B6F; Tue, 11 Aug 2015 22:43:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level:
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] 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 wK5jSlAdk9Hu; Tue, 11 Aug 2015 22:43:04 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7801B2B6C; Tue, 11 Aug 2015 22:43:04 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D2651A888132; Tue, 11 Aug 2015 22:43:03 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 11 Aug 2015 22:43:04 -0700 (PDT)
Message-ID: <c9be7fcc727dce10f19acfca3e6d8371.squirrel@www.trepanning.net>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93300537662F@OPEXCLILMA3.corporate.adroot .infra.ftgroup>
References: <d382a567352201437592e63f00180e93.squirrel@www.trepanning.net> <87si7vt4b1.fsf@alice.fifthhorseman.net> <8d0721840eaf232d895b0e2c8b50ead9.squirrel@www.trepanning.net> <787AE7BB302AE849A7480A190F8B93300537662F@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Date: Tue, 11 Aug 2015 22:43:04 -0700 (PDT)
From: "Dan Harkins" <dharkins@lounge.org>
To: mohamed.boucadair@orange.com
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/O1H6Xpa_Xa5V_ST8CBe0MW4uy_0>
Cc: "draft-vinapamula-softwire-dslite-prefix-binding.all@tools.ietf.org" <draft-vinapamula-softwire-dslite-prefix-binding.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
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: Wed, 12 Aug 2015 05:43:10 -0000


On Mon, August 10, 2015 1:37 am, mohamed.boucadair@orange.com wrote:
> Hi Dan, all,
>
> Please see inline.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Dan Harkins [mailto:dharkins@lounge.org]
>> Envoyé : samedi 8 août 2015 00:33
>> À : Daniel Kahn Gillmor
>> Cc : iesg@ietf.org; secdir@ietf.org; draft-vinapamula-softwire-dslite-
>> prefix-binding.all@tools.ietf.org
>> Objet : Re: [secdir] secdir review of draft-vinapamula-softwire-dslite-
>> prefix-binding-07
>>
[snip]
> I have no problem to add a privacy section. What about the following
> change:
>
> OLD:
>
> 5. Security Considerations
>
>    Security considerations related to DS-Lite are discussed in
>    [RFC6333].
>
>    Enforcing the recommendations documented in Section 4 together with
>    rate limiting softwires with new source IPv6 addresses from the same
>    prefix defend against DoS attacks that would result in varying the
>    B4's IPv6 address to exhaust AFTR resources.  A misbehaving CPE can
>    be blacklisted by enforcing appropriate policies based on the prefix
>    derived from the subscriber-mask.
>
>    Also, the recommendations in Section 4 ensure the traffic is
>    forwarded to a legitimate CPE.  If those recommendations are not
>    implemented, privacy concerns may arise (e.g., If an IPv6 prefix is
>    reassigned while mapping entries associated with that prefix are
>    still active in the AFTR, sensitive data that belong to a previous
>    prefix owner may be disclosed to the new prefix owner).
>
> NEW:
>
> 5.  Security Considerations
>
>    Security considerations related to DS-Lite are discussed in
>    [RFC6333].
>
>    Enforcing the recommendations documented in Section 4 together with
>    rate limiting softwires with new source IPv6 addresses from the same
>    prefix defend against DoS attacks that would result in varying the
>    B4's IPv6 address to exhaust AFTR resources.  A misbehaving CPE can
>    be blacklisted by enforcing appropriate policies based on the prefix
>    derived from the subscriber-mask.
>
> 6.  Privacy Considerations
>
>    A CPE connected to a DS-Lite network is identified by a set of
>    information that is specific to each network domain (e.g., service
>    credentials, device identifiers, etc.).  This document does not make
>    any assumption nor introduce new requirements on how such
>    identification is implemented network-wide.
>
>    This document adheres to Sections 6 and 8 of [RFC6333] for handling
>    IPv4-in-IPv6 packets and IPv4 translation operations.  In particular,
> this
>    document does not leak extra information in packets exiting a DS-Lite
>    network domain.
>
>    The recommendations in Section 4 (bullet 6, in particular) ensure the
>    traffic is forwarded to a legitimate CPE.  If those recommendations
>    are not implemented, privacy concerns may arise (e.g., If an IPv6
>    prefix is reassigned while mapping entries associated with that
>    prefix are still active in the AFTR, sensitive data that belong to a
>    previous prefix owner may be disclosed to the new prefix owner).
>
>    These recommendations do not interfere with privacy extensions for
>    generating IPv6 addresses (e.g., [RFC7217] or [RFC4941]).  These
>    recommendations allow a CPE to generate new IPv6 addresses with
>    privacy extensions without experiencing DS-Lite service degradation.
>
>    This document does not nullify the privacy effects of non-stable IPv6
>    prefixes.  Concretely, the subscriber-mask does not allow to identify
>    a CPE across renumbering (even within a DS-Lite network domain).
>    This document mitigates some of the undesired effects of reassigning
>    an IPv6 prefix to another CPE (e.g., update a rendezvous service,
>    remove stale mappings).
>
> Better?

  Yes! I like the mention of RFC 4941 too. That looks great.

  thanks,

  Dan.