IETF Logo Mail Archive

Re: [Dots] New Version Notification for draft-boucadair-dots-dhcp-00.txt

<mohamed.boucadair@orange.com> Mon, 10 April 2017 06:37 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CF31205D3 for <dots@ietfa.amsl.com>; Sun, 9 Apr 2017 23:37:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 yRy9XJojLM7i for <dots@ietfa.amsl.com>; Sun, 9 Apr 2017 23:37:04 -0700 (PDT)
Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FCDE1270A3 for <dots@ietf.org>; Sun, 9 Apr 2017 23:37:03 -0700 (PDT)
Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id CC366402A6; Mon, 10 Apr 2017 08:37:01 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 976BD1A007A; Mon, 10 Apr 2017 08:37:01 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0319.002; Mon, 10 Apr 2017 08:37:01 +0200
From: mohamed.boucadair@orange.com
To: Dave Dolson <ddolson@sandvine.com>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: New Version Notification for draft-boucadair-dots-dhcp-00.txt
Thread-Index: AQHSrtDKL0G3kuXF+EKjSheziLtndaG4ReAAgAIUneCAA8fgwA==
Date: Mon, 10 Apr 2017 06:37:00 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E4AE54@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <149148149033.22052.2740593195904388324.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933009E48A7D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <E8355113905631478EFF04F5AA706E987057E4B0@wtl-exchp-1.sandvine.com>
In-Reply-To: <E8355113905631478EFF04F5AA706E987057E4B0@wtl-exchp-1.sandvine.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/Q5B8uIfuMiZvBLTtvjyAKuiKJJQ>
Subject: Re: [Dots] New Version Notification for draft-boucadair-dots-dhcp-00.txt
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Apr 2017 06:37:06 -0000

Hi Dave, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Dave Dolson [mailto:ddolson@sandvine.com]
> Envoyé : vendredi 7 avril 2017 22:21
> À : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
> Objet : RE: New Version Notification for draft-boucadair-dots-dhcp-00.txt
> 
> Med,
> How do you think dots security should work for clients provisioned via
> DHCP?

[Med] A simple approach is to leverage on security features already supported by CPEs to provide some sensitive services with similar requirements. A typical example is a SIP agent embedded on the CPE. For deployments that require DTLS mutual authentication, the DHCP option can be designed to return an authentication domain name. Of course, this model assumes that DHCP server is trusted. 

> It seems like we are deciding on a (D)TLS model. How would the keys be
> provisioned?

[Med] For the CPE-based model I'm interested in, security keys can be provisioning following current practices for similar services and deployments. In such deployments, IP-specific configuration parameters are provided using DHCP while service-specific parameters are passed using channels such as TR-69 and its extensions (see for example, TR-104 for the VoIP case (https://www.broadband-forum.org/technical/download/TR-104_Issue-2.pdf)). 

FWIW, you may refer to https://www.broadband-forum.org/technical/download/TR-181_Issue-2_Amendment-11.pdf (starting from page 133) to see a recent feature that was added (PCP client) and how a PCP server is configured to the CPE. That model assumes that the server can be provisioned by means of DHCP, but other parameters such as filtering rules are may be provisioned via TR-69. 

> 
> -Dave
> 
> 
> -----Original Message-----
> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of
> mohamed.boucadair@orange.com
> Sent: Thursday, April 6, 2017 8:43 AM
> To: dots@ietf.org
> Subject: [Dots] TR: New Version Notification for draft-boucadair-dots-
> dhcp-00.txt
> 
> Dear all,
> 
> Given that:
> * means to provision a DOTS client with the address(es) of its DOTS server
> are needed,
> * many of the use cases discussed in draft-ietf-dots-use-cases rely upon a
> CPE,
> * reserving anycast-addresses for DOTS may be not be justified (see the
> problems discussed in Section 3.2.4.1 of draft-ietf-dots-architecture)
> 
> Leveraging on existing provisioning tools is much more pragmatic. This
> draft specifies DHCP options to discover a list of IP addresses of a DOTS
> server.
> 
> Comments, questions and suggestions are more than welcome.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Envoyé
> > : jeudi 6 avril 2017 14:25 À : BOUCADAIR Mohamed IMT/OLN Objet : New
> > Version Notification for draft-boucadair-dots-dhcp-00.txt
> >
> >
> > A new version of I-D, draft-boucadair-dots-dhcp-00.txt has been
> > successfully submitted by Mohamed Boucadair and posted to the IETF
> > repository.
> >
> > Name:		draft-boucadair-dots-dhcp
> > Revision:	00
> > Title:		DHCP Options for DDoS Open Threat Signaling (DOTS)
> > Document date:	2017-04-06
> > Group:		Individual Submission
> > Pages:		10
> > URL:            https://www.ietf.org/internet-drafts/draft-boucadair-
> dots-
> > dhcp-00.txt
> > Status:         https://datatracker.ietf.org/doc/draft-boucadair-dots-
> > dhcp/
> > Htmlized:       https://tools.ietf.org/html/draft-boucadair-dots-dhcp-00
> > Htmlized:       https://datatracker.ietf.org/doc/html/draft-boucadair-
> > dots-dhcp-00
> >
> >
> > Abstract:
> >    It may not be possible for a network to determine the cause for an
> >    attack, but instead just realize that some resources seem to be under
> >    attack.  To fill that gap, DDoS Open Threat Signaling (DOTS) allows a
> >    DOTS client to inform a DOTS server that the network is under a
> >    potential attack so that appropriate mitigation actions are
> >    undertaken.
> >
> >    This document specifies DHCP (IPv4 and IPv6) options to configure
> >    hosts with DOTS servers.
> >
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at
> > tools.ietf.org.
> >
> > The IETF Secretariat
> 
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots

v2.23.0 | Report a Bug | By Email