Subject: Moving forward draft-ietf-6man-oversized-header chain?

From: Fernando Gont <[email-masked]>
Date: Mon, 04 Feb 2013 16:27:26 -0300

Folks,

I was wondering what's the status of draft-ietf-6man-oversized-header-chain.

Was it ready to ship to the IESG? Or does it still need to be WGLC'ed?

FWIW, this I-D has been stable for a few months now, and quite a few
folks agreed that it was ready to progress.

Thanks!

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

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 6 Feb 2013 20:22:45 +0000

Hi Fernando,

If the chairs were to initiate a last call, I would support this document.

Maybe the chairs can comment?

                             Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Fernando Gont
> Sent: Monday, February 04, 2013 2:27 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Moving forward draft-ietf-6man-oversized-header chain?
> 
> Folks,
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Ole Troan <[email-masked]>
Date: Wed, 6 Feb 2013 22:29:39 +0100

Ron,

thanks for the reminder.

> Maybe the chairs can comment?

Bob and I will discuss progress on this document in our call next week.

Best regards,
Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 6 Feb 2013 22:51:05 +0100

while we are on the topic, and you made me re-read the document.

section 4:
issues with terminology. call a device that walks the extension header chain something else than a router.
rfc2460 definition of a router; "extension headers are not examined or processed by any node along a packet's delivery path".
a switch in my book doesn't look at L3 headers.
use "middlebox" or "filtering router"?

section 3:
is the main justification for this work to make NAT64s function better? if so that might be a little short-sighted, by the time we've updated IPv6 implementations... perhaps use a different example than NAT64?

section 5:
restricting the header chain seems like an incomplete solution. doesn't a middlebox need to reassembly fragments anyway,
to deal with mis-ordered fragments?
at least at some point I thought BSD sent fragmented packets by sending the last fragment first.

with a more idealist hat on:
that extension headers are hard to parse, some consider a feature of IPv6.
a feature that tries to protect the end to end Internet, i.e. that we can deploy new transport protocols and extension
headers without upgrading all intermediate boxes. changing the IPv6 protocol for a flawed design (aka middleboxes), is that wise?
might as well just deprecate IP fragmentation. (which I would be in favour of).

and don't get me wrong, I can't imagine any use case for an extension header chain longer than 1280 bytes either.

cheers,
Ole

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 6 Feb 2013 23:41:07 +0000

Ole,

I am supporting this draft because the community has become accustomed to stateless firewalls on routers. These stateless firewalls are capable of filtering based upon information gleaned from both the IPv6 and L4 header.

When a stateless firewall encounters an IPv6 datagram in which the IPv6 header and L4 header don't appear in the first fragment, it can't make an informed filtering decision on any fragment. However, if there is a guarantee that the IPv6 header and the L4 header are in the first fragment, it can at least make an informed decision regarding that fragment. 

Would the draft be more acceptable if we stated this as the motivation and removed references to NAT64?

                                     Ron

> From: Ole Troan [mailto:[email-masked]]
> Sent: Wednesday, February 06, 2013 4:51 PM
> To: Ronald Bonica
> Cc: Fernando Gont; [email-masked]; [email-masked]
> Subject: Re: Moving forward draft-ietf-6man-oversized-header chain?
> 
> rfc2460 definition of a router; "extension headers are not examined or
> processed by any node along a packet's delivery path".
> is the main justification for this work to make NAT64s function better?
> if so that might be a little short-sighted, by the time we've updated
> IPv6 implementations... perhaps use a different example than NAT64?
> 
> section 5:
> restricting the header chain seems like an incomplete solution. doesn't
> a middlebox need to reassembly fragments anyway, to deal with mis-
> ordered fragments?
> a feature that tries to protect the end to end Internet, i.e. that we
> can deploy new transport protocols and extension headers without
> upgrading all intermediate boxes. changing the IPv6 protocol for a
> flawed design (aka middleboxes), is that wise?
> and don't get me wrong, I can't imagine any use case for an extension
> header chain longer than 1280 bytes either.
> 
> cheers,
> Ole
> 
> 
>

---

From: joel jaeggli <[email-masked]>
Date: Wed, 06 Feb 2013 16:01:48 -0800

> When a stateless firewall encounters an IPv6 datagram in which the IPv6 header and L4 header don't appear in the first fragment, it can't make an informed filtering decision on any fragment. Howeve…
my own .02

Stateless observation of upper layer headers of any variety have this 
issue whether applied in a router or on and end system. if I wish to 
apply a particular priority to a packet forwarding on the basis of an L4 
identifier I have to find it first.  If I want my sflow/netflow  export 
to expose the contents of the upper layer header I need to find them. If 
I want to protect the control plane, first I need to find the upper 
layer header. If I need to mitigate a DOS attack sourced on UDP 53 I 
need to find the upper layer header etc.

I don't really belive that wanting usable data out of flow sampling 
(which necessarily due to the nature of sampling cannot do reassembly), 
or the ability to assign queues to traffic on the basis of something 
other than source/dest address and an empty flow label result in what 
would be characterized as flawed middlebox design. Nor whould I 
characterize the devices that do this as firewalls, elsewise every 
high-scale router on the internet is a firewall.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 06 Feb 2013 21:47:23 -0300

On 02/06/2013 06:51 PM, Ole Troan wrote:
> section 4: issues with terminology. call a device that walks the
> extension header chain something else than a router. rfc2460
> definition of a router; "extension headers are not examined or
> processed by any node along a packet's delivery path". a switch in my
> book doesn't look at L3 headers. use "middlebox" or "filtering
> router"?

Will do.

> section 3: is the main justification for this work to make NAT64s
> function better? if so that might be a little short-sighted, by the
> time we've updated IPv6 implementations... perhaps use a different
> example than NAT64?

I could mention something along the lines of "any middlebox that
must/wants_to perform stateless processing of packets"

> section 5: restricting the header chain seems like an incomplete
> solution. doesn't a middlebox need to reassembly fragments anyway, to
> deal with mis-ordered fragments?

No. Such devices typically pass non-first fragments, and enforce their
policy based on the information contained in the first fragment.

> with a more idealist hat on: that extension headers are hard to
> parse, some consider a feature of IPv6. 

Others consider "deployability" a more interesting feature -- are we
really having this discussion?

> a feature that tries to
> protect the end to end Internet, 

That doesn't protect the end-to-end-ness of the Internet, but rather
just prevents IPv6 from being deployed -- such "feature" ("overlooked
conercase", I'd rather say) will only prevent traffic (that would have
otherwise been allowed) from flowing in the network.

> i.e. that we can deploy new
> transport protocols and extension headers without upgrading all
> intermediate boxes.  changing the IPv6 protocol for a flawed design
> (aka middleboxes), is that wise?

That's your take. My take is that packets that have more headers than
payload don't make any sense. We put headers to move payloads -- not the
other way around.

> might as well just deprecate IP
> fragmentation. (which I would be in favour of).

IMHO, (and all the above said), this document was adopted almost a year
ago. If we're going to stop moving documents forward to re-hash
one-year-old discussions (as we already did with
draft-ietf-6man-stable-privacy-addresses), it becomes very hard to make
any sort of progress.

Thanks!

Best regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Feb 2013 08:04:59 +0000

> must/wants_to perform stateless processing of packets"

Yes, it's certainly an issue for load balancers, for example.
It certainly isn't "routers" in the classical sense.

At the chairs' request, I cross-checked the interaction of this
draft with draft-carpenter-6man-ext-transmit some time back,
and concluded that there's no conflict. Banning fragmented header
chains makes header processing easier, so it's a good thing, IMHO.

>> (aka middleboxes), is that wise?

IMHO yes - this was an oversight in the design. I would like to fix
middleboxes too, hence draft-carpenter-6man-ext-transmit, but it
is not easily enforceable.

>> fragmentation. (which I would be in favour of).

That's an even bigger piece to bite off. For now, just set your MTU to 1280 ;-)

   Brian

---

From: Karl Auer <[email-masked]>
Date: Thu, 07 Feb 2013 19:37:27 +1100

> > payload don't make any sense. We put headers to move payloads -- not the

Coming in very late and this has probably already been thought of, but
the ESP header *is* effectively a payload, and may need to be
fragmented.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])
http://www.biplane.com.au/kauer
http://www.biplane.com.au/blog

GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017

---

From: joel jaeggli <[email-masked]>
Date: Thu, 07 Feb 2013 01:14:28 -0800

> the ESP header *is* effectively a payload, and may need to be
everything after the esp header is payload for everyone other than the 
intended recipient, who has more headers to unwrap once the payload has 
been decrypted.

---

From: Ole Troan <[email-masked]>
Date: Thu, 7 Feb 2013 11:18:35 +0100

Ron,

> I am supporting this draft because the community has become accustomed to stateless firewalls on routers. These stateless firewalls are capable of filtering based upon information gleaned from both…

don't get me wrong, I'm also in support of this work. ;-)
but if we go down this slippery slope. where do we draw the line? I do know of filtering routers that look at the L7 headers.
and I'm sure there are those that inspect the payload as well.
do we arbitrary choose to stop at the L4 header?

as Karl pointed out, what do we do with the ESP header? do you define which part of the ESP header that must be included in the first fragment? or does this mean that a packet with ESP MUST NOT be fragmented?
are there other headers where what consist of the "entire ipv6 header chain" is unclear?

> Would the draft be more acceptable if we stated this as the motivation and removed references to NAT64?

yes, I think that would help.

Best regards,
Ole

---

From: Karl Auer <[email-masked]>
Date: Thu, 07 Feb 2013 21:34:24 +1100

> intended recipient, who has more headers to unwrap once the payload has 

Er - yes. I just meant that you can't take the hard line that "headers
shall not be fragmented" (not that Brian was saying that) when at least
one header may have to be. There will only be more headers to unwrap in
tunnel mode.

Regards, K.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 07 Feb 2013 14:35:43 -0300

>From the pov of this I-D, ESP is the "upper layer protocol". So as long
as you have everythin till the ESP header in the first fragment, you're
fine.

I could add a clarification, if you want (for instance, I added
something along those lines in draft-ietf-v6ops-ra-guard-implementation)

Thanks!

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 7 Feb 2013 16:18:42 +0000

Inline....

> From: Ole Troan [mailto:[email-masked]]
> Sent: Thursday, February 07, 2013 5:19 AM
> To: Ronald Bonica
> Cc: [email-masked]; Fernando Gont; [email-masked]
> > I am supporting this draft because the community has become
> accustomed to stateless firewalls on routers. These stateless firewalls
> are capable of filtering based upon information gleaned from both the
> IPv6 and L4 header.
> 
> don't get me wrong, I'm also in support of this work. ;-) but if we go
> down this slippery slope. where do we draw the line? I do know of
> filtering routers that look at the L7 headers.

Clearly, we have to draw the line somewhere. I think that it is reasonable to stop at the L4 header.

> 
> as Karl pointed out, what do we do with the ESP header? do you define
> which part of the ESP header that must be included in the first
> fragment? or does this mean that a packet with ESP MUST NOT be
> fragmented?

The document needs to make a special exception for encrypted payloads. In that case, the ESP header must begin on the first fragment, but need not end on the first fragment.

Does this sound reasonable?

> 
> > When a stateless firewall encounters an IPv6 datagram in which the
> IPv6 header and L4 header don't appear in the first fragment, it can't
> make an informed filtering decision on any fragment. However, if there
> is a guarantee that the IPv6 header and the L4 header are in the first
> fragment, it can at least make an informed decision regarding that
> fragment.
> >
> > Would the draft be more acceptable if we stated this as the
> motivation and removed references to NAT64?
> 

I will work with Fernando on this.

> >> issues with terminology. call a device that walks the extension
> >> header chain something else than a router.
> >> rfc2460 definition of a router; "extension headers are not examined
> >> or processed by any node along a packet's delivery path".
> >> restricting the header chain seems like an incomplete solution.
> >> doesn't a middlebox need to reassembly fragments anyway, to deal
> with
> >> mis- ordered fragments?

---

From: Karl Auer <[email-masked]>
Date: Fri, 08 Feb 2013 07:44:10 +1100

On Thu, 2013-02-07 at 14:35 -0300, Fernando Gont wrote:
> I could add a clarification, if you want

I think every exception needs a clarification, yes :-)

Regards, K.

---

From: Ole Troan <[email-masked]>
Date: Thu, 7 Feb 2013 21:59:58 +0100

Ron,

> Clearly, we have to draw the line somewhere. I think that it is reasonable to stop at the L4 header.

agree.

> Does this sound reasonable?

yes, I'll leave it to the ipsec experts to determine if there is a part of the header that should be in the first fragment or not.

> I will work with Fernando on this.

thanks!

cheers,
Ole

---

From: Karl Auer <[email-masked]>
Date: Fri, 08 Feb 2013 08:47:01 +1100

On Thu, 2013-02-07 at 21:59 +0100, Ole Troan wrote:
> >> as Karl pointed out, what do we do with the ESP header?
> > The document needs to make a special exception for encrypted
> > payloads. In that case, the ESP header must begin on the first
> > fragment, but need not end on the first fragment.

Do you mean that the ESP header must be the first item in the
fragmentable part of the first fragment? Or that the ESP header must be
(at least partly) in the non-fragmentable part of the first fragment?

If the latter, that's a new kind of animal. At present, a header is
either completely in the non-fragmentable part or completely in the
fragmentable part. Permitting a header to straddle the fragment header
seems odd, and I can't immediately see how you could do it without
changing the fragment header definition, either.

Regards, K.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 07 Feb 2013 18:56:46 -0300

> changing the fragment header definition, either.

I think we all mean that the ESP header must be the last "visible"
header in the fragmentable part of the first fragment.

Put another way, if the ESP header is the last chunk of headers one
could possibly snoop without decrypting the packet, then that header
must be in the first fragment.

Cheers,