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

<mohamed.boucadair@orange.com> Thu, 13 August 2015 08:50 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 1F48B1B3789; Thu, 13 Aug 2015 01:50:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 nkj2MsJ-MW7q; Thu, 13 Aug 2015 01:50:07 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8CF1B3788; Thu, 13 Aug 2015 01:50:06 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 65D782DC112; Thu, 13 Aug 2015 10:50:05 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.31]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 430224C070; Thu, 13 Aug 2015 10:50:05 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0248.002; Thu, 13 Aug 2015 10:50:05 +0200
From: <mohamed.boucadair@orange.com>
To: Dan Harkins <dharkins@lounge.org>
Thread-Topic: [secdir] secdir review of draft-vinapamula-softwire-dslite-prefix-binding-07
Thread-Index: AQHQ1MHDiCFdgijnkUqqYb779kpt754Jn69g
Date: Thu, 13 Aug 2015 08:50:04 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300537888D@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> <c9be7fcc727dce10f19acfca3e6d8371.squirrel@www.trepanning.net>
In-Reply-To: <c9be7fcc727dce10f19acfca3e6d8371.squirrel@www.trepanning.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.8.13.82715
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/L_V6R_LUrGkVJ076NLf6rvVz0dU>
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: Thu, 13 Aug 2015 08:50:10 -0000

Hi Dan,

Great!

A new version with the proposed changes is available online: https://datatracker.ietf.org/doc/draft-vinapamula-softwire-dslite-prefix-binding/ 

A diff to track the changes is available at: https://www.ietf.org/rfcdiff?url2=draft-vinapamula-softwire-dslite-prefix-binding-09

Many thanks for the review. 

Cheers,
Med 

> -----Message d'origine-----
> De : Dan Harkins [mailto:dharkins@lounge.org]
> Envoyé : mercredi 12 août 2015 07:43
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Daniel Kahn Gillmor; 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
> 
> 
> 
> 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.
>