Subject: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT)

From: "Ted Lemon" <[email-masked]>
Date: Sat, 07 Feb 2015 11:46:16 -0800

Ted Lemon has entered the following ballot position for
draft-ietf-opsec-dhcpv6-shield-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

When I began with this DISCUSS, my understanding was that in order to
implement DHCPv6 Shield and be sure of stopping all DHCP packets, it
would, as the document says, be necessary to filter packets with unknown
IPv6 headers.   This would likely mean that the layer 2 switching fabric
of a network supporting DHCPv6 shield would be unable to carry any IP
packets containing not only unknown IP extension headers, but also
packets containing unknown (to the switching fabric) protocol headers.  
Consequently I suggested a fairly elaborate way to mitigate the risk
without requiring that all such packets be filtered.

However, after discussing this at length with Fernando, I realized that
it was actually not at all necessary to filter unknown IPv6 headers.  
The reason for this is that we can safely assume that any IP extension
header that appears in a packet conforms to RFC 6564.   This means that
switches implementing DHCPv6 shield can at least in principle skip over
unknown IP extension headers.   If an unknown protocol header is seen,
this will look to the switch like a malformed IP extension header, but
this is harmless in the context of DHCPv6 shield because any such packet
is by definition _not_ a DHCPv6 packet.   I believe that a switching
fabric should not default to dropping packets it doesn't recognize,
because this pretty much guarantees that new protocols can't be deployed
even in site-specific situations.

Therefore, I believe that this document should not only not require
filtering unknown IP extension headers, but should not even mention
filtering them.   It may be that some implementations may need to filter
them for other reasons, but this is already allowed by RFC 7045, and
therefore needn't be mentioned here.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This is the original text of this DISCUSS:

This text makes sense, but I think it needs to be changed somewhat:

   3.  When parsing the IPv6 header chain, if the packet is identified
       to be a DHCPv6 packet meant for a DHCPv6 client or the packet
       contains an unrecognized Next Header value, DHCPv6-Shield MUST
       drop the packet, and SHOULD log the packet drop event in an
       implementation-specific manner as a security alert.
       DHCPv6-Shield MUST provide a configuration knob that controls
       whether packets with unrecognized Next Header values are dropped;
       this configuration knob MUST default to "drop".

          RATIONALE: An unrecognized Next Header value could possibly
          identify an IPv6 Extension Header, and thus be leveraged to
          conceal a DHCPv6-server packet (since there is no way for
          DHCPv6-Shield to parse past unrecognized Next Header values
          [I-D.gont-6man-rfc6564bis]).  [RFC7045] requires that nodes be
          configurable with respect to whether packets with unrecognized
          headers are forwarded, and allows the default behavior to be
          that such packets be dropped.

I think it's worth considering whether the default setting for this
configuration knob should be "drop" or "pass."   The problem with
defaulting to "drop" is that it means that extension headers the DHCPv6
Shield device does not understand fail to pass, which could cause
operational problems.   The problem with not defaulting to "drop" you
have already explained.   I do not think that the threat of DHCPv6
spoofing is sufficient to justify defaulting to drop.   Yes, DHCPv6
spoofing can cause operational issues.   So can filtering "unknown"
headers.

The frustrating thing about this document is that it actually solves the
problem the wrong way.   What this document should recommend is filtering
of DHCPv6 packets from _clients_.   If a rogue DHCP server can't see
client multicasts because DHCPv6 shield is blocking them, then it can't
know to attack DHCPv6 clients.   This substantially limits the rogue's
ability to attack DHCPv6 clients on the local subnet.   If you combine
that with server packet filtering but do not block unknown headers, I
think you have achieved a good tradeoff between the problems caused by
whatever spoofing might get to a client using an unknown header and the
problems caused by blocking non-DHCP packets that use that unknown header
for some legitimate purpose.

So, realizing that this would be a major change, the way I would LIKE you
to address this discuss is to add DHCPv6 client packet filtering.   You
could also address it by changing the default for the unknown header
filter, but I would understand if you felt that this was inadequate.   Or
you could argue persuasively that I'm wrong, which has been known to
happen. :)

---

From: Ted Lemon <[email-masked]>
Date: Sat, 7 Feb 2015 12:47:55 -0700

On Feb 7, 2015, at 12:46 PM, Ted Lemon <[email-masked]> wrote:
> header that appears in a packet conforms to RFC 6564. 

What I mean here is that any IP extension header not already standardized at the time of publication of this document, which presumably any implementation conforming to this document will be aware of.   Of course there are IP extension headers already defined that do not conform to RFC 6564.

---

From: Joel Jaeggli <[email-masked]>
Date: Sat, 7 Feb 2015 12:25:30 -0800

Right one would expect future extension headers to match the TLV  expectations of 6564. I can live with the removal of filtering advice but I'd like to see that run past the working group at the very least.

Sent from my iPhone

> On Feb 7, 2015, at 11:46, Ted Lemon <[email-masked]> wrote:
> 
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec
>

---

From: Ted Lemon <[email-masked]>
Date: Sat, 7 Feb 2015 13:37:03 -0700

> Right one would expect future extension headers to match the TLV  expectations of 6564. I can live with the removal of filtering advice but I'd like to see that run past the working group at the ve…

Sounds like a good plan.   Thanks!

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 08 Feb 2015 13:00:25 +1300

> Sounds like a good plan.   Thanks!

However, I don't think you should remove this sentence and the normative reference
to RFC 7045:

   [RFC7045] requires that nodes be
   configurable with respect to whether packets with unrecognized
   headers are forwarded, and allows the default behavior to be
   that such packets be dropped.

  Brian

---

From: Ted Lemon <[email-masked]>
Date: Sat, 7 Feb 2015 19:55:54 -0500

>   that such packets be dropped.

What does that have to do with DHCPv6 shield?   I guess I don't mind if this is included, but it seems unnecessary.

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 7 Feb 2015 19:37:19 -0800 (PST)

On Sat, 7 Feb 2015, Ted Lemon wrote:
> unknown IP extension headers.

That is incorrect because extension headers and upper layer headers 
share a numbering space.  Upper layer headers do NOT follow the 
format in RFC 6564.  That makes it in UNSAFE to attempt to skip over 
an unknown next header value.  The decision to drop or pass must be 
made when an unknown extension header is encountered.

Whether the default is drop or pass when encountering an unknown 
next header value may be worth reconsidering.  However, I strongly 
agree with Brian Carpenter that the normative reference to RFC 7045 
should be retained, and with it the requirement that the behaviour 
upon encountering an unknown next header value be user configurable.

Mike Heard

P.S.  For previous discussion please see:

http://www.ietf.org/mail-archive/web/opsec/current/msg01481.html
http://www.ietf.org/mail-archive/web/v6ops/current/msg18529.html

and please note that RFC 7113 (RA-Guard) specifies the same 
behaviour as does draft-ietf-opsec-dhcpv6-shield-05.

On Sat, 7 Feb 2015, Joel Jaeggli wrote:
> Right one would expect future extension headers to match the TLV 
> expectations of 6564. I can live with the removal of filtering 
> advice but I'd like to see that run past the working group at the 
> very least.
> 
> Sent from my iPhone
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 08 Feb 2015 17:14:12 +1300

> What does that have to do with DHCPv6 shield?   I guess I don't mind if this is included, but it seems unnecessary.

DHCPv6 Shield matches the definition of "forwarding node" given
in RFC 7045, so reminding implementers of the requirement seems
appropriate to me.

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Sun, 8 Feb 2015 02:03:15 -0500

On Feb 7, 2015, at 10:37 PM, C. M. Heard <[email-masked]> wrote:
> an unknown next header value.

I addressed that in my DISCUSS position.   The fact that RA guard gives bad advice is no reason for the bad advice to be repeated in this document.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 08 Feb 2015 15:04:13 -0300

On 02/07/2015 09:00 PM, Brian E Carpenter wrote:
> However, I don't think you should remove this sentence and the
> normative reference to RFC 7045:
> 
> [RFC7045] requires that nodes be configurable with respect to whether
> packets with unrecognized headers are forwarded, and allows the
> default behavior to be that such packets be dropped.

Well, IMO, what Ted is essentially saying is that we cannot take the
advice from RFC7045 (!).

When this document says that DHCPv6 shield should (by default) filter
packets with unrecognized IPv6 extension headers, t does so by backing
the requirement with RFC7045. Namely, it says:

---- cut here ----

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Sun, 08 Feb 2015 15:08:52 -0300

Hi, Mike,

FWIW, I made exactly the same point during the IESG-review discussions
-- i.e., I agree 100% with what you've said.

IMO, the default should be "drop", since that's the more sensible option
from a security standpoint... and because RFC7045 (the RFC that
clarifies what to do with IPv6 EHs) allows us to do so.

Thanks,
Fernando

---

From: Fernando Gont <[email-masked]>
Date: Sun, 08 Feb 2015 15:11:55 -0300

> I addressed that in my DISCUSS position.   The fact that RA guard gives bad advice is no reason for the bad advice to be repeated in this document.

The advice in RA-Guard in DHCPv6-shield is essentially 6man's advice on
the topic: RFC7045. That's why we provide RFC7045 as a reference.

If you don't like what the current version of the I-D says, you're not
only disagreeing with it and with the "RA-Guard IMplementation advice"
RFC, but also with the advice that 6man itself has produced on the topic
(RFC7045).

Thanks,

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 8 Feb 2015 10:47:58 -0800 (PST)

On Sun, 8 Feb 2015, Ted Lemon wrote:
> I addressed that in my DISCUSS position.

Wherein you wrote:

| If an unknown protocol header is seen, this will look to the 
| switch like a malformed IP extension header, but this is harmless 
| in the context of DHCPv6 shield because any such packet is by 
| definition _not_ a DHCPv6 packet.

It is not necessarily true that an unknown upper layer protocol 
header will look like a malformed extension header to a device that 
assumes it is an extension header following the format in RFC 6564.  
If the value of the 2nd octet of the unknown header is v, then it 
won't appear malformed if at least 8*(v+1) bytes remain in the 
packet, starting from the beginning of the unknown header.  At that 
point the device would be interpreting the payload of the unknown 
upper layer PDU as an extension header chain.  In the benign case 
where the packet is a legitimate one with an upper layer protocol 
unknown to the device, it is likely (but not assured) that the chain 
would quickly terminate in something that looks like a malformed 
extension header.  However, it would not be difficult to craft a 
packet that makes a very long apparent header chain.  Depending on 
how the device processes header chains, that could easily be a 
vector for DOS attacks -- e.g., by consuming processing resources or 
by exercising a rarely used processing path.  That is why I think it 
is UNSAFE to continue processing a header chain after encountering 
an unknown next header value.

That being said, I think I agree with your main point: if the 
default for a DHCPv6-Shield device is to drop packets with unknown 
next header values, then a DHCPv6-Shield device will by default 
block unknown upper layer protocols, and that is not a desirable 
effect if the ONLY purpose of the device is to shield against rogue 
DHCPv6 packets.

Perhaps a way forward would be to specify that a DHCPv6-Shield 
device SHOULD pass packets with unknown next header values if 
protection against rogue DHCPv6 packets is the ONLY purpose of the 
device, but it MAY default to blocking such packets (in accordance 
with RFC 7045) if other functionality is included.  In any case, the 
behaviour MUST be user configurable (per RFC 7045).

In my opinion, it's truly unfortunate that new IPv6 extension 
headers have not been banned outright in favor of using new 
destination options or upper layer protocol headers.  That would 
make the correct action in this case unambiguous: pass the packet, 
as it's some protocol other than DHCPv6.  RFC 6564 leaves the 
possibility of new extension headers open but raises they very high 
bar of proving that a new destination option or upper layer protocol 
header won't work.  As far as I can see, that is an impossible bar 
to get over.

> The fact that RA guard gives bad advice is no reason for the bad 
> advice to be repeated in this document.

I agree that the advice should be the same.

Mike Heard

---

From: Ted Lemon <[email-masked]>
Date: Sun, 8 Feb 2015 14:24:11 -0500

> an unknown next header value.

This may or may not be true, but to the extent that it's true, it's already addressed in RFC 7045, and it's addressed correctly there.   There is no need to strengthen the advice in RFC 7045 here, which this document currently does, and indeed this is completely unrelated to the supposed purpose of the document, which is to prevent DHCP packets sent by unauthorized servers from reaching clients.

If indeed RFC 7045 is too weak and needs to be strengthened, the place to do that is in 6man, not in opsec.   Fernando tried to do that in 6man and got no traction.   If we were to allow that to be done here, it would effectively be an end-run around the 6man working group.

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 8 Feb 2015 15:21:46 -0800 (PST)

> > assumes it is an extension header following the format in RFC 6564.  
...
> This may or may not be true, but to the extent that it's true, 
> it's already addressed in RFC 7045, and it's addressed correctly 
> there.  There is no need to strengthen the advice in RFC 7045 
> here, which this document currently does, and indeed this is 
> completely unrelated to the supposed purpose of the document, 
> which is to prevent DHCP packets sent by unauthorized servers from 
> reaching clients.

Would your objections be addressed if Section 3 of the draft were 
replaced by something along the lines of the following?

=============================== cut here ===============================
3.  When parsing the IPv6 header chain, if the packet contains an
    unrecognized Next Header value, DHCPv6-Shield MUST be configurable
    to pass the packet.  The default configuration MAY drop such packets.
    When such a packet is dropped, DHCPv6-Shield SHOULD log the packet
    drop event in an implementation-specific manner as a security alert.

          RATIONALE: An unrecognized Next Header value could possibly
          identify an IPv6 Extension Header, and thus be leveraged to
          conceal a DHCPv6-server packet that should be dropped, or it
          may identify an unrecognized upper layer protocol, which
          should be passed.  There is no reliable way to tell the
          difference.  The advice given here is consistent with the
          requirements levied by [RFC7045] on forwarding nodes with
          respect to handling of unrecognized extension headers.

4.  When parsing the IPv6 header chain, if the packet is identified
    to be a DHCPv6 packet meant for a DHCPv6 client, DHCPv6-Shield MUST
    drop the packet, and SHOULD log the packet drop event in an
    implementation-specific manner as a security alert.
=============================== cut here ===============================

//cmh

---

From: Ted Lemon <[email-masked]>
Date: Sun, 8 Feb 2015 20:30:13 -0500

> replaced by something along the lines of the following?

No.   This is not a draft about filtering extension headers.  It is a draft about filtering DHCP.   The two are unrelated, and should not be discussed as if they were related.

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 9 Feb 2015 09:33:04 +0800

> Le 2015-02-09 à 09:30, Ted Lemon <[email-masked]> a écrit :
> 

I agree with Ted’s point above. The draft is about dhcpv6 not extension headers. 

Regards, Marc.

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 8 Feb 2015 17:47:08 -0800 (PST)

On Mon, 9 Feb 2015, Marc Blanchet wrote:
> > No.  This is not a draft about filtering extension headers.  It 
> > is a draft about filtering DHCP.  The two are unrelated, and 
> > should not be discussed as if they were related.
> 
> I agree with Tedÿÿs point above. The draft is about dhcpv6 not extension headers. 

Yes, but there is a situation in which it is not possibile to make a 
positive identification where a given packet is or is not a DHCPv6 
packet.  This should be pointed out to implementors, and the 
relevant requirements from RFC 7045 should be noted.

I think I've made it amply clear that I disagree with the DISCUSS as 
it is currently written.  I will now shut up and let others speak.

//cmh

---

From: Ted Lemon <[email-masked]>
Date: Sun, 8 Feb 2015 23:14:11 -0500

On Feb 8, 2015, at 8:47 PM, C. M. Heard <[email-masked]> wrote:
> packet.

Can you carefully describe in detail how this could happen?

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 09 Feb 2015 17:58:39 +1300

> Can you carefully describe in detail how this could happen?

Ted, I think we have to say Hi to the elephant in the corner of the
room. There is a fundamental flaw in the IPv6 design, which is that
there is no way, in the general case, to distinguish an unknown
extension header from an unknown upper layer protocol. Now this
doesn't matter too much in a middlebox-free Internet, since (with the
well-specified exception of the hop-by-hop header) nobody ever needs
to make that distinction, since unknowns cause a packet drop at the
destination anyway. Steve Deering told me in Vancouver that this is
just fine, because middleboxes are evil anyway. But that doesn't
wash. A middlebox that is trying to flush out a specific type of
upper layer protocol (such as DHCPv6) needs to parse all extension
headers, including ones it doesn't understand, in case there is
an instance of the upper layer protocol behind it.

In the real world, that means that such middleboxes, if they are
of the paranoid security persuasion, will discard packets that,
as far as they are concerned, are unparseable.

I'm afraid that IETF documents that don't recognise this fact of life
will not be taken seriously.

    Brian

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Feb 2015 00:01:43 -0500

On Feb 8, 2015, at 11:58 PM, Brian E Carpenter <[email-masked]> wrote:
> A middlebox that is trying to flush out a specific type of

Can you explain, in detail, what a DHCPv6 packet would look like that would get past a filter because either it used unknown extension headers, or an unknown protocol header?

---

From: Pete Resnick <[email-masked]>
Date: Sun, 8 Feb 2015 23:04:14 -0600

On 2/8/15 11:01 PM, Ted Lemon wrote:
> On Feb 8, 2015, at 11:58 PM, Brian E Carpenter<[email-masked]>  wrote:
>    

Better yet, could you give an example packet with a fake new extension 
header that a middlebox would think is not a DHCPv6 packet, but in fact is?

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 8 Feb 2015 22:02:04 -0800 (PST)

On Sun, 8 Feb 2015, Pete Resnick wrote:
> > Can you explain, in detail, what a DHCPv6 packet would look like that would
> > get past a filter because either it used unknown extension headers, or an
> > unknown protocol header?
> >    
> 
> Better yet, could you give an example packet with a fake new extension header
> that a middlebox would think is not a DHCPv6 packet, but in fact is?

Not with a fake extension header, but with a real one.  Suppose:

- A new extension header is defined that make sense to sandwich in 
  front of a DHCPv6 packet (not all do; some extension headers are 
  required to have a next header value of "no next header")

- This extension header is unknowm to a DHCPv6-Shield implementation

- This is extension header is known and considered valid by a host 
  that DHCPv6-Shield implementation is trying to protect

If I correctly understand Ted's position, he is saying that a 
DHCPv6-Shield implementation should unconditionally pass a packet 
containing a next header value it does not recognize.  In that case, 
a DHCPv6 packet containing the hypothesized new extension header 
described above would pass through the DHCPv6-Shield implementation 
and be processed by the host.

The current DHCPv6-Shield draft (and the variant language I proposed 
a few messages back) takes the position that whether a DHCPv6-Shield 
implementation passes a packet with an unknown next header value 
must be a user configurable option.  Some users may consider the 
above scenario too improbable to worry about and configure packets 
with unknown next header values to be passed.  Other users of a more 
paranoid persuation may have a different point of view.

Sorry, I said I was going to shut up.  Now I will.

//cmh

---

From: Brian Haberman <[email-masked]>
Date: Mon, 09 Feb 2015 08:12:00 -0500

Let me chime in here with two points...

>   that DHCPv6-Shield implementation is trying to protect

The above is a typical scenario where different code bases update their
capabilities on different time scales.  Any time a new feature/function
is added, there will be a risk of incompatible functionality within the
set of devices that compose the network path from source to destination.

> and be processed by the host.

I have interpreted Ted's position to be that this document should simply
point to RFC 7045 (or its successor) for handling unknown extension headers.

Regards,
Brian

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Feb 2015 09:41:53 -0500

>  that DHCPv6-Shield implementation is trying to protect

In addition to being known by the host, the extension header would have to be a standard extension header that does not conform to RFC 6564.   Otherwise, the switch can just skip over it even though it's nominally "unknown."   Having skipped over it, it would correctly reach the UDP protocol header, and notice that the packet was a DHCP packet.

I think it's safe to assume that no future extension header that is standardized will fail to conform to RFC 6564.   Hence, we do not need to worry that the host will be able to parse a new extension header, but that the DHCPv6-shield device will not.   Hence, there is no need to drop packets with unknown extension headers.

This is particularly important, because in dropping packets with unknown extension headers, we are _also_ dropping packets with unknown protocol headers.   That is the real harm of the language of the document as it is currently written.

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 9 Feb 2015 07:08:11 -0800 (PST)

> point to RFC 7045 (or its successor) for handling unknown extension headers.

I am probably confused, but the intended substance of the proposal 
in http://www.ietf.org/mail-archive/web/opsec/current/msg01819.html 
was just that, and it got rejected.

//cmh

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 9 Feb 2015 08:11:20 -0800 (PST)

On Mon, 9 Feb 2015, Ted Lemon wrote:
> In addition to being known by the host, the extension header would 
> have to be a standard extension header that does not conform to 
> RFC 6564.  Otherwise, the switch can just skip over it even though 
> it's nominally "unknown."

That, unfortunately, is not true, as I have been trying repeatedly 
to explain.

When the switch encounters an unknown next header value, it does not 
know if that refers to a new extension header, which is required to 
conform to the format of RFC 6564, or an upper layer protocol 
header, which is NOT required to conform to RFC 6564.  As I argue in 
http://www.ietf.org/mail-archive/web/opsec/current/msg01817.html, 
the switch opens itself up to DOS attacks if it assumes that any 
unknown header in the chain conforms to RFC 6564 and attempts to 
continue parsing the header chain.

RFC 6564 gives the misleading impression that it actually solves a 
problem.  It does not.  This is at least the third time I've seem 
this discussion has come up.  For that reason it's time to retire 
RFC 6564, but that of course is a job for 6man, not opsec.

There was some discussion of this problem in 6man -- one proposal 
was draft-gont-6man-rfc6564bis, discussed Feb-May 2014 (see, e.g., 
http://www.ietf.org/mail-archive/web/ipv6/current/msg20710.html).  
6man never came to consensus that the problem was sufficiently 
important to solve, but I think the current discussion has 
hughlighted the importance of putting it to rest.  Secifically:

> ... in dropping packets with unknown extension headers, we are 
> _also_ dropping packets with unknown protocol headers.  That is 
> the real harm of the language of the document as it is currently 
> written.

THAT is a very a real problem in an Internet full of middleboxes.  
It would be fixed if the set of extension headers were closed off to 
further expansion.  Multiple technically viable ways to do this 
without sacrificing functionality have been proposed; this 
discussion sould, I hope, provide the motivation needed to get 6man 
to adopt one of those solutions (or something similar).

Sorry for the digression, but I think it was necessary to understand 
the problem.

//cmh

---

From: joel jaeggli <[email-masked]>
Date: Mon, 09 Feb 2015 08:33:49 -0800

On 2/9/15 8:11 AM, C. M. Heard wrote:
> header, which is NOT required to conform to RFC 6564.

So the problem I have in application is if i'm applying an acl with an
L4 rule I have to find the upper layer header. If I can't parse the
header chain the packet is hitting a drop rule. if I can jumper over a
header due to 6564 and find the the L4 header then great, if I can't,
that packet is getting dropped.

>  As I argue in 

in a device such a switch, I'm going to have to give up long before this
happens becasue the amount of the packet going towards the header
processing is only 64/128/256 bytes so I'm going to drop it if I don't
have that offset available to me.

I do think what you describe is a serious problem.

We do have a bunch of dos options to avail ourselves of on devices that
can be assumed to be capable of processing arbitrary header chains. If
such devices existed in my network I'd have to protect them with much
simpler devices.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Feb 2015 11:44:52 -0500

> continue parsing the header chain.

Yes, you made this argument.   But how does this constitute a DoS attack?   You have a 1500 byte packet, and you have some kind of fast-path hardware that's trying to parse the packet. At some point it will either succeed or fail.   Most such hardware doesn't even look very far into the packet--maybe 256 bytes at most.

I asked you earlier in this conversation to describe a specific attack, not make general speculations.   Can you describe a specific attack here and explain why it is bad?   Remember that we are specifically talking about filtering DHCPv6 here, not solving the general problem of eliminating possibly bogus packets at the switching fabric so that hosts don't see them.

Remember too that the packet has to actually be _valid_ when it's forwarded to the host: it's not sufficient that it simply make it through the filter.   Otherwise the host will not see it as a DHCPv6 packet, and the shield will have succeeded even though it passed the packet.   So the packet has to use a valid chain of extension headers that the host can successfully parse, even if they are unknown to the switch.

Can you describe an attack that works in the presence of all these requirements?

---

From: Fernando Gont <[email-masked]>
Date: Mon, 09 Feb 2015 15:16:45 -0300

Ted,

Please let me describe a scenario for an attack that would work if we
don't enforce the filtering rules from the current version of the I-D.

Before getting into the specific details, please let me provide some
background.

** Background **

* As have been noted multiple times, IPv6 Extension Headers and
Transport Protocols share the same name space. Given an
unrecognized/unknown EH/Protocol type, there's no way for you to know
how to parse it: since it could be ether an EH, or a transport protocol.

* RFC6564 has a major flaw, since it defines a "unified format for EHs".
But per the above, it is impossible to tell when you should assume that
what follows is an EH (in RFC6564 format) or a new transport protocol.

* There's nothing that we can do to fix RFC6564 itself in this respect.
The only possible option is to replace RFC6564 with something such as:
<https://tools.ietf.org/id/draft-gont-6man-rfc6564bis-00.txt>.
Regardless of whether the IETF decides to fix this problem or not, the
problem is there.

* If you assume that an unrecognized header follows the format in
RFC6564, you will hurt the deployment of new transport protocols.

* RFC7045 is the current IETF advice on the topic. DHCPv6 shield
complies with it -- as noted a few times... even by Brian Carpenter
(co-author of the aforementioned document). If you disagree with what
DHCPv6-shield is currently doing, you're essentially disagreeing with
6man's advice on the topic.

** Attack scenario **

1) Let us assume that either a new EH that doesn't follow RFC6564 is
specified (since, as noted, RFC6564 doesn't buy you anything), or that
the proposal in draft-gont-6man-rfc6564bis-00 gets standardized, and
hence new EHs follow the EH format in that document.

2) Such EH, according to the rules you had proposed (namely "assume
RFC6564 for unrecognized headers"), would be passed/allowed, since it
would be considered a "transport protocol" rather than an EH.

3) Now, let us assume that such EH has been implemented by a target
host. An attacker could send a DHCPv6-server packet with includes one of
the aforementioned EHs. The DHCPv6-shiled device would (according to
your rules) pass this packet, and the target host would receive it.

4) As a result of the above, an attacker would have been able to sneak a
DHCPv6-server packet past the DHCPv6 shield device.

This is an attack vector we mean to block. The current version of
DHCPv6-shield would block it. If we were to modify the document as you
suggest, it wouldn't.

Thanks,
Fernando

---

From: Fernando Gont <[email-masked]>
Date: Mon, 09 Feb 2015 15:57:27 -0300

On 02/08/2015 04:24 PM, Ted Lemon wrote:
>>  assumes it is an extension header following the format in RFC
>> 6564. If the value of the 2nd octet of the unknown header is v,
>> then it won't appear malformed if at least 8*(v+1) bytes remain in
>> the packet, starting from the beginning of the unknown header.  At
>> that point the device would be interpreting the payload of the
>> unknown upper layer PDU as an extension header chain.  In the
>> benign case where the packet is a legitimate one with an upper
>> layer protocol unknown to the device, it is likely (but not
>> assured) that the chain would quickly terminate in something that
>> looks like a malformed extension header.  However, it would not be
>> difficult to craft a packet that makes a very long apparent header
>> chain.  Depending on how the device processes header chains, that
>> could easily be a vector for DOS attacks -- e.g., by consuming
>> processing resources or by exercising a rarely used processing
>> path.  That is why I think it is UNSAFE to continue processing a
>> header chain after encountering an unknown next header value.
> 
> This may or may not be true, but to the extent that it's true, it's
> already addressed in RFC 7045, and it's addressed correctly there.
> There is no need to strengthen the advice in RFC 7045 here, which
> this document currently does

Why do you think this document "strengthens the advice in RFC7045", as
opposed to it actually *complying* with what's in RFC7045?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 09 Feb 2015 16:08:54 -0300

Hi, Brian,

On 02/09/2015 10:12 AM, Brian Haberman wrote:
[....]
>>> Better yet, could you give an example packet with a fake new
>>> extension header that a middlebox would think is not a DHCPv6
>>> packet, but in fact is?
>> 
>> - A new extension header is defined that make sense to sandwich
>> in front of a DHCPv6 packet (not all do; some extension headers
>> are required to have a next header value of "no next header")
>> 
>> - This is extension header is known and considered valid by a
>> host that DHCPv6-Shield implementation is trying to protect
> 
> The above is a typical scenario where different code bases update
> their capabilities on different time scales.  Any time a new
> feature/function is added, there will be a risk of incompatible
> functionality within the set of devices that compose the network
> path from source to destination.

Exactly. The same applies to Ted's concern: the newly-specified IPv6
EH would be "incorporated" by DHCPv6 implementations and hence would
not be dropped.

>>  containing a next header value it does not recognize.  In that
>> case, a DHCPv6 packet containing the hypothesized new extension
>> header described above would pass through the DHCPv6-Shield
>> implementation and be processed by the host.
> 
> I have interpreted Ted's position to be that this document should
> simply point to RFC 7045 (or its successor) for handling unknown
> extension headers.

It doesn't seem to be so.

Brian Carpenter himself (co-author of RFC7045) noted that we comply
with RFC7045. We simply state what the default should be, and
normatively reference RF7045, since that's the document on which we've
based our requirements.

So I don't understand what's the issue here, since we *are* complying
with the current (6man's) recommendations on the topic.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 09 Feb 2015 16:14:55 -0300

On 02/09/2015 11:41 AM, Ted Lemon wrote:
> have to be a standard extension header that does not conform to RFC
> 6564.   Otherwise, the switch can just skip over it even though it's
> nominally "unknown."   Having skipped over it, it would correctly
> reach the UDP protocol header, and notice that the packet was a DHCP
> packet.
> 
> I think it's safe to assume that no future extension header that is
> standardized will fail to conform to RFC 6564.

It is not. As noted, RFC6564 doesn't buy you anything. And if we decide
to fix the problem in question (e.g., as described in
draft-gont-6man-rfc6564bis-00.txt), then I can guarantee that new IPv6
EHs will *not* follow the format in RFC6564.

(And I'd say that "assumptions" have been the source of most security
flaws in protocols and implementations I've seen).

> Hence, we do not
> need to worry that the host will be able to parse a new extension
> header, but that the DHCPv6-shield device will not.   Hence, there is
> no need to drop packets with unknown extension headers.
> 
> This is particularly important, because in dropping packets with
> unknown extension headers, we are _also_ dropping packets with
> unknown protocol headers.   That is the real harm of the language of
> the document as it is currently written.

You can't be worried about new transport protocols and at the same time
support RFC6564. If you assume that new EHs will follow RFC6564, then
you're banning *from scratch* deployment of new transport protocols (!).

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Feb 2015 14:23:28 -0500

> hence new EHs follow the EH format in that document.

Come on, Fernando, this is ridiculous.   RFC 6564 is normative.   We should not expect new EHs to be standardized that do not conform with RFC 6564.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Feb 2015 08:47:49 +1300

> Come on, Fernando, this is ridiculous.   RFC 6564 is normative.   We should not expect new EHs to be standardized that do not conform with RFC 6564.

Fair enough. But let's just say that DHCPv6 Shield sees a Next Header
value of 253. How does it know where to look for a potential UDP
header with port 546?

If you don't like 253 as an example, how about 143, or any
other value that isn't listed at
http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header

I simply don't believe that any security product designer will do
anything except give up and discard the packet. Don't we want RFCs
to live in the real world?

    Brian

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Feb 2015 14:52:39 -0500

> value of 253. How does it know where to look for a potential UDP

Either the next header is an unknown EH conforming to RFC 6564, or else it is a protocol header.   If it is a protocol header, then it is an unknown protocol header, and therefore not a UDP header.   If it conforms to RFC 6564, then it can be successfully skipped, whether or not it is known.

> to live in the real world?

We want RFCs to recommend the right thing.   It is likely true that at present, the implementor of a switch that implements DHCPv6 shield may cut some corners on processing of unknown headers.   However, this is not something the IETF should recommend they do, because our recommendations will last longer than the current state of the art.   There is no reason to cast the limitations of the current state of the art in stone.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 09 Feb 2015 17:26:46 -0300

On 02/09/2015 04:52 PM, Ted Lemon wrote:
>> Fair enough. But let's just say that DHCPv6 Shield sees a Next
>> Header value of 253. How does it know where to look for a potential
>> UDP header with port 546?
> 
> Either the next header is an unknown EH conforming to RFC 6564, or
> else it is a protocol header.

Are we in agreement that if RFC6564 is deployed, we say "bye bye" to new
transport protocols?

And if we are, is that the path you want to follow?

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Feb 2015 10:41:27 +1300

> Either the next header is an unknown EH conforming to RFC 6564, or else it is a protocol header.   If it is a protocol header, then it is an unknown protocol header, and therefore not a UDP header.…

OK Ted, then please provide the pseudo-code for making that
determination:

  if ???? then #it's an unknown extension header conforming to RFC 6564
          else #it's an unknown transport protocol;

    Brian

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Feb 2015 10:37:15 -0500

> was just that, and it got rejected.

Can we _please_ understand the problem before arguing about the solution?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Feb 2015 18:32:07 -0500

>          else #it's an unknown transport protocol;

Apologies if there are horrific buffer overflow bugs, but here's roughly how you would do it:

// return true if it's a dhcpv6 packet that we should drop
BOOL
guard_p(int next_header_type, u_int8_t *bufp, int buflen)
{
  int header_len;
  // no space for a valid protocol or extension header?
  if (buflen < 2)
    return false;
  if (next_header_type == 59)
    return false;
  if (udp_p(next_header_type))
    return dhcpv6_guard_p(bufp, buflen);
  if (known_proto_header_type_p(next_header_type))
    return false;
  if (known_extension_header_type_p(next_header_type))
    {
      header_len = header_extension_len(next_header_type, bufp, buflen);
      // evidently malformed header?
      if (header_len == 0)
        return false;
      // tail call to check next header
      return guard_p(known_extension_header_next_type(next_header_type, bufp, buflen),
                     bufp + header_len, buflen - header_len);
    }
  // tail call to check presumed RFC 6564 header.
  // if it's actually an unknown protocol header, we may 
  // have to parse over some garbage before running off
  // the end of the packet and returning false.
  // It may also be deliberate garbage, in which case the
  // same thing will happen, but possibly more slowly.
  return guard_p(bufp[0], bufp + bufp[1], buflen - bufp[1]);
}

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Feb 2015 18:35:48 -0500

should be:

>  return guard_p(bufp[0], bufp + bufp[1] + 2, buflen - bufp[1] - 2);

---

From: Fernando Gont <[email-masked]>
Date: Mon, 09 Feb 2015 20:48:52 -0300

On 02/09/2015 08:32 PM, Ted Lemon wrote:
[....]
>   // same thing will happen, but possibly more slowly.

You're essentially proposing a hack to fix a known protocol design flaw,
instead of accepting the flaw, and allow DHCPv6-shield to comply with
the existing specifications/requirements (RFC7045).

  -- all this under the assumption that RFC6564 gets deployed. In which
case you're essentially declaring "game over" for any new transport
protocol.

I'll just reference this:
<http://www.ietf.org/mail-archive/web/opsec/current/msg01834.html>. And
note that you're arguing against 6man's advice in RFC7045.

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Feb 2015 19:02:42 -0500

> the existing specifications/requirements (RFC7045).

How is this a hack?   It correctly identifies all DHCPv6 packets.   The solution I've proposed is completely in compliance with RFC 7045.   If you want to argue that a solution is wrong, you should say what is wrong with it, not refer to it as a "hack" as if merely by calling it a "hack," you have somehow shown that it is not a good solution.

> case you're essentially declaring "game over" for any new transport

Er, no, the point of this is to _not_ break new transport protocols.   RFC 7045 does not deprecate RFC 6564.   If you want to deprecate RFC 6564, please go do the work in the appropriate venue.   It's my understanding, however, that you already tried this, and did not get consensus to even adopt your proposal as a working group work item.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 09 Feb 2015 21:27:16 -0300

On 02/09/2015 09:02 PM, Ted Lemon wrote:
>> You're essentially proposing a hack to fix a known protocol design
>> flaw, instead of accepting the flaw, and allow DHCPv6-shield to
>> comply with the existing specifications/requirements (RFC7045).
> 
> How is this a hack? 

How can you positively tell whether what follow is an EH or a transport
protocol? -- You simply can't.

In your code, you assume that because something seems to be parseable by
the RFC6564 syntax, it does follow the RFC6564 syntax. And of course
that's, if anything, a hack. If there's a transport protocol that
happens to look like RFC6564, and it is followed by data that looks like
DHCPv6/UDP, your code will fail.

Your code also assumes that RFC6564 will the deployed, when
hepefuly/chances_are_that it won't. -- Because deploying RFC6564 would
essentially say "bye bye" to any new transport protocols. I keep
repeating it, and you keep ignoring it.

The question is: Are we in agreement that deploying RFC6564 would
prevent us developing any new transport protocols? And, if so, is that
what you want?

>> -- all this under the assumption that RFC6564 gets deployed. In
>> which case you're essentially declaring "game over" for any new
>> transport protocol.
> 
> Er, no, the point of this is to _not_ break new transport protocols.
> RFC 7045 does not deprecate RFC 6564.

That doesn't eliminate the flaw in RFC6564. Please see my two questions
above.

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Feb 2015 19:51:25 -0500

On Feb 9, 2015, at 7:27 PM, Fernando Gont <[email-masked]> wrote:
> If there's a transport protocol that

You mean if there is an unknown transport protocol header that looks like RFC 6564, and it is followed by a next header type of UDP, and that UDP packet happens to be a well-formed DHCP packet, and happens to match the criteria of DHCPv6-guard, then the switch will drop it?   Yes, this is true.   However, in your proposal, the switch will also drop it, so we haven't lost anything.  Moreover, this is easy to fix: update the switch to support the new protocol header.  (Yes, I realize that my definition of easy is a bit optimistic, but under the circumstances I think that's okay.)

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Feb 2015 19:52:37 -0500

> repeating it, and you keep ignoring it.

I keep ignoring it because you keep asserting it without explaining why you believe it to be true.

> prevent us developing any new transport protocols? And, if so, is that

No, we are not in agreement about this.

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 9 Feb 2015 18:51:24 -0800 (PST)

On Mon, 9 Feb 2015, Ted Lemon wrote:
>   return guard_p(bufp[0], bufp + bufp[1] + 2, buflen - bufp[1] - 2);> 
> }
[ final statement corrected as indicated in subsequent e-mail ]

I think this pseudo-code pretty clearly makes the point I was trying 
to make about DOS attacks on the DHCPv6-Sheild engine.  In an 
earlier message, you wrote:

> I asked you earlier in this conversation to describe a specific 
> attack, not make general speculations.

OK.  Here is a crafted packet that will make things go slowly:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    6  | Traffic Class |           Flow Label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                880            |     143       |   Hop Limit   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                         Source Address                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      Destination Address                      +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      144      |       0       |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      145      |       0       |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      252      |       0       |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       59      |       0       |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If I counted correctly, this "packet" uses all 110 unassigned 
protocol numbers (aka next header values).  It would be easy to 
include more or fewer headers.  Or make the last header length point 
outside the packet.

Note that this is not an attack on the destination host.  The 
destination host should drop the packet immediately upon 
encountering an unknown next header value.  Rather, it is an attack 
on the DHCPv6-Shield engine, which has to do a lot of work to figure 
out what to do with this packet.  Is a typical implementation robust 
enough to deal with a line-rate stream of stuff like this?  Do 
implementations with hardware accelerators (and limited header 
memory) suffer no adverse effects at all?  What do they do if the 
header chain won't fit?  I'm sure the effects vary greatly, but is 
is really true that this attack is nothing to worry about?

//cmh

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Feb 2015 22:09:41 -0500

> is really true that this attack is nothing to worry about?

I think what will happen in practice is that there will be some fast-path logic that looks at the first 256 bytes of the packet at most, and probably discards it if it can't be made sense of by the end of those 256 bytes.   I am completely okay with that.   What I am not okay with is advocating this behavior in a BCP.

AFAIK existing implementations of DHCPv6-shield already do this.

---

From: joel jaeggli <[email-masked]>
Date: Mon, 09 Feb 2015 20:56:02 -0800

On 2/9/15 7:09 PM, Ted Lemon wrote:
>> include more or fewer headers.  Or make the last header length
>> point outside the packet.
>> 
>>  on the DHCPv6-Shield engine, which has to do a lot of work to
>> figure out what to do with this packet.  Is a typical
>> implementation robust enough to deal with a line-rate stream of
>> stuff like this?  Do implementations with hardware accelerators
>> (and limited header memory) suffer no adverse effects at all?  What
>> do they do if the header chain won't fit?  I'm sure the effects
>> vary greatly, but is is really true that this attack is nothing to
>> worry about?
> 
> I think what will happen in practice is that there will be some
> fast-path logic that looks at the first 256 bytes of the packet at
> most, and probably discards it if it can't be made sense of by the
> end of those 256 bytes.   I am completely okay with that.   What I am
> not okay with is advocating this behavior in a BCP.

We do ourselves and the community a disservice when we fail to include
discussion  of operational divergence from expected behavior. if whe can
find a position that falls short of advocacy where does that leave us?

> AFAIK existing implementations of DHCPv6-shield already do this.

Yeah exactly.

> _______________________________________________ OPSEC mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/opsec
>

---

From: Brian Haberman <[email-masked]>
Date: Tue, 10 Feb 2015 09:48:54 -0500

> opposed to it actually *complying* with what's in RFC7045?

Perhaps the issue is that not everyone has read 7045 recently.  The
primary piece of advice in 7045 is section 2.1
(http://tools.ietf.org/html/rfc7045#section-2.1), which I summarize as:

1. A forwarding node SHOULD forward all packets regardless of whether
there are extension headers present or not.

2. If a forwarding node examines the packet it MUST recognize all
standard extension headers and SHOULD recognize all experimental
extension headers.

3. Intermediate nodes SHOULD NOT discard a packet containing
unrecognized extension headers.

4. If the intermediate node discards a packet containing a standard
extension header, it MUST be because of a configurable policy.

5. The discard policy for each standard extension header MUST be
individually configurable.  The default configuration SHOULD allow all
standard extension headers.

6. Forwarding nodes MUST be configurable to allow unrecognized extension
headers. The default configuration MAY be to drop packets containing them.

Regards,
Brian

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 10 Feb 2015 09:25:53 -0800 (PST)

> find a position that falls short of advocacy where does that leave us?

Allow me to point out that a device that is unable to parse the entire 
IPv6 header chain is not compliant with the draft as now written:

   1.  DHCPv6-Shield MUST parse the entire IPv6 header chain present in
       the packet, to identify whether it is a DHCPv6 packet meant for a
       DHCPv6 client (i.e., a DHCPv6-server message).

          RATIONALE: DHCPv6-Shield implementations MUST NOT enforce a
          limit on the number of bytes they can inspect (starting from
          the beginning of the IPv6 packet), since this could introduce
          false-negatives: DHCP6-server packets received on ports not
          allowed to receive such packets could be allowed simply
          because the DHCPv6-Shield device does not parse the entire
          IPv6 header chain present in the packet.

The implication is that if the header chain exceeds the size that 
can be looked at with fast-path logic, the packet would need to be 
kicked onto a slow path -- where the potential DoS exposure that 
I've pointed out would very likely be a real problem.

//cmh

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Feb 2015 12:48:56 -0500

> find a position that falls short of advocacy where does that leave us?

I would suggest a note in the security considerations section that says something like this:

The recommendations in this document represent the ideal behavior of a DHCPv6 shield device. However, in order to implement DHCPv6 shield on the fast path, it may be necessary to limit the depth into the packet that can be scanned before giving up.   In circumstances where there is such a limitation, it is recommended that implementations drop packets after attempting to find a protocol header (as opposed to an extension header) up to that limit, whatever it is.

Ideally, such devices should be configurable with a list of protocol header identifiers so that if new transport protocols are standardized after the device is released, they can be added to the list of protocol header types that the device recognizes.  Since any protocol header that is not a UDP header would be passed by the DHCPv6 shield algorithm, this would allow such devices to avoid blocking the use of new transport protocols.

When an implementation must stop searching for recognizable header types in a packet due to such limitations, whether the device passes or drop that packet SHOULD be configurable.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Feb 2015 15:38:04 -0300

Hi, Ted,

On 02/10/2015 02:48 PM, Ted Lemon wrote:
>> We do ourselves and the community a disservice when we fail to
>> include discussion  of operational divergence from expected
>> behavior. if whe can find a position that falls short of advocacy
>> where does that leave us?
> 

Your suggestion sounds very sensible. I have a couple of questions
below, though:

> The recommendations in this document represent the ideal behavior of
> a DHCPv6 shield device. However, in order to implement DHCPv6 shield
> on the fast path, it may be necessary to limit the depth into the
> packet that can be scanned before giving up.   In circumstances where
> there is such a limitation, it is recommended that implementations
> drop packets after attempting to find a protocol header (as opposed
> to an extension header) up to that limit, whatever it is.

Not sure what the "(as opposed to an extension header)" means. Could you
elaborate/clarify a bit?

> Ideally, such devices should be configurable with a list of protocol
> header identifiers so that if new transport protocols are
> standardized after the device is released, they can be added to the
> list of protocol header types that the device recognizes.  Since any
> protocol header that is not a UDP header would be passed by the
> DHCPv6 shield algorithm, this would allow such devices to avoid
> blocking the use of new transport protocols.

So in summary, this argues in favor of DHCPv6-Shield not having only a
hardcoded list of protocols/EHs that it should pass, but to also allow
that list to be expanded, so to speak, right?

If so, that's sensible, too. The only thing that I'd probably change is
s/transport protocols/Next Header values that do not represent Extension
Headers/, since it's more general (e.g., something new protocol ala
ICMPv6 should be passed.. but ICMPv6 is not a transport protocol).

> When an implementation must stop searching for recognizable header
> types in a packet due to such limitations, whether the device passes
> or drop that packet SHOULD be configurable.

Should we say anything about the default setting? From a security
standpoint, it shoudl clearly default to "drop".. otherwise
DHCPv6-Shield would be easily evasible by inserting an appropriate
number of IPv6 EHs.

Thoughts?

Thanks!

Best regards,

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 10 Feb 2015 11:14:37 -0800 (PST)

> ICMPv6 should be passed.. but ICMPv6 is not a transport protocol).

Yes indeed, the problems we've been arguing about all get solved 
satisfactorily if the device sports a table that allows each of the 
undefined Next Header values to be be treated either as identifying 
either an upper-layer protocol, which should be passed, or as an 
extension header that follows the rules of RFC 6564, which can be 
skipped while parsing the header chain.

For the purposes of this discussion, "undefined Next Header values" 
means the values in the Protocol Numbers registry 
(http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml) 
that at the time of implementation are unassigned, PLUS the 
experimental values 253 and 254 (which could be either an 
experimental extension header or an experimental protocol), PLUS the 
reserved value 255.  Currently that would be 143 and up.

> > or drop that packet SHOULD be configurable.

I would say MUST be configurable, otherwise it cannot comply with 
RFC 7045.

> DHCPv6-Shield would be easily evasible by inserting an appropriate

I would be fine with lifting the agnostic "the default configuration 
MAY drop such packets" from RFC 7045 but I am not wedded to this.

//cmh

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Feb 2015 15:49:53 -0500

> Not sure what the "(as opposed to an extension header)" means. Could you

What I'm proposing is that unknown codes can be assumed to be extension headers.   Any known code may be either an extension header or a protocol header, but then it's a known code, so not a problem.   But rereading the text, that parenthetical does seem unnecessary.

Anyway, it sounds like we now have some text to argue about that we might be able to agree on, so I will defer to you on tweaking it--I just wanted to give you a sense of what I had in mind.   The main thing I want to avoid is a recommendation that the basic shield algorithm by default drop unknown extension and transport headers, but I agree that it's good to say what to do if the hardware can't support that fully.

---

From: joel jaeggli <[email-masked]>
Date: Tue, 10 Feb 2015 18:46:09 -0800

> No.   This is not a draft about filtering extension headers.  It is a draft about filtering DHCP.   The two are unrelated, and should not be discussed as if they were related.
This is the peril of getting a little far afield. I think we can solve
the dhcpv6 problem discussion with a more narrowly scoped attack on the
text.