Subject: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield

From: KK Chittimaneni <[email-masked]>
Date: Sat, 10 May 2014 20:12:14 -0700

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
support 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.
Ideally, 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-opsec-dhcpv6-shield/

<https://datatracker.ietf.org/doc/draft-ietf-opsec-ip-options-filtering/>
Please read it now and report to the list whether you support publication
or 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)

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 12 May 2014 13:09:33 +0000

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" => "on specific port(s) of the layer-2 device" (plural form)
  *   Section 1: "Only those ports to which a DHCPv6 server" => "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 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 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 — 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" => "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 DoS 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

-éric

From: Kiran Kumar Chittimaneni <[email-masked]<mailto:[email-masked]>>
Date: dimanche 11 mai 2014 05:12
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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 support 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. Ideally, 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-opsec-dhcpv6-shield/

<https://datatracker.ietf.org/doc/draft-ietf-opsec-ip-options-filtering/>
Please read it now and report to the list whether you support publication or not. Insufficient responses will be taken as an indication of lack of interest and we'll stop from proceeding further.

Regards,

---

From: "Sleigh, Robert" <[email-masked]>
Date: Mon, 12 May 2014 16:27:39 +0000

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 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 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 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'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 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:[email-masked]] On Behalf Of Eric Vyncke (evyncke)
Sent: 12 May 2014 14:10
To: KK Chittimaneni; [email-masked]
Cc: Fernando Gont
Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield

  *   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 packet (the MUST NOT should be SHOULD NOT or even a MAY - reversing the proposed policy). Of course, such platforms cannot claim compatibility with DHCP-shield

-éric

Dear Opsec WG,

NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named person(s).  If you are not the intended recipient, notify the sender immediately, 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 legislation. We have taken steps to ensure that this email and attachments are 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, Hertfordshire, AL10 9BW

---

From: "Schmoll, Carsten" <[email-masked]>
Date: Mon, 26 May 2014 14:34:34 +0000

Dear Fernando, all,

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-less", but then again I am no English native speaker myself.

Best regards
Carsten

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

Hi All

Regards

Bob
07958 318592

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

-éric

Dear Opsec WG,

NOTICE AND DISCLAIMER

EE Limited

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 27 May 2014 08:14:33 +0000

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 path should also be trusted (which is usually the case as it is part of 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 should indeed be deployed on all layer-2 switches of a layer-2 domain.

-éric

From: <Schmoll>, Carsten <[email-masked]<mailto:[email-masked]>>
Date: lundi 26 mai 2014 07:34
To: "Sleigh, Robert" <[email-masked]<mailto:[email-masked]>>, Eric Vyncke <[email-masked]<mailto:[email-masked]>>, Kiran Kumar Chittimaneni <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Fernando Gont <[email-masked]<mailto:[email-masked]>>
Subject: RE: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield

Dear Fernando, all,

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

Best regards
Carsten

From: OPSEC [mailto:[email-masked]] On Behalf Of Sleigh, Robert
Sent: Monday, May 12, 2014 6:28 PM
To: Eric Vyncke (evyncke); KK Chittimaneni; [email-masked]<mailto:[email-masked]>
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…

In a routed DHCPv6 relay environment there will be an ingress port on the enduser’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 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

-éric

Dear Opsec WG,

NOTICE AND DISCLAIMER

EE Limited

---

From: "Sleigh, Robert" <[email-masked]>
Date: Tue, 27 May 2014 09:02:47 +0000

Hi Eric

I chose DHCP relays as the example because they will not be in the L2 domain of the clients, whereas a DHCP server will be.

You are right it's the same issue, you have to trust any inbound packet on 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 client L2 scope, the relay L2 scope and any interconnected L2 scopes...

Regards

Bob
07958 318592

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

Bob and Carsten,

-éric

Dear Fernando, all,

Best regards
Carsten

Hi All

Regards

Bob
07958 318592

-éric

Dear Opsec WG,

NOTICE AND DISCLAIMER

EE Limited

NOTICE AND DISCLAIMER

EE Limited