I have reviewed the document and here are my comments (some cosmetic):

section 1: "on a specified port of th= e layer-2 device" =3D> "Secti= on 1: "Only those ports= to which a DHCPv6 server" =3D> "Only those ports to which a DHCPv6 server or relay" (relays should be allowed as well)
Section 3: not sure whether it is= relevant here, this is well-known and accepted terminology, I am always un= easy when information is duplicated as it is an open door for inconsistency
Section 3: should define what a 'DHCP shield device' is
Sect= ion 5: I do not agree with point 1) if the specific platform cannot handle = a long ext header chain, it should be allowed to drop the packet (the MUST = NOT should be SHOULD NOT or even a MAY =97 reversing the proposed policy). = Of course, such platforms cannot claim compatibility with DHCP-shield
Section 5: "SHOULD be logged in an implementation-specific = manner as security fault" =3D> "= security alert" or "security event"
Section 7= : the whole I-D is only handling the physical/wired switched case= while in the introduction it is stated to be 'broadcast network'. The secu= rity section and/or introduction should mention this.
Section 7: sh= ould also mention other DHCP related threats? Such as DoS attack against DH= CP servers? Amplification/reflection attacks? Of course, the mitigation tec= hniques are out of scope, but, I think that the threats should be mentioned=
Add a reference to SAVI-DHCP ?

Else, good document, pretty much like the well-known rogue DHCPv4

-=E9ric

From: Kiran Kumar Chittimaneni <= kk.chittimaneni@gmail.com&= gt;
Date: dimanche 11 mai 2014 05:12 To: "opsec@ietf.org" <ops= ec@ietf.org>
Subject: [OPSEC] Progressing draft-= ietf-opsec-dhcpv6-shield

Dear Opsec WG,

The WGLC for this draft technically ended last month with just one res= ponse received. Not enough to move forward.

The co-chairs chatted about this and noted that there was a lot more suppor= t for this doc during earlier stages. Given that, we'd like to give the WG = a bit more time to review this and extend the LC to the 24th of May. Ideall= y, we'd like to get at least two volunteers who could do a thorough review of this doc and post their comme= nts to the list.

= Th= e draft is available here: https://datatracker.iet= f.org/doc/draft-ietf-opsec-dhcpv6-shield/

Please read it now and report to the list whether you support publicat= ion or not. Insufficient responses will be taken as an indication of lack o= f interest and we'll stop from proceeding further.

Regards,

KK (as Opsec WG co-chair)

--_000_CF9691291AC75evynckeciscocom_-- From nobody Mon May 12 09:28:01 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994601A0753 for ; Mon, 12 May 2014 09:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 DUymhBzaOtJR for ; Mon, 12 May 2014 09:27:55 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.146]) by ietfa.amsl.com (Postfix) with ESMTP id 108371A0752 for ; Mon, 12 May 2014 09:27:54 -0700 (PDT) Received: from [85.158.136.3:56466] by server-10.bemta-5.messagelabs.com id 8B/99-27081-486F0735; Mon, 12 May 2014 16:27:48 +0000 X-Env-Sender: robert.sleigh@ee.co.uk X-Msg-Ref: server-13.tower-123.messagelabs.com!1399912061!30624153!1 X-Originating-IP: [193.36.79.211] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11286 invoked from network); 12 May 2014 16:27:41 -0000 Received: from unknown (HELO autechre) (193.36.79.211) by server-13.tower-123.messagelabs.com with SMTP; 12 May 2014 16:27:41 -0000 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by autechre with MailMarshal (v6, 8, 2, 9371) id ; Mon, 12 May 2014 17:28:39 +0100 Received: from UK31S005EXS06.EEAD.EEINT.CO.UK ([fe80::d851:f0e3:bba5:c1a0]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([fe80::5093:62a6:6ee3:7198%11]) with mapi id 14.02.0318.004; Mon, 12 May 2014 17:27:40 +0100 From: "Sleigh, Robert" To: "Eric Vyncke (evyncke)" , KK Chittimaneni , "opsec@ietf.org" Thread-Topic: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield Thread-Index: AQHPbMbU3Fibc0izRkWpMI7LA/NQHZs83IOAgAAklOA= Date: Mon, 12 May 2014 16:27:39 +0000 Message-ID: <679694A32AB94046931C676BEF4BA8B80C9257A7@UK31S005EXS06.EEAD.EEINT.CO.UK> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: multipart/alternative; boundary="_000_679694A32AB94046931C676BEF4BA8B80C9257A7UK31S005EXS06EE_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/EY_3fbLXm33714zKngqGuzKBe-o Cc: Fernando Gont Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 16:27:59 -0000 --_000_679694A32AB94046931C676BEF4BA8B80C9257A7UK31S005EXS06EE_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All This seems like a good step in the right direction, so I think this docum= ent has some value and should progress but... Unless this functionality is to be deployed on every switch port across a= n entire environment (which I grant you, it may well be), I think this wi= ll only remove the risk entirely if the client and the DHCPv6 server are = located on the same switch. It does not necessarily provide full protection for endusers in, for exam= ple, a routed DHCPv6 relay environment, and I think a similar issue arise= s in cascading L2 devices. In a routed DHCPv6 relay environment there will be an ingress port on the= =20enduser's local switch which will need to be enabled for receiving DHC= Pv6-server messages, but the switch will be reliant on the upstream devic= es to have filtered out rogue DHCPv6-server messages, as the local switch= =20has no way of determining which upstream DHCP-server messages are vali= d. Regards Bob 07958 318592 Life's for sharing... and what I like to share the most is a smile From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Eric Vyncke (evy= ncke) Sent: 12 May 2014 14:10 To: KK Chittimaneni; opsec@ietf.org Cc: Fernando Gont Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield KK, Gunter, Fernando & Will, I have reviewed the document and here are my comments (some cosmetic): =20 * section 1: "on a specified port of the layer-2 device" =3D> "on s= pecific port(s) of the layer-2 device" (plural form) =20 * Section 1: "Only those ports to which a DHCPv6 server" =3D> "Only= =20those ports to which a DHCPv6 server or relay" (relays should be allow= ed as well) =20 * Section 3: not sure whether it is relevant here, this is well-kno= wn and accepted terminology, I am always uneasy when information is dupli= cated as it is an open door for inconsistency =20 * Section 3: should define what a 'DHCP shield device' is =20 * Section 5: I do not agree with point 1) if the specific platform = cannot handle a long ext header chain, it should be allowed to drop the p= acket (the MUST NOT should be SHOULD NOT or even a MAY - reversing the pr= oposed policy). Of course, such platforms cannot claim compatibility with= =20DHCP-shield =20 * Section 5: "SHOULD be logged in an implementation-specific manner= =20as security fault" =3D> "security alert" or "security event" =20 * Section 7: the whole I-D is only handling the physical/wired swit= ched case while in the introduction it is stated to be 'broadcast network= '. The security section and/or introduction should mention this. =20 * Section 7: should also mention other DHCP related threats? Such a= s DoS attack against DHCP servers? Amplification/reflection attacks? Of c= ourse, the mitigation techniques are out of scope, but, I think that the = threats should be mentioned =20 * Add a reference to SAVI-DHCP ? Else, good document, pretty much like the well-known rogue DHCPv4 -=E9ric From: Kiran Kumar Chittimaneni > Date: dimanche 11 mai 2014 05:12 To: "opsec@ietf.org" > Subject: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield Dear Opsec WG, The WGLC for this draft technically ended last month with just one respon= se received. Not enough to move forward. The co-chairs chatted about this and noted that there was a lot more supp= ort for this doc during earlier stages. Given that, we'd like to give the= =20WG a bit more time to review this and extend the LC to the 24th of May= . Ideally, we'd like to get at least two volunteers who could do a thorou= gh review of this doc and post their comments to the list. The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-= opsec-dhcpv6-shield/ Please read it now and report to the list whether you support publication= =20or not. Insufficient responses will be taken as an indication of lack = of interest and we'll stop from proceeding further. Regards, KK (as Opsec WG co-chair) NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named p= erson(s). If you are not the intended recipient, notify the sender immed= iately, delete this email from your system and do not disclose or use for= =20any purpose. =20 =20 We may monitor all incoming and outgoing emails in line with current legi= slation. We have taken steps to ensure that this email and attachments ar= e free from any virus, but it remains your responsibility to ensure that = viruses do not adversely affect you.=20 EE Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfor= dshire, AL10 9BW --_000_679694A32AB94046931C676BEF4BA8B80C9257A7UK31S005EXS06EE_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =

Hi All

This seems like a goo= d step in the right direction, so I think this document has some value an= d should progress but…

Unless this functiona= lity is to be deployed on every switch port across an entire environment = (which I grant you, it may well be), I think this will only remove =20the risk entirely if the client and the DHCPv6 server are located on t= he same switch.

It does not necessari= ly provide full protection for endusers in, for example, a routed DHCPv6 = relay environment, and I think a similar issue arises in cascading =20L2 devices.

In a routed DHCPv6 re= lay environment there will be an ingress port on the enduser’s loca= l switch which will need to be enabled for receiving DHCPv6-server messag= es, =20but the switch will be reliant on the upstream devices to have filtere= d out rogue DHCPv6-server messages, as the local switch has no way of det= ermining which upstream DHCP-server messages are valid.

Regards

Bob

07958 318592

Life's for sharing... a= nd what I like to share the most is a smile

From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Eric Vyncke (evyncke)
Sent: 12 May 2014 14:10
To: KK Chittimaneni; opsec@ietf.org
Cc: Fernando Gont
Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield

KK, Gunter, Fernando &a= mp; Will,

I have reviewed the doc= ument and here are my comments (some cosmetic):

section 1: "on a specified port of the layer-2 device= " =3D> "on specific port(s) of the layer-2 device" (plu= ral form)
Se= ction 1: "Only those ports to which a DHCPv6 server" =3D= > "Only those ports to which a DHCPv6 server or relay" (rela= ys should be allowed as well)
Section 3: not sure whether it is relevant her= e, this is well-known and accepted terminology, I am always uneasy when i= nformation is duplicated as it is an open door for inconsistency
Section 3: should define what a 'DHCP shield device' is

Section 5: I do not agree with point 1) if the specific platform cannot h= andle a long ext header chain, it should be allowed to drop the packet (t= he MUST NOT should be SHOULD NOT or even a MAY — reversing the prop= osed policy). Of course, such platforms cannot =20claim compatibility with DHCP-shield

Section 5: "SHOULD be logged in an implementation-specific manner as= =20security fault" =3D> "security alert" or "secur= ity event"

Section 7: the whole I-D is only handling the physical/wired sw= itched case while in the introduction it is stated to be 'broadcast netwo= rk'. The security section and/or introduction should mention this.

Section 7: should also mention other DHCP related threats? Such as DoS at= tack against DHCP servers? Amplification/reflection attacks? Of course, t= he mitigation techniques are out of scope, but, I think that the threats = should be mentioned

Add a reference to SAVI-DHCP ?

Else, good document, pretty much like the well-kno= wn rogue DHCPv4

-=E9ric

From: Kiran Kumar Chittimaneni <kk.chittimaneni@gmail.com><= br> Date: dimanche 11 mai 2014 05:12
To: "opsec@ietf.org&quo= t; <opsec@ietf.org>
Subject: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield

Dear Opsec WG,

The WGLC for this draft technically ended last month with just on= e response received. Not enough to move forward.

The co-chairs chatted about this and noted that there was a lot more supp= ort for this doc during earlier stages. Given that, we'd like to give the= =20WG a bit more time to review this and extend the LC to the 24th of May= . Ideally, we'd like to get at least two =20volunteers who could do a thorough review of this doc and post their c= omments to the list.

Th= e draft is available here: https://datatracker= .ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/

Please read it now and report to the list whether you support pub= lication or not. Insufficient responses will be taken as an indication =20of lack of interest and we'll stop from proceeding further.=

Regards,

KK (as Opsec WG co-chai= r)

NOTICE AND DISCLAIMER
This e-mail (including any attachments) is in= tended=20 for the above-named person(s). If you are not the intended recipien= t,=20 notify the sender immediately, delete this email from your system and do = not=20 disclose or use for any purpose.

We may monitor all i= ncoming=20 and outgoing emails in line with current legislation. We have taken steps= =20to=20 ensure that this email and attachments are free from any virus, but it re= mains=20 your responsibility to ensure that viruses do not adversely affect you. <= /P>

EE Limited
Registered in England and Wales
Company Registered Nu= mber:=20 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfi= eld,=20 Hertfordshire, AL10 9BW

--_000_679694A32AB94046931C676BEF4BA8B80C9257A7UK31S005EXS06EE_-- From nobody Thu May 15 13:19:19 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E8D1A0158; Thu, 15 May 2014 13:19:15 -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 XQM7C2zwfMAM; Thu, 15 May 2014 13:19:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB101A0191; Thu, 15 May 2014 13:19:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140515201914.1356.80314.idtracker@ietfa.amsl.com> Date: Thu, 15 May 2014 13:19:14 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/YcrN9rD7oe39sOSayGShgUCArFk Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-08.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 20:19:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. Title : Using Only Link-Local Addressing Inside an IPv6 Network Authors : Michael Behringer Eric Vyncke Filename : draft-ietf-opsec-lla-only-08.txt Pages : 10 Date : 2014-05-15 Abstract: In an IPv6 network it is possible to use only link-local addresses on infrastructure links between routers. This document discusses the advantages and disadvantages of this approach to help the decision process for a given network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-lla-only/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-lla-only-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-lla-only-08 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 26 07:34:53 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FBA1A016D for ; Mon, 26 May 2014 07:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 U6zGqnG82l_a for ; Mon, 26 May 2014 07:34:47 -0700 (PDT) Received: from mx-relay37-dus.antispameurope.com (mx-relay37-dus.antispameurope.com [94.100.134.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C60A1A0160 for ; Mon, 26 May 2014 07:34:43 -0700 (PDT) Received: from smtpsrv1.fokus.fraunhofer.de ([195.37.77.166]) by mx-gate37-dus.antispameurope.com; Mon, 26 May 2014 16:34:36 +0200 Received: from CURIE.fokus.fraunhofer.de (curie.fokus.fraunhofer.de [IPv6:2001:638:806:9::203] (may be forged)) by smtpsrv1.fokus.fraunhofer.de (8.14.4/8.14.4) with ESMTP id s4QEYZxl026321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 26 May 2014 16:34:35 +0200 Received: from DIRAC.fokus.fraunhofer.de ([fe80::95a6:a35d:2023:242c]) by CURIE.fokus.fraunhofer.de ([fe80::4405:336c:6211:c99f%16]) with mapi id 14.03.0181.006; Mon, 26 May 2014 16:34:34 +0200 From: "Schmoll, Carsten" To: "Sleigh, Robert" , "Eric Vyncke (evyncke)" , KK Chittimaneni , "opsec@ietf.org" Thread-Topic: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield Thread-Index: AQHPbMbZqYYYlHbAFkKj3yztxNB1PZs8y8CAgAA3WYCAFgDwEA== Date: Mon, 26 May 2014 14:34:34 +0000 Message-ID: <45F6EC28CBA2DE418529BD6EBC89A8226BFE6A85@DIRAC.fokus.fraunhofer.de> References: <679694A32AB94046931C676BEF4BA8B80C9257A7@UK31S005EXS06.EEAD.EEINT.CO.UK> In-Reply-To: <679694A32AB94046931C676BEF4BA8B80C9257A7@UK31S005EXS06.EEAD.EEINT.CO.UK> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:638:806:9::121] x-kse-antivirus-interceptor-info: protection disabled Content-Type: multipart/alternative; boundary="_000_45F6EC28CBA2DE418529BD6EBC89A8226BFE6A85DIRACfokusfraun_" MIME-Version: 1.0 X-cloud-security-sender: carsten.schmoll@fokus.fraunhofer.de X-cloud-security-recipient: opsec@ietf.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate37-dus with 659572118001 X-cloud-security-connect: smtpsrv1.fokus.fraunhofer.de[195.37.77.166], TLS=, IP=195.37.77.166 X-cloud-security: scantime:.1704 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/onkn8Bojb7j6QqN-63kggTRRPCs Cc: Fernando Gont Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 14:34:52 -0000 --_000_45F6EC28CBA2DE418529BD6EBC89A8226BFE6A85DIRACfokusfraun_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Fernando, all, I second this opinion; maybe some additional section could be added to stat= e the extras issues related to a routed DHCPv6 server environment, and what= can (or MUST) be done in such a setup? As far as wording in this draft goes, I am not sure about the '- ' in "firs= t-fragment" and in "state-less", but then again I am no English native spea= ker myself. Best regards Carsten From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Sleigh, Robert Sent: Monday, May 12, 2014 6:28 PM To: Eric Vyncke (evyncke); KK Chittimaneni; opsec@ietf.org Cc: Fernando Gont Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield Hi All This seems like a good step in the right direction, so I think this documen= t has some value and should progress but... Unless this functionality is to be deployed on every switch port across an = entire environment (which I grant you, it may well be), I think this will o= nly remove the risk entirely if the client and the DHCPv6 server are locate= d on the same switch. It does not necessarily provide full protection for endusers in, for exampl= e, a routed DHCPv6 relay environment, and I think a similar issue arises in= cascading L2 devices. In a routed DHCPv6 relay environment there will be an ingress port on the e= nduser's local switch which will need to be enabled for receiving DHCPv6-se= rver messages, but the switch will be reliant on the upstream devices to ha= ve filtered out rogue DHCPv6-server messages, as the local switch has no wa= y of determining which upstream DHCP-server messages are valid. Regards Bob 07958 318592 Life's for sharing... and what I like to share the most is a smile From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Eric Vyncke (evync= ke) Sent: 12 May 2014 14:10 To: KK Chittimaneni; opsec@ietf.org Cc: Fernando Gont Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield KK, Gunter, Fernando & Will, I have reviewed the document and here are my comments (some cosmetic): * section 1: "on a specified port of the layer-2 device" =3D> "on speci= fic port(s) of the layer-2 device" (plural form) * Section 1: "Only those ports to which a DHCPv6 server" =3D> "Only tho= se ports to which a DHCPv6 server or relay" (relays should be allowed as we= ll) * Section 3: not sure whether it is relevant here, this is well-known a= nd accepted terminology, I am always uneasy when information is duplicated = as it is an open door for inconsistency * Section 3: should define what a 'DHCP shield device' is * Section 5: I do not agree with point 1) if the specific platform cann= ot handle a long ext header chain, it should be allowed to drop the packet = (the MUST NOT should be SHOULD NOT or even a MAY - reversing the proposed p= olicy). Of course, such platforms cannot claim compatibility with DHCP-shie= ld * Section 5: "SHOULD be logged in an implementation-specific manner as = security fault" =3D> "security alert" or "security event" * Section 7: the whole I-D is only handling the physical/wired switched= case while in the introduction it is stated to be 'broadcast network'. The= security section and/or introduction should mention this. * Section 7: should also mention other DHCP related threats? Such as Do= S attack against DHCP servers? Amplification/reflection attacks? Of course,= the mitigation techniques are out of scope, but, I think that the threats = should be mentioned * Add a reference to SAVI-DHCP ? Else, good document, pretty much like the well-known rogue DHCPv4 -=E9ric From: Kiran Kumar Chittimaneni > Date: dimanche 11 mai 2014 05:12 To: "opsec@ietf.org" > Subject: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield Dear Opsec WG, The WGLC for this draft technically ended last month with just one response= received. Not enough to move forward. The co-chairs chatted about this and noted that there was a lot more suppor= t for this doc during earlier stages. Given that, we'd like to give the WG = a bit more time to review this and extend the LC to the 24th of May. Ideall= y, we'd like to get at least two volunteers who could do a thorough review = of this doc and post their comments to the list. The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-op= sec-dhcpv6-shield/ Please read it now and report to the list whether you support publication o= r not. Insufficient responses will be taken as an indication of lack of int= erest and we'll stop from proceeding further. Regards, KK (as Opsec WG co-chair) NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named per= son(s). If you are not the intended recipient, notify the sender immediate= ly, delete this email from your system and do not disclose or use for any p= urpose. We may monitor all incoming and outgoing emails in line with current legisl= ation. We have taken steps to ensure that this email and attachments are fr= ee from any virus, but it remains your responsibility to ensure that viruse= s do not adversely affect you. EE Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfords= hire, AL10 9BW --_000_45F6EC28CBA2DE418529BD6EBC89A8226BFE6A85DIRACfokusfraun_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I second this opinion; maybe some additional section could= be added to state the extras issues related to a routed DHCPv6 server environment, and what can (or MUST) be done in such a setup?

As far as wording in this draft goes, I am not sure about = the ‘- ‘ in “first-fragment” and in “state-le= ss”, but then again I am no English native speaker myself.

Best regards

Carsten

From: OPSEC = [mailto:opsec-bounces@ietf.org] On Behalf Of Sleigh, Robert
Sent: Monday, May 12, 2014 6:28 PM
To: Eric Vyncke (evyncke); KK Chittimaneni; opsec@ietf.org
Cc: Fernando Gont
Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield=

Hi All

= ;

This seems= like a good step in the right direction, so I think this document has some= value and should progress but…

= ;

Unless thi= s functionality is to be deployed on every switch port across an entire env= ironment (which I grant you, it may well be), I think this will only remove the risk entirely if the client and the DHCPv6 server are= located on the same switch.

= ;

It does no= t necessarily provide full protection for endusers in, for example, a route= d DHCPv6 relay environment, and I think a similar issue arises in cascading L2 devices.

= ;

In a route= d DHCPv6 relay environment there will be an ingress port on the enduserR= 17;s local switch which will need to be enabled for receiving DHCPv6-server messages, but the switch will be reliant on the upstream devices to have f= iltered out rogue DHCPv6-server messages, as the local switch has no way of= determining which upstream DHCP-server messages are valid.

= ;

Regards<= span lang=3D"EN-GB" style=3D"color:#1F497D">

Bob

07958 318592

Life's for s= haring... and what I like to share the most is a smile

= ;

From: OPSEC [mail= to:opsec-bounces@ietf.org] On Behalf Of Eric Vyncke (evyncke)
Sent: 12 May 2014 14:10
To: KK Chittimaneni; opsec@ietf.or= g
Cc: Fernando Gont
Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield=

KK, Gunter, = Fernando & Will,

<= /o:p>

I have revie= wed the document and here are my comments (some cosmetic):

section 1: "on a specified port of the lay= er-2 device" =3D> "on specific port(s) of the layer-2 device&q= uot; (plural form)
Section 1: "Only those ports to= which a DHCPv6 server" =3D> "Only those ports to which a DHCP= v6 server or relay" (relays should be allowed as well)
Section 3: not sure whether it is r= elevant here, this is well-known and accepted terminology, I am always unea= sy when information is duplicated as it is an open door for inconsistency
Section 3: should define what a 'DHCP shield device' i= s
Section 5: I do not agree with point 1) if the specifi= c platform cannot handle a long ext header chain, it should be allowed to d= rop the packet (the MUST NOT should be SHOULD NOT or even a MAY — rev= ersing the proposed policy). Of course, such platforms cannot claim compatibility with DHCP-shield
Section 5: "SHOULD be logged in an implementation= -specific manner as security fault" =3D> "security alert"= or "security event"
Section 7: the whole I-D is only handling th= e physical/wired switched case while in the introduction it is stated to be= 'broadcast network'. The security section and/or introduction should menti= on this.
Section 7: should also mention other DHCP related thre= ats? Such as DoS attack against DHCP servers? Amplification/reflection atta= cks? Of course, the mitigation techniques are out of scope, but, I think th= at the threats should be mentioned
Add a reference to SAVI-DHCP ?

Else, good document, pretty muc= h like the well-known rogue DHCPv4

-=E9ric

<= /o:p>

From: Kiran Kumar Chittimaneni= <kk.chittimaneni@gmail.com= >
Date: dimanche 11 mai 2014 05:12
To: "opsec@ietf.org"= <opsec@ietf.org>
Subject: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield

<= /o:p>

Dear Opsec WG,

The WGLC for this draft technically ended last month wit= h just one response received. Not enough to move forward.

The co-chairs chatted about this and noted that there was a lot more suppor= t for this doc during earlier stages. Given that, we'd like to give the WG = a bit more time to review this and extend the LC to the 24th of May. Ideall= y, we'd like to get at least two volunteers who could do a thorough review of this doc and post their comme= nts to the list.

The draft is available here: https://data= tracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/

<= /o:p>

Please read it now and report to the list whether you su= pport publication or not. Insufficient responses will be taken as an indication of lack of interest and we'll stop from proceeding furthe= r.

Regards,

KK (as Opsec= WG co-chair)

NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named per= son(s). If you are not the intended recipient, notify the sender imme= diately, delete this email from your system and do not disclose or use for = any purpose.

We may monitor all incoming and outgoing emails in line with current legisl= ation. We have taken steps to ensure that this email and attachments are fr= ee from any virus, but it remains your responsibility to ensure that viruse= s do not adversely affect you.

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfords= hire, AL10 9BW

--_000_45F6EC28CBA2DE418529BD6EBC89A8226BFE6A85DIRACfokusfraun_-- From nobody Tue May 27 01:14:47 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D921A03DA for ; Tue, 27 May 2014 01:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 FMjLpCSBkb2b for ; Tue, 27 May 2014 01:14:38 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98C7E1A03E2 for ; Tue, 27 May 2014 01:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32759; q=dns/txt; s=iport; t=1401178474; x=1402388074; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5WNz9bY9JOh5NesPWltes4N3suvZ8Vrz7KpGEmxen4s=; b=eH2IrGn9EnLef2wAy75+zgrn9ZdTaetR95aWjDe8dUFXaI8HhwToi2sE ZoBJyOZtE/wekXqqfNsVZvJ9CXlHPBzttMnBLDsuZ9nP2V7gh2W9Mqc/1 qFBx9X0fiXLQvDY2OBEE3+TCDSEExEKGHdWN5FKR4jPkMxsD+MWEmm6N4 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFACdIhFOtJA2H/2dsb2JhbABZgkJFUljCFAGBDhZ0giUBAQEELUcFEAIBCBEDAQEBIQEGByERFAkIAgQBDQUZiBUDEQ3Nbw2GGhMEjDyBNAoHASwTDAEEBgEChD4El32Bdo01hXKDOGyBAQkXIg X-IronPort-AV: E=Sophos;i="4.98,917,1392163200"; d="scan'208,217";a="327943965" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-1.cisco.com with ESMTP; 27 May 2014 08:14:33 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s4R8EXgF008259 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 May 2014 08:14:33 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.121]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 27 May 2014 03:14:33 -0500 From: "Eric Vyncke (evyncke)" To: "Schmoll, Carsten" , "Sleigh, Robert" , KK Chittimaneni , "opsec@ietf.org" Thread-Topic: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield Thread-Index: AQHPbMbYfZxAQufNXkuwA/o7IiWXMps8y8CAgAA3WYCAFgDwEIABnyGA Date: Tue, 27 May 2014 08:14:33 +0000 Message-ID: References: <679694A32AB94046931C676BEF4BA8B80C9257A7@UK31S005EXS06.EEAD.EEINT.CO.UK> <45F6EC28CBA2DE418529BD6EBC89A8226BFE6A85@DIRAC.fokus.fraunhofer.de> In-Reply-To: <45F6EC28CBA2DE418529BD6EBC89A8226BFE6A85@DIRAC.fokus.fraunhofer.de> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.55.185.77] Content-Type: multipart/alternative; boundary="_000_CFAA15931C660evynckeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/CaZWX-Q-htZcXdTp8S13vH6r9KQ Cc: Fernando Gont Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 08:14:41 -0000 --_000_CFAA15931C660evynckeciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Bob and Carsten, I am not sure why you make a difference between a DHCP server and a DHCP re= lay in this context. Of course, if this is a DHCP relay, then the relay pat= h should also be trusted (which is usually the case as it is part of the in= frastructure). My understanding is that this I-D is basically an extension = of RA guard RFC. You are also right about the cascading layer-2 switches, this features shou= ld indeed be deployed on all layer-2 switches of a layer-2 domain. -=E9ric From: , Carsten > Date: lundi 26 mai 2014 07:34 To: "Sleigh, Robert" = >, Eric Vyncke >, Kiran Kumar C= hittimaneni >, = "opsec@ietf.org" > Cc: Fernando Gont > Subject: RE: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield Dear Fernando, all, I second this opinion; maybe some additional section could be added to stat= e the extras issues related to a routed DHCPv6 server environment, and what= can (or MUST) be done in such a setup? As far as wording in this draft goes, I am not sure about the =91- =91 in = =93first-fragment=94 and in =93state-less=94, but then again I am no Englis= h native speaker myself. Best regards Carsten From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Sleigh, Robert Sent: Monday, May 12, 2014 6:28 PM To: Eric Vyncke (evyncke); KK Chittimaneni; opsec@ietf.org Cc: Fernando Gont Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield Hi All This seems like a good step in the right direction, so I think this documen= t has some value and should progress but=85 Unless this functionality is to be deployed on every switch port across an = entire environment (which I grant you, it may well be), I think this will o= nly remove the risk entirely if the client and the DHCPv6 server are locate= d on the same switch. It does not necessarily provide full protection for endusers in, for exampl= e, a routed DHCPv6 relay environment, and I think a similar issue arises in= cascading L2 devices. In a routed DHCPv6 relay environment there will be an ingress port on the e= nduser=92s local switch which will need to be enabled for receiving DHCPv6-= server messages, but the switch will be reliant on the upstream devices to = have filtered out rogue DHCPv6-server messages, as the local switch has no = way of determining which upstream DHCP-server messages are valid. Regards Bob 07958 318592 Life's for sharing... and what I like to share the most is a smile From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Eric Vyncke (evync= ke) Sent: 12 May 2014 14:10 To: KK Chittimaneni; opsec@ietf.org Cc: Fernando Gont Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield KK, Gunter, Fernando & Will, I have reviewed the document and here are my comments (some cosmetic): * section 1: "on a specified port of the layer-2 device" =3D> "on speci= fic port(s) of the layer-2 device" (plural form) * Section 1: "Only those ports to which a DHCPv6 server" =3D> "Only tho= se ports to which a DHCPv6 server or relay" (relays should be allowed as we= ll) * Section 3: not sure whether it is relevant here, this is well-known a= nd accepted terminology, I am always uneasy when information is duplicated = as it is an open door for inconsistency * Section 3: should define what a 'DHCP shield device' is * Section 5: I do not agree with point 1) if the specific platform cann= ot handle a long ext header chain, it should be allowed to drop the packet = (the MUST NOT should be SHOULD NOT or even a MAY =97 reversing the proposed= policy). Of course, such platforms cannot claim compatibility with DHCP-sh= ield * Section 5: "SHOULD be logged in an implementation-specific manner as = security fault" =3D> "security alert" or "security event" * Section 7: the whole I-D is only handling the physical/wired switched= case while in the introduction it is stated to be 'broadcast network'. The= security section and/or introduction should mention this. * Section 7: should also mention other DHCP related threats? Such as Do= S attack against DHCP servers? Amplification/reflection attacks? Of course,= the mitigation techniques are out of scope, but, I think that the threats = should be mentioned * Add a reference to SAVI-DHCP ? Else, good document, pretty much like the well-known rogue DHCPv4 -=E9ric From: Kiran Kumar Chittimaneni > Date: dimanche 11 mai 2014 05:12 To: "opsec@ietf.org" > Subject: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield Dear Opsec WG, The WGLC for this draft technically ended last month with just one response= received. Not enough to move forward. The co-chairs chatted about this and noted that there was a lot more suppor= t for this doc during earlier stages. Given that, we'd like to give the WG = a bit more time to review this and extend the LC to the 24th of May. Ideall= y, we'd like to get at least two volunteers who could do a thorough review = of this doc and post their comments to the list. The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-op= sec-dhcpv6-shield/ Please read it now and report to the list whether you support publication o= r not. Insufficient responses will be taken as an indication of lack of int= erest and we'll stop from proceeding further. Regards, KK (as Opsec WG co-chair) NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named per= son(s). If you are not the intended recipient, notify the sender immediate= ly, delete this email from your system and do not disclose or use for any p= urpose. We may monitor all incoming and outgoing emails in line with current legisl= ation. We have taken steps to ensure that this email and attachments are fr= ee from any virus, but it remains your responsibility to ensure that viruse= s do not adversely affect you. EE Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfords= hire, AL10 9BW --_000_CFAA15931C660evynckeciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2DE14A32D84A534F837FD3452F02065B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Bob and Carsten,

I am not sure why you make a difference between a DHCP server and a DH= CP relay in this context. Of course, if this is a DHCP relay, then the rela= y path should also be trusted (which is usually the case as it is part of t= he infrastructure). My understanding is that this I-D is basically an extension of RA guard RFC.

You are also right about the cascading layer-2 switches, this features= should indeed be deployed on all layer-2 switches of a layer-2 domain.

-=E9ric

From: <Schmoll>, Carsten <= carsten.schmoll@foku= s.fraunhofer.de>
Date: lundi 26 mai 2014 07:34
To: "Sleigh, Robert" <= robert.sleigh@ee.co.uk>, E= ric Vyncke <evyncke@cisco.com&g= t;, Kiran Kumar Chittimaneni <kk.chittimaneni@gmail.com>, "opsec@ietf.org" <opsec@ietf.org>
Cc: Fernando Gont <fgont@si6networks.com>
Subject: RE: [OPSEC] Progressing dr= aft-ietf-opsec-dhcpv6-shield

Dear Fernando, all,

I second this opini= on; maybe some additional section could be added to state the extras issues= related to a routed DHCPv6 server environment, and what can (or MUST) be done in such a setup?

As far as wording i= n this draft goes, I am not sure about the =91- =91 in =93first-fragment=94= and in =93state-less=94, but then again I am no English native speaker myself.

Best regards

Carsten<= /span>

From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Sleigh, Robert
Sent: Monday, May 12, 2014 6:28 PM
To: Eric Vyncke (evyncke); KK Chittimaneni; opsec@ietf.org
Cc: Fernando Gont
Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield=

Hi All

This seems like a g= ood step in the right direction, so I think this document has some value an= d should progress but=85

Unless this functio= nality is to be deployed on every switch port across an entire environment = (which I grant you, it may well be), I think this will only remove the risk entirely if the client and the DHCPv6= server are located on the same switch.

It does not necessa= rily provide full protection for endusers in, for example, a routed DHCPv6 = relay environment, and I think a similar issue arises in cascading L2 devices.

In a routed DHCPv6 = relay environment there will be an ingress port on the enduser=92s local sw= itch which will need to be enabled for receiving DHCPv6-server messages, but the switch will be reliant on the upstream dev= ices to have filtered out rogue DHCPv6-server messages, as the local switch= has no way of determining which upstream DHCP-server messages are valid.

Regards

Bob

07958 318592

Life's for sharing... and what= I like to share the most is a smile

From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Eric Vyncke (evyncke)
Sent: 12 May 2014 14:10
To: KK Chittimaneni; opsec@ietf.or= g
Cc: Fernando Gont
Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield=

KK, Gunter, Fernando & W= ill,

I have reviewed the document= and here are my comments (some cosmetic):

section 1: "on a specified port of the layer-2 device" = =3D> "on specific port(s) of the layer-2 device" (plural form)=
Section 1= : "Only those ports to which a DHCPv6 serv= er" =3D> "Only those ports to which a DHCPv6 server or relay&q= uot; (relays should be allowed as well)
Section 3: not sure whether it is relevant here, th= is is well-known and accepted terminology, I am always uneasy when informat= ion is duplicated as it is an open door for inconsistency
Section 3: should define what a 'DHCP shield device' i= s
Section 5: I do not agree with point 1) if the specifi= c platform cannot handle a long ext header chain, it should be allowed to d= rop the packet (the MUST NOT should be SHOULD NOT or even a MAY =97 reversi= ng the proposed policy). Of course, such platforms cannot claim compatibility with DHCP-shield
Section 5: "SHOULD be logged in an implementation= -specific manner as security fault" =3D> "security alert"= or "security event"
Section 7: the whole I-D is only handling th= e physical/wired switched case while in the introduction it is stated to be= 'broadcast network'. The security section and/or introduction should menti= on this.
Section 7: should also mention other DHCP related thre= ats? Such as DoS attack against DHCP servers? Amplification/reflection atta= cks? Of course, the mitigation techniques are out of scope, but, I think th= at the threats should be mentioned
Add a reference to SAVI-DHCP ?
<= /ul>

Else, good document, pretty muc= h like the well-known rogue DHCPv4

-=E9ric

From: Kiran Kumar Chittimaneni <kk.chittimaneni@gmail.com>
Date: dimanche 11 mai 2014 05:12
To: "opsec@ietf.org"= <opsec@ietf.org>
Subject: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield

The draft= is available here: https://datatracker.ietf.org/d= oc/draft-ietf-opsec-dhcpv6-shield/<= /o:p>

Regards,

KK (as Opsec WG co-chair)

NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named per= son(s). If you are not the intended recipient, notify the sender imme= diately, delete this email from your system and do not disclose or use for = any purpose.

We may monitor all incoming and outgoing emails in line with current legisl= ation. We have taken steps to ensure that this email and attachments are fr= ee from any virus, but it remains your responsibility to ensure that viruse= s do not adversely affect you.

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfords= hire, AL10 9BW

--_000_CFAA15931C660evynckeciscocom_-- From nobody Tue May 27 02:03:03 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F431A004E for ; Tue, 27 May 2014 02:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 4dZ6j9fspySj for ; Tue, 27 May 2014 02:02:57 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.153]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1D11A002F for ; Tue, 27 May 2014 02:02:55 -0700 (PDT) Received: from [85.158.136.3:20432] by server-17.bemta-5.messagelabs.com id F9/CB-09046-BB454835; Tue, 27 May 2014 09:02:51 +0000 X-Env-Sender: robert.sleigh@ee.co.uk X-Msg-Ref: server-8.tower-123.messagelabs.com!1401181368!38955695!1 X-Originating-IP: [193.36.79.211] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25484 invoked from network); 27 May 2014 09:02:49 -0000 Received: from unknown (HELO autechre) (193.36.79.211) by server-8.tower-123.messagelabs.com with SMTP; 27 May 2014 09:02:49 -0000 Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by autechre with MailMarshal (v6, 8, 2, 9371) id ; Tue, 27 May 2014 10:03:41 +0100 Received: from UK31S005EXS06.EEAD.EEINT.CO.UK ([fe80::d851:f0e3:bba5:c1a0]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.02.0318.004; Tue, 27 May 2014 10:02:48 +0100 From: "Sleigh, Robert" To: "Eric Vyncke (evyncke)" , "Schmoll, Carsten" , KK Chittimaneni , "opsec@ietf.org" Thread-Topic: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield Thread-Index: AQHPbMbU3Fibc0izRkWpMI7LA/NQHZs83IOAgAAklOCAFfPRAIABKCiAgAAaoOA= Date: Tue, 27 May 2014 09:02:47 +0000 Message-ID: <679694A32AB94046931C676BEF4BA8B80C93B497@UK31S005EXS06.EEAD.EEINT.CO.UK> References: <679694A32AB94046931C676BEF4BA8B80C9257A7@UK31S005EXS06.EEAD.EEINT.CO.UK> <45F6EC28CBA2DE418529BD6EBC89A8226BFE6A85@DIRAC.fokus.fraunhofer.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: multipart/alternative; boundary="_000_679694A32AB94046931C676BEF4BA8B80C93B497UK31S005EXS06EE_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/LAiR6nOg9lhSwmjm745YMnvZbpA Cc: Fernando Gont Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 09:03:01 -0000 --_000_679694A32AB94046931C676BEF4BA8B80C93B497UK31S005EXS06EE_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Eric I chose DHCP relays as the example because they will not be in the L2 dom= ain of the clients, whereas a DHCP server will be. You are right it's the same issue, you have to trust any inbound packet o= n the L2 device interconnect, just perhaps a potentially higher risk due = to the wider scope for exploitation ie all the non-local devices in the c= lient L2 scope, the relay L2 scope and any interconnected L2 scopes... Regards Bob 07958 318592 Life's for sharing... and what I like to share the most is a smile From: Eric Vyncke (evyncke) [mailto:evyncke@cisco.com] Sent: 27 May 2014 09:15 To: Schmoll, Carsten; Sleigh, Robert; KK Chittimaneni; opsec@ietf.org Cc: Fernando Gont Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield Bob and Carsten, I am not sure why you make a difference between a DHCP server and a DHCP = relay in this context. Of course, if this is a DHCP relay, then the relay= =20path should also be trusted (which is usually the case as it is part o= f the infrastructure). My understanding is that this I-D is basically an = extension of RA guard RFC. You are also right about the cascading layer-2 switches, this features sh= ould indeed be deployed on all layer-2 switches of a layer-2 domain. -=E9ric From: , Carsten > Date: lundi 26 mai 2014 07:34 To: "Sleigh, Robert" >, Eric Vyncke >, Kiran Kum= ar Chittimaneni >, "opsec@ietf.org" > Cc: Fernando Gont > Subject: RE: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield Dear Fernando, all, I second this opinion; maybe some additional section could be added to st= ate the extras issues related to a routed DHCPv6 server environment, and = what can (or MUST) be done in such a setup? As far as wording in this draft goes, I am not sure about the '- ' in "fi= rst-fragment" and in "state-less", but then again I am no English native = speaker myself. Best regards Carsten From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Sleigh, Robert Sent: Monday, May 12, 2014 6:28 PM To: Eric Vyncke (evyncke); KK Chittimaneni; opsec@ietf.org Cc: Fernando Gont Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield Hi All This seems like a good step in the right direction, so I think this docum= ent has some value and should progress but... Unless this functionality is to be deployed on every switch port across a= n entire environment (which I grant you, it may well be), I think this wi= ll only remove the risk entirely if the client and the DHCPv6 server are = located on the same switch. It does not necessarily provide full protection for endusers in, for exam= ple, a routed DHCPv6 relay environment, and I think a similar issue arise= s in cascading L2 devices. In a routed DHCPv6 relay environment there will be an ingress port on the= =20enduser's local switch which will need to be enabled for receiving DHC= Pv6-server messages, but the switch will be reliant on the upstream devic= es to have filtered out rogue DHCPv6-server messages, as the local switch= =20has no way of determining which upstream DHCP-server messages are vali= d. Regards Bob 07958 318592 Life's for sharing... and what I like to share the most is a smile From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Eric Vyncke (evy= ncke) Sent: 12 May 2014 14:10 To: KK Chittimaneni; opsec@ietf.org Cc: Fernando Gont Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield KK, Gunter, Fernando & Will, I have reviewed the document and here are my comments (some cosmetic): =20 * section 1: "on a specified port of the layer-2 device" =3D> "on s= pecific port(s) of the layer-2 device" (plural form) =20 * Section 1: "Only those ports to which a DHCPv6 server" =3D> "Only= =20those ports to which a DHCPv6 server or relay" (relays should be allow= ed as well) =20 * Section 3: not sure whether it is relevant here, this is well-kno= wn and accepted terminology, I am always uneasy when information is dupli= cated as it is an open door for inconsistency =20 * Section 3: should define what a 'DHCP shield device' is =20 * Section 5: I do not agree with point 1) if the specific platform = cannot handle a long ext header chain, it should be allowed to drop the p= acket (the MUST NOT should be SHOULD NOT or even a MAY - reversing the pr= oposed policy). Of course, such platforms cannot claim compatibility with= =20DHCP-shield =20 * Section 5: "SHOULD be logged in an implementation-specific manner= =20as security fault" =3D> "security alert" or "security event" =20 * Section 7: the whole I-D is only handling the physical/wired swit= ched case while in the introduction it is stated to be 'broadcast network= '. The security section and/or introduction should mention this. =20 * Section 7: should also mention other DHCP related threats? Such a= s DoS attack against DHCP servers? Amplification/reflection attacks? Of c= ourse, the mitigation techniques are out of scope, but, I think that the = threats should be mentioned =20 * Add a reference to SAVI-DHCP ? Else, good document, pretty much like the well-known rogue DHCPv4 -=E9ric From: Kiran Kumar Chittimaneni > Date: dimanche 11 mai 2014 05:12 To: "opsec@ietf.org" > Subject: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield Dear Opsec WG, The WGLC for this draft technically ended last month with just one respon= se received. Not enough to move forward. The co-chairs chatted about this and noted that there was a lot more supp= ort for this doc during earlier stages. Given that, we'd like to give the= =20WG a bit more time to review this and extend the LC to the 24th of May= . Ideally, we'd like to get at least two volunteers who could do a thorou= gh review of this doc and post their comments to the list. The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-= opsec-dhcpv6-shield/ Please read it now and report to the list whether you support publication= =20or not. Insufficient responses will be taken as an indication of lack = of interest and we'll stop from proceeding further. Regards, KK (as Opsec WG co-chair) NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named p= erson(s). If you are not the intended recipient, notify the sender immed= iately, delete this email from your system and do not disclose or use for= =20any purpose. We may monitor all incoming and outgoing emails in line with current legi= slation. We have taken steps to ensure that this email and attachments ar= e free from any virus, but it remains your responsibility to ensure that = viruses do not adversely affect you. EE Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfor= dshire, AL10 9BW NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named p= erson(s). If you are not the intended recipient, notify the sender immed= iately, delete this email from your system and do not disclose or use for= =20any purpose. =20 =20 We may monitor all incoming and outgoing emails in line with current legi= slation. We have taken steps to ensure that this email and attachments ar= e free from any virus, but it remains your responsibility to ensure that = viruses do not adversely affect you.=20 EE Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfor= dshire, AL10 9BW --_000_679694A32AB94046931C676BEF4BA8B80C93B497UK31S005EXS06EE_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =

Hi Eric

I chose DHCP relays a= s the example because they will not be in the L2 domain of the clients, w= hereas a DHCP server will be.

You are right it̵= 7;s the same issue, you have to trust any inbound packet on the L2 device= =20interconnect, just perhaps a potentially higher risk due to the wider =20scope for exploitation ie all the non-local devices in the client L2 s= cope, the relay L2 scope and any interconnected L2 scopes…

Regards

Bob

07958 318592

Life's for sharing... a= nd what I like to share the most is a smile

From: Eric Vyncke (evyncke) [mailto:evyncke@cisco.c= om]
Sent: 27 May 2014 09:15
To: Schmoll, Carsten; Sleigh, Robert; KK Chittimaneni; opsec@ietf.= org
Cc: Fernando Gont
Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield

Bob and Carsten,

I am not sure why you m= ake a difference between a DHCP server and a DHCP relay in this context. = Of course, if this is a DHCP relay, then the relay path should =20also be trusted (which is usually the case as it is part of the infras= tructure). My understanding is that this I-D is basically an extension of= =20RA guard RFC.

You are also right abou= t the cascading layer-2 switches, this features should indeed be deployed= =20on all layer-2 switches of a layer-2 domain.

-=E9ric

From: <Schmoll>, Carsten <carsten.schmoll@fokus.fr= aunhofer.de>
Date: lundi 26 mai 2014 07:34
To: "Sleigh, Robert" <robert.sleigh@ee.co.uk>, Eric Vyncke <evyncke@cisco.com>, Kiran Kumar Chittimanen= i <kk.chittimaneni@gmail.= com>, =20"opsec@ietf.org" <<= a href=3D"mailto:opsec@ietf.org">opsec@ietf.org>
Cc: Fernando Gont <fgo= nt@si6networks.com>
Subject: RE: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield

Dear Fern= ando, all,

I seco= nd this opinion; maybe some additional section could be added to state th= e extras issues related to a routed DHCPv6 server environment, and =20what can (or MUST) be done in such a setup?

=

As far= =20as wording in this draft goes, I am not sure about the ‘- ‘= ; in “first-fragment” and in “state-less”, but th= en again I am no English native =20speaker myself.

=

Best r= egards
Carste= n

=

From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Sleigh, Robert
Sent: Monday, May 12, 2014 6:28 PM
To: Eric Vyncke (evyncke); KK Chittimaneni; opsec@ietf.org
Cc: Fernando Gont
Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield

Hi All

This seems like a goo= d step in the right direction, so I think this document has some value an= d should progress but…

Unless this functiona= lity is to be deployed on every switch port across an entire environment = (which I grant you, it may well be), I think this will only remove =20the risk entirely if the client and the DHCPv6 server are located on t= he same switch.=

It does not necessari= ly provide full protection for endusers in, for example, a routed DHCPv6 = relay environment, and I think a similar issue arises in cascading =20L2 devices.<= /span>

In a routed DHCPv6 re= lay environment there will be an ingress port on the enduser’s loca= l switch which will need to be enabled for receiving DHCPv6-server messag= es, =20but the switch will be reliant on the upstream devices to have filtere= d out rogue DHCPv6-server messages, as the local switch has no way of det= ermining which upstream DHCP-server messages are valid.

Regards

Bob

07958 318592

Life's for sharing... a= nd what I like to share the most is a smile

From:<= /span> OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Eric Vyncke (evyncke)
Sent: 12 May 2014 14:10
To: KK Chittimaneni; opsec@ietf.= org
Cc: Fernando Gont
Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield

KK, Gunter, Fernando &a= mp; Will,

I have reviewed the doc= ument and here are my comments (some cosmetic):

section 1: "on a specified port of the layer-2 device= " =3D> "on specific port(s) of the layer-2 device" (plu= ral form)
Se= ction 1: "Only those ports to which a DHCPv6 server" =3D= > "Only those ports to which a DHCPv6 server or relay" (rela= ys should be allowed as well)
Section 3: not sure whether it is relevant here, this is w= ell-known and accepted terminology, I am always uneasy when information i= s duplicated as it is an open door for inconsistency
=
Section 5: I do not agree with point 1) if the specific platform cannot h= andle a long ext header chain, it should be allowed to drop the packet (t= he MUST NOT should be SHOULD NOT or even a MAY — reversing the prop= osed policy). Of course, such platforms cannot =20claim compatibility with DHCP-shield
Section 5: "SHOULD be logged in an implementation-specific manner as= =20security fault" =3D> "security alert" or "secur= ity event"
Section 7: the whole I-D is only handling the physical/wired sw= itched case while in the introduction it is stated to be 'broadcast netwo= rk'. The security section and/or introduction should mention this.
Section 7: should also mention other DHCP related threats? Such as DoS at= tack against DHCP servers? Amplification/reflection attacks? Of course, t= he mitigation techniques are out of scope, but, I think that the threats = should be mentioned
Add a reference to SAVI-DHCP ?

Else, good document, p= retty much like the well-known rogue DHCPv4

-=E9ric

From: Kiran Kumar Chittimaneni <kk.chittimaneni@gmail.com><= br> Date: dimanche 11 mai 2014 05:12
To: "opsec@ietf.org&quo= t; <opsec@ietf.org>
Subject: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield=

Dear Opsec WG,

The WGLC for this draft technically ended last month with just on= e response received. Not enough to move forward.

The co-chairs chatted about this and noted that there was a lot more supp= ort for this doc during earlier stages. Given that, we'd like to give the= =20WG a bit more time to review this and extend the LC to the 24th of May= . Ideally, we'd like to get at least two =20volunteers who could do a thorough review of this doc and post their c= omments to the list.<= /o:p>

Th= e draft is available here: https://datatracker= .ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/

Please read it now and report to the list whether you support pub= lication or not. Insufficient responses will be taken as an indication =20of lack of interest and we'll stop from proceeding further.

Regards,

KK (as Opsec WG co-chai= r)

NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named p= erson(s). If you are not the intended recipient, notify the sender = immediately, delete this email from your system and do not disclose or us= e for any purpose.

We may monitor all incoming and outgoing emails in line with current legi= slation. We have taken steps to ensure that this email and attachments ar= e free from any virus, but it remains your responsibility to ensure that = viruses do not adversely affect you.

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfor= dshire, AL10 9BW

EE Limited
Registered in England and Wales
Company Registered Nu= mber:=20 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfi= eld,=20 Hertfordshire, AL10 9BW

--_000_679694A32AB94046931C676BEF4BA8B80C93B497UK31S005EXS06EE_--