Subject: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

From: Ray Hunter <[email-masked]>
Date: Thu, 06 Jun 2013 18:14:57 +0200

Nalini Elkins wrote:
> >>> Some tricky and potentially malicious cases will be avoided by
> forbidding very long chains of extension headers that need to be
> >>> fragmented [I-D.ietf-6man-oversized-header-chain].
> > 
> > I  wonder if this is the place to define "very long"?
>
> >> I guess those two words can be deleted - the issue is only that the
> header chain gets fragmented at all. The full discussion is in the
> cited draft, of course.
>
> I know the draft that you have cited and they do not define "long"
> either.  There has been quite a bit of discussion about what "long"
> means and IMHO somewhere, someone needs to take some kind of
> reasonable stand. 
>
Actually IMHO ietf-6man-oversized-header-chain DOES define "unusually
long" very accurately.

I-D.ietf-6man-oversized-header-chain requires that "the first fragment
of a fragmented datagram is required to contain the entire IPv6 header
chain"

So in other words, any packet parsing engine should be prepared to
examine an entire single frame up to the MTU of the local egress
interface, but should not be expected to maintain any state across
multiple fragments.

We might also benefit operationally from setting an additional limit on
the length of the hop hop option header, which is theoretically meant to
be processed by routers along the path. However, my guess is that is
well beyond the author's original intentions for
draft-ietf-6man-oversized-header-chain-02, which was more focussed on
firewalls.

>
> >>The IETF hasn't done much about firewalls at all. This
> search produces far more expired drafts than anything else:
> >> https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit=
> <https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit=>
>
> The reason I asked is because I think defining RFCs or rules for
> firewalls is a really good thing to do but if the vendors are not in
> the habit of having to be compliant, then why would they pay attention
> to this draft that we are discussing?  I actually think maybe an RFC
> which explicitly talks about firewalls is probably a good thing to do.
>  Now, getting vendors to comply...
>  
> Thanks,
>
> Nalini Elkins
> Inside Products, Inc.
> (831) 659-8360
> www.insidethestack.com
>

---

From: Nalini Elkins <[email-masked]>
Date: Thu, 6 Jun 2013 09:20:49 -0700 (PDT)

So, if we are talking about the MTU of the local egress interface, then since, I believe, the minimum MTU size for IPv6 is 1,280, then all devices should be prepared to examine up to 1,280 bytes to get the L4 header?

Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________
 From: Ray Hunter <[email-masked]>
To: Nalini Elkins <[email-masked]> 
Cc: Brian E Carpenter <[email-masked]>; 6man <[email-masked]>; Fernando Gont <[email-masked]>; [email-masked] 
Sent: Thursday, June 6, 2013 9:14 AM
Subject: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

---

From: Ray Hunter <[email-masked]>
Date: Thu, 06 Jun 2013 18:42:18 +0200

IMVHO interpreting the text of the current drafts.

> Nalini Elkins <mailto:[email-masked]>
> 6 June 2013 18:20
> So, if we are talking about the MTU of the local egress interface,
> then since, I believe, the minimum MTU size for IPv6 is 1,280, then
> all devices should be prepared to examine up to 1,280 bytes to get the
> L4 header?
Not quite.

AFAICS

1. All parsing engines should be able to parse at least 1280 bytes to
cover the minimum IPv6 MTU.

2. If all the local interfaces are Ethernet, and have an MTU set of
1500, the parsing engine on that box should be able to parse a full
Ethernet frame of 1500 bytes of payload..... and so on for devices
supporting links with larger MTUs, all the way up to jumbograms (if
supported on that device).

3. draft-ietf-6man-ext-transmit gives the option of not parsing
extension headers at all on high speed routers (only the hop by hop
option is supposed to be parsed by routers on the path). But neither
this draft, nor any other IETF draft that I know of, gives an option for
parsing an IPv6 header chain "just for the first n bytes", where n is an
arbitrary number picked out of the air by a vendor, whether that be 53,
256 or 1280.

regards,
RayH
>  
> Thanks,
>
> Nalini Elkins
> Inside Products, Inc.
> (831) 659-8360
> www.insidethestack.com
>
> ------------------------------------------------------------------------
> *From:* Ray Hunter <[email-masked]>
> *To:* Nalini Elkins <[email-masked]>
> *Cc:* Brian E Carpenter <[email-masked]>; 6man
> <[email-masked]>; Fernando Gont <[email-masked]>;
> [email-masked]
> *Sent:* Thursday, June 6, 2013 9:14 AM
> *Subject:* draft-ietf-6man-oversized-header-chain-02 (was Re: Re:
> draft-ietf-6man-ext-transmit-01)
>
> Nalini Elkins wrote:
> <https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit=
> <https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit=>>
> >
> > www.insidethestack.com <http://www.insidethestack.com/>
> >
>
>
>
> Ray Hunter <mailto:[email-masked]>
> 6 June 2013 18:14
> Nalini Elkins wrote:
> ------------------------------------------------------------------------

---

From: Nalini Elkins <[email-masked]>
Date: Thu, 6 Jun 2013 09:46:18 -0700 (PDT)

But the reality of the situation is that much of the Internet appears to be running where

"n is an arbitrary number picked out of the air by a vendor"

Or rather

"multiple arbitrary numbers"!

Yes?

Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________
 From: Ray Hunter <[email-masked]>
To: Nalini Elkins <[email-masked]> 
Cc: Brian E Carpenter <[email-masked]>; 6man <[email-masked]>; Fernando Gont <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Thursday, June 6, 2013 9:42 AM
Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

Not quite.

AFAICS

regards,
RayH

---

From: Ray Hunter <[email-masked]>
Date: Thu, 06 Jun 2013 19:25:54 +0200

> "multiple arbitrary numbers"!
Correct.

There is a non null union between the set of IETF standards and the set
of operational configurations of the various networks that form the
Internet; but neither is a proper subset of the other. That's nothing new.

> "[email-masked]" <[email-masked]>
> *Sent:* Thursday, June 6, 2013 9:42 AM
> *Subject:* Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re:
> > Nalini Elkins <mailto:[email-masked]
> <mailto:[email-masked]>>
> > 6 June 2013 18:20
> > *From:* Ray Hunter <[email-masked] <mailto:[email-masked]>>
> > *To:* Nalini Elkins <[email-masked]
> <mailto:[email-masked]>>
> > *Cc:* Brian E Carpenter <[email-masked]
> <mailto:[email-masked]>>; 6man
> > <[email-masked] <mailto:[email-masked]>>; Fernando Gont
> <[email-masked] <mailto:[email-masked]>>;
> > [email-masked] <mailto:[email-masked]>
> <https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit=>>>
> > >
> > Ray Hunter <mailto:[email-masked] <mailto:[email-masked]>>
> > 6 June 2013 18:14
> > Nalini Elkins wrote:

---

From: Fernando Gont <[email-masked]>
Date: Thu, 06 Jun 2013 22:08:27 +0200

> interface, but should not be expected to maintain any state across

FWIW, some earlier version of this document tried to require that the
entire IPv6 header chain be present within the first 1280 bytes -- but
some folks thought that was too constricting.

> draft-ietf-6man-oversized-header-chain-02, which was more focussed on

I (personally) think it would be valuable to limit the number of
instance of each extension header -- but that wouldn't probably fly here...

Thanks!

Best regards,
-- 
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: Thu, 06 Jun 2013 22:09:31 +0200

On 06/06/2013 06:20 PM, Nalini Elkins wrote:
> So, if we are talking about the MTU of the local egress interface, then
> since, I believe, the minimum MTU size for IPv6 is 1,280, then all
> devices should be prepared to examine up to 1,280 bytes to get the L4
> header?

In theory, yes. In practice, it wouldn't make much sense, probably (most
of the packet containing overhead?).

Cheers,

---

From: joel jaeggli <[email-masked]>
Date: Thu, 06 Jun 2013 16:19:34 -0400

> of the packet containing overhead?).
There's a question you can pose to an asic designer... What does it cost 
at this point to extend the header processing from 53/64/128/256 bytes. 
bearing in mind also that part of the reason that the space already has 
increased is due to encapsulation, label-in-label q-in-q so the ipv6 
header is not the only thing competing for more room.

---

From: Ray Hunter <[email-masked]>
Date: Thu, 06 Jun 2013 22:41:10 +0200

> joel jaeggli <mailto:[email-masked]>
> 6 June 2013 22:19
> There's a question you can pose to an asic designer... What does it
> cost at this point to extend the header processing from 53/64/128/256
> bytes. bearing in mind also that part of the reason that the space
> already has increased is due to encapsulation, label-in-label q-in-q
> so the ipv6 header is not the only thing competing for more room.
>> Cheers,
>
May I suggest some other questions:

Does size matter?

Or is the complexity of the ASIC implementation of a header chain parser
more heavily influenced by the fact that the header chain is defined as
a linked list of type-length-value items that can be built up in any
number of valid combinations, and so has to be traversed and interpreted
at every individual link?

What if the most common individual TLV option tokens were standardized
further?

And the transmission order fixed?

What if the most common individual extension headers were standardized
further?

And the transmission order fixed?

Would this help make hardware parsing possible/economic?

regards,
RayH

---

From: Ole Troan <[email-masked]>
Date: Fri, 7 Jun 2013 11:06:03 +0200

[absolutely no chair hat]

> Would this help make hardware parsing possible/economic?

since it's Friday... and thinking aloud, what extension headers are in actual use today?
what would be the consequence of relegating them to networks using them only
among consenting adults?

IPv6-Opts:
-----------------
Link specific: Jumbo Payload
Consenting Adults: RPL Option, CALIPSO, Line-Identification Option, MPL Option
Experimental: Quick-Start, SMF_DPD, ILNP Nonce, IP_DFF
Not implemented: Tunnel Encapsulation Limit
Hop-by-Hop option: Router Alert. DOS vector
Home Address - could use tunneling.

IPv6-Route:
-------------------
There are two source route types, one used by mobile IP (that could use tunnelling),
and one used by RPL, which could be supported in a RPL network.

IPv6-Frag:
---------------
It would be an interesting analysis to see what application layer protocols must change if
we were to remove fragmentation from the Internet layer.

of course you have AH, ESP, various GRE, IP in IP stuff as well.

cheers,
Ole

---

From: Nalini Elkins <[email-masked]>
Date: Fri, 7 Jun 2013 05:46:59 -0700 (PDT)

Yes!   Let those of us who want to use extension headers use them!
 
Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________
 From: Ole Troan <[email-masked]>
To: Ray Hunter <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>; 6man <[email-masked]>; Fernando Gont <[email-masked]> 
Sent: Friday, June 7, 2013 2:06 AM
Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

IPv6-Opts:
-----------------

IPv6-Route:
-------------------

IPv6-Frag:
---------------

cheers,
Ole
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 08 Jun 2013 08:03:36 +1200

Ole,

I think the list of headers in -ext-transmit is complete,
if you include HIP. However, you last question illustrates the
Catch-22 problem - the ones in use today are the ones that
manage to get through firewalls, sometimes, today. We don't
*know* which ones would be in use if the network was transparent
to them.

Your other questions are interesting ones, but I am also interested
in seeing a detailed analysis of exactly what is hard for modern
technology in dealing with what is currently standardised. All I
hear is "our current design doesn't do this." That isn't helpful.

Regards
   Brian

On 07/06/2013 21:06, Ole Troan wrote:
> .

---

From: joel jaeggli <[email-masked]>
Date: Sat, 08 Jun 2013 10:36:47 +0200

>> "n is an arbitrary number picked out of the air by a vendor"
The number is the product of compromise between (in no particular order) 
performance, transitor count, memory size, cost, heat, standards 
compliance, customer requirements, product lifetime.

The are room for multiple products in the market-place. and some of them 
have quite long life-cycles. There is ipv6 capable silicon forwarding at 
10Gbe/OC192 rates in the internet that was designed 13-15 years ago and 
which was still recently commercially available having been iteratively 
improved.
> Internet; but neither is a proper subset of the other. That's nothing new.
Part of the reasons we have a couple of drafts floating around right now 
related to problems in that space, is that operators want the IETF 
community to be aware of the limitations of where we are today. 
Doubtless some people participating in the IETF are aware of how 
asic-based-forwarding works in the internet today having made 
significant contributions to where we are, but not everyone is. 
Manufacturers are understandably cagey about the internal workings of 
their hardware.

As on operator I have an interest in telling people if their assumptions 
are at variance with what we can support.

---

From: joel jaeggli <[email-masked]>
Date: Sat, 08 Jun 2013 11:12:58 +0200

> May I suggest some other questions:
It does because typically the memory associated with the 
forwarding/header lookup is very fast and expensive. It never holds the 
whole packet currently. This was of course in our draft.
> at every individual link?
Traversal is expensive yes.

---

From: Ray Hunter <[email-masked]>
Date: Sat, 08 Jun 2013 13:06:28 +0200

> 8 June 2013 11:12
>>>>> then
> forwarding/header lookup is very fast and expensive. It never holds
> the whole packet currently. This was of course in our draft.
Understood.

Do you think hardware based forwarding with parsing of a header up to a
single frame at wire speed is realistic in the foreseeable future?

[no state required to be maintained across frames, but upper limit =
entire header is contained in the 1st frame of a packet, as per
draft-ietf-6man-oversized-header-chain-02]
> Traversal is expensive yes.
ACK.

Can we as an IETF community do anything about that?

"Unhindered by any technical knowledge" as they say in Dutch, if we
published an *informational* RFC that defined some basic syntax
structure to facilitate optimized forwarding in hardware, would this
help out with simplifying future designs (less iterative traversal, less
transistors, less branch complexity) and get us all more bang for the buck?

I was thinking something along the lines of:

- The preferred length of a Hop by Hop extension header for optimized
forwarding in hardware is always 16 octets long.

- the Hop by Hop EH may be present exactly once, or not present, and is
always transmitted directly after the IPv6 header (already the case in 2460)

- Strict processing in transmission order is not required when
performing optimized hardware forwarding, and options may be evaluated
in parallel (potentially dubious according to 2460) provided that only
the Pad1, PadN, Jumbogram and Router Alert options are present.

- the Router Alert option RFC2711 should always be the first option (4
octets) if present
if not present it should be replaced with Padn option for 4 octets

- the second option should always be the Jumbogram option (rfc2675) (6
octets) if present
if not present it should be replaced with Padn option for 6 octets

- The remaining 4 octets are currently undefined (reserved for future
use) and should be filled with 4 * pad1 (4 octets)

[Just trying to help out making sensible trade offs]

regards,
RayH

---

From: Fernando Gont <[email-masked]>
Date: Sun, 09 Jun 2013 15:42:53 +0200

> Traversal is expensive yes.

Yet this has always been claimed as a "feature" -- which I've never
really understood, btw.

IIRC, the claim was that routers didn't need to parse all options to get
the ones it's interested in (as opposed to v4, where the IPv4 might
contain both "destination options" and router options).

However,as soon as one realizes that many boxes need to access the L4
information, this header-chain structure seems rather painful.

I guess having a L4-pointer would have helped quite a lot.

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 09 Jun 2013 15:46:19 +0200

Ray,

> always transmitted directly after the IPv6 header (already the case in 2460)

I'd say one should enforce a "each EH can be present at most once".

ANd, me, I'd limit the EH chain to 1280 octets (at most) -- even that is
kind of irrational: 1280 is the IPv6 minimum MTU... so we'd be allowing
packets that are 100& overhead.

Cheers,

---

From: Ray Hunter <[email-masked]>
Date: Sun, 09 Jun 2013 18:36:42 +0200

> Fernando Gont <mailto:[email-masked]>
> 9 June 2013 15:46
> Ray,
>
I just wanted to start with one simple example. It can of course be
extended.

BTW there is a precedent for publishing recommendations to enable
optimised parsing of variable byte-aligned options.

http://tools.ietf.org/html/rfc1323#page-7 & Appendix A advises an
optimal layout of TCP options to enable fast processing of a commonly
recurring pattern by RISC processors.
> 8 June 2013 13:06

---

From: Tom Taylor <[email-masked]>
Date: Sun, 09 Jun 2013 12:49:26 -0400

> I guess having a L4-pointer would have helped quite a lot.
Would it be practical to define a HBH option that has an L4 pointer and 
assign a fixed order to it?

---

From: Fernando Gont <[email-masked]>
Date: Sun, 09 Jun 2013 19:09:34 +0200

> I just wanted to start with one simple example. It can of course be

Agreed. -- I should have said "I'd also limit..".

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 09 Jun 2013 19:16:32 +0200

> assign a fixed order to it?

1) I doubt that would fly.

2) IPv6 EHs seem to be so unreliable already, that if you're to
implement an "extension", you better rely on something else. -- not that
I like it, but... me not liking it doesn't make the situation any better :-(

Cheers,

---

From: Arturo Servin <[email-masked]>
Date: Sun, 09 Jun 2013 19:09:53 -0300

There is another conversation in v6ops that mentioned that switching
ASICs do not inspect beyond 40 bytes.

-as

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Jun 2013 16:31:20 +1200

> On 09/06/2013 9:42 AM, Fernando Gont wrote:

...
> assign a fixed order to it?

http://tools.ietf.org/html/draft-zhang-6man-offset-option-01

It didn't fly in this WG at the time.

   Brian

---

From: Andrew McGregor <[email-masked]>
Date: Mon, 10 Jun 2013 15:01:07 +1000

Which is definitely not true in general.  Some do that, many do not inspect
beyond 128, some go further.

---

From: joel jaeggli <[email-masked]>
Date: Mon, 10 Jun 2013 07:39:30 +0200

On 6/10/13 7:01 AM, Andrew McGregor wrote:
> Which is definitely not true in general.  Some do that, many do not 
> inspect beyond 128, some go further.
>
The lower bound is probably 53. There's a lowest common denominator 
problem if you expect to be able to find an l4 header as part of your 
forwarding decision
>
> On Mon, Jun 10, 2013 at 8:09 AM, Arturo Servin 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
That was never said. You should reread the thread. What was said is that 
the fixed portion of the ipv6 header is 40 bytes, which is all you need 
to forward on modula hop-by-hop options. unless you need to find the l4 
header for some reason in which case you're back to here:

http://tools.ietf.org/html/draft-wkumari-long-headers-00
>     [email-masked] <mailto:[email-masked]>

---

From: Randy Bush <[email-masked]>
Date: Mon, 10 Jun 2013 12:49:06 +0200

i think of it as a somewhat arbitrary operational (not protocol, i.e.
does not belong in this wg) best common practice.  just as i warn my
customer that they can announce a /64 to me, and can pay me to announce
it to my peers, that my peers will not listen to it or propagate it.

similarly, you might be able to send 4k of bleeding extension headers to
me, but i am likely to drop the packet on the floor.  and if i don't,
someone down the line likely will.

so i would suggest a bcp draft in grow or v6ops that says that it is
unsafe to send more than X bytes in extensions.

randy

---

From: Arturo Servin <[email-masked]>
Date: Mon, 10 Jun 2013 08:29:24 -0300

Joel

	My mistake, you are right.

	And thanks for the reference, that is exactly what I needed to clear
some doubts.

	Nevertheless, shouldn't we see the problem of long headers chains as
operational and security instead of two separate issues as we have now?

Regards,
as

---

From: Nalini Elkins <[email-masked]>
Date: Mon, 10 Jun 2013 07:09:59 -0700 (PDT)

>problem if you expect to be able to find an l4 header as part of your 

Guys,

53 = not good.  Just because some people are re-using old hardware cards they had hanging around does not mean everyone has to go along with it.

Nalini

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 10 Jun 2013 10:31:59 -0400

On Mon, Jun 10, 2013 at 10:09 AM, Nalini Elkins
<[email-masked]> wrote:

> 53 = not good.  Just because some people are re-using old hardware cards
> they had hanging around does not mean everyone has to go along with it.

define old.
define 'hanging around'
define the location from which capex can be drawn to replace 'old' and
'hanging around' modules which are clearly perfectly functional in the
network today.

-chris

---

From: joel jaeggli <[email-masked]>
Date: Mon, 10 Jun 2013 16:34:31 +0200

On 6/10/13 4:09 PM, Nalini Elkins wrote:
> 53 = not good.  Just because some people are re-using old hardware 
> cards they had hanging around does not mean everyone has to go along 
> with it.
Last time  I bought one of that particular arch boxes new was in 2011. I 
don't have any in my current network but things don't age out of the 
internet as quickly as I can change jobs, certainly not in enterprises 
either.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Jun 2013 16:52:19 +0200

> they had hanging around does not mean everyone has to go along with it.

Agreed: You can always choose to "engineer" an un-deployable
protocol/mechanism and complain about the network.

Cheers,

---

From: Nalini Elkins <[email-masked]>
Date: Mon, 10 Jun 2013 07:56:32 -0700 (PDT)

> >The lower bound is probably 53. There's a lowest common denominator> >problem if you expect to be able to find an l4 header as part of your
> >forwarding decision
> 
> Guys,
> 

>>Last time  I bought one of that particular arch boxes new was in 2011. I don't have any in my current network but things don't age out of the internet as quickly as I can change jobs, certainly not in enterprises either.

Sure.  I don't even want to get started on war stories of the kind of equipment / software protocols some of our folks have hanging around.  I totally know that but I don't encourage them buying more of the same either!

I suppose what I am thinking is that since there are no "IETF Police", then the only "teeth" there are in the standards is the ability to say "this is not compliant".  That is not a trivial thing.  People pay attention to that.

If there is consensus that EH's are valuable - then, maybe the way forward should be to:

1.  Decide how to get to the L4 header best.

2.  Maybe a recommendation on how much of the header should be read into ASIC.  Is that out of scope?

Nalini

---

From: Randy Bush <[email-masked]>
Date: Mon, 10 Jun 2013 16:57:10 +0200

> cards they had hanging around does not mean everyone has to go along

you are completely correct.  you are welcome to send 10gb of headers.
just do not be surprised when they do not make it to the destination.
welcome to ops reality.

randy

---

From: Warren Kumari <[email-masked]>
Date: Mon, 10 Jun 2013 11:03:35 -0400

> It didn't fly in this WG at the time.

The issue is that, in order to be able to see header X you need to push all the bits up to header X onto the forwarding engine. Having a header that says "The L4 header is at byte 142" simply pushes the L4 out by another 8 bytes, exacerbating the problem.

This issue is:
1: In order to make a decision on header X the forwarding / filtering engine needs to see header X
2: This require pushing at least <number of bytes from start of packet to end of header X> up to the forwarding engine in a  "cell".
3: Bandwidth into the forwarding engine is expensive / limited, and storage on the forwarding engine is expensive (this is not DRAM ;-))
4: As you don't know (until you've looked) how far into the packet header X is, you need to choose some number and ship that many bytes to the forwarding engine.
5: Having a header that points at the L4 info doesn't help -- by the time you can see it you've already sucked the bits onto the engine. 
6: Having additional logic that "prescreens" the packets looking for a pointer header *could* possibly work, but that is much of the forwarding engine logic - see #3.

Choosing the optimum cell size is the tricky bit. If you increase the cell size you vastly increase cost -- if your competitors don't do the same, you've priced yourself out of the market. 

We are planning on updating the long-headers draft / publishing another "implementers guide" draft that suggests 128 or 256 bytes (as a straw man). This will hopefully be something that major vendors will sign up for.

W

--
It's a mistake trying to cheer up camels. You might as well drop meringues into a black hole. -- Terry Prachett

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 10 Jun 2013 11:22:43 -0400

> ASIC.  Is that out of scope?

Some of the discussion already had talks about ordering and optimum
method to find X in the header chain. What happens in these situations
when someone sends 'lots' of packets with 'bad ordering' of the header
bits? Will the devices in the path behave 'well'? or will I get
degraded forwarding performance because of bad ordering? or will the
packets be dropped? or ?

it's worth thinking about what can go wrong with this requirement to
order EH bits in certain ways.

-chris

---

From: [email-masked]
Date: Mon, 10 Jun 2013 18:02:30 +0200 (CEST)

> 'hanging around' modules which are clearly perfectly functional in the

This is precisely the problem. I don't think anybody is going to phase
out functional equipment just because it can't peek all the way into a
64k byte header chain. 

I might be able to put some requirement on this ability into future
RFQs if there is sensible guidance on what the limit should be. Note
that I'm not going to be asking for 4k byte or 64k byte - neither of
those constitute sensible guidance in my book. 128 or 256 bytes sound
much more reasonable.

It would be good to have a document which gives sensible guidance
here, preferably based on input from actual hardware-based forwarding
equipment manufacturers.

Steinar Haug, AS 2116

---

From: Ray Hunter <[email-masked]>
Date: Mon, 10 Jun 2013 20:44:10 +0200

> Christopher Morrow <mailto:[email-masked]>
> 10 June 2013 17:22
I purposefully left that particular can unopened, because I consider it
unlikely that we will obtain rough consensus on it.

IMHO it's better to have an informational RFC that says "if you obey
these simple formatting rules, your packet is likely to be transported
(fast)" than nothing at all.

I just searched draft-ietf-v6ops-6204bis-12 for requirements on
extension headers. Nada AFAICS.

I also just tested my own home CPE for outbound transmission of
extension headers (with and without firewall configured):
HBH EH: tick
Destination Options EH: tick
Fragment EH: looks like they're always dropped

regards,
RayH

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 10 Jun 2013 14:59:52 -0400

> unlikely that we will obtain rough consensus on it.

:)

> (fast)" than nothing at all.

right, but you're also asking HW manufacturers to optomize on a
certain ordering (sort of), that's going to lead to: 1, 2, 3 ordering
works great! but: 3,2,1 == slow-path :(

or COULD lead to that.

> Fragment EH: looks like they're always dropped

neat... how about proto-59? (noext-headers)? :)

---

From: Ray Hunter <[email-masked]>
Date: Mon, 10 Jun 2013 21:35:01 +0200

> 10 June 2013 20:59
> works great!

Yes. Better than today.

>  but: 3,2,1 == slow-path :(
>
> or COULD lead to that.

Same as today. So they'll continue to make their own decision on whether
to deploy slow path or drop.

> neat... how about proto-59? (noext-headers)? :)
Untested (no test source yet)

regards,
RayH

---

From: joel jaeggli <[email-masked]>
Date: Mon, 10 Jun 2013 22:04:51 +0200

> to deploy slow path or drop.
Understand that there is no slow path in high capacity devices.

There is fast path or no path.

If slow path exists it becomes a bottleneck or a dos target.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Jun 2013 08:12:04 +1200

Why wouldn't we add a sentence in -oversized-header-chain
following this:

> 6.  Updating RFC 2460
> 
>    If an IPv6 packet is fragmented, the first fragment of that IPv6
>    packet (i.e., the fragment having a Fragment Offset of 0) MUST
>    contain the entire IPv6 header chain.

 The entire IPv6 header including the header chain SHOULD NOT exceed
 256 octets.

(or whatever magic number we decide on).

We might need some words to justify that, but they can be found
in this thread.

Regards
   Brian Carpenter

---

From: [email-masked]
Date: Mon, 10 Jun 2013 22:42:12 +0200 (CEST)

> (or whatever magic number we decide on).

I like this addition very much.

Do you think it is realistic to get input from hardware manufacturers
on what the magic number should be?

Steinar Haug, AS 2116

---

From: Ray Hunter <[email-masked]>
Date: Mon, 10 Jun 2013 22:47:44 +0200

> 10 June 2013 22:04
I understand exactly.

Which is why I am studiously ignoring the issue. :)

regards,
RayH

---

From: Warren Kumari <[email-masked]>
Date: Mon, 10 Jun 2013 16:59:30 -0400

>> We are planning on updating the long-headers draft / publishing another "implementers guide" draft that suggests 128 or 256 bytes (as a straw man). This will hopefully be something that major vend…

Fine idea!

W

--
It is impossible to sharpen a pencil with a blunt axe.  It is equally vain
to try to do it with ten blunt axes instead.
    --  E.W Dijkstra, 1930-2002

---

From: Warren Kumari <[email-masked]>
Date: Mon, 10 Jun 2013 18:10:02 -0400

Warren Kumari
------
Please excuse typing, etc -- This was sent from a device with a tiny keyboard.

>>> We are planning on updating the long-headers draft / publishing another "implementers guide" draft that suggests 128 or 256 bytes (as a straw man). This will hopefully be something that major ven…

... and we are still planning on doing this as well. Never hurts to have the same things repeated....

W

---

From: Christian Huitema <[email-masked]>
Date: Tue, 11 Jun 2013 00:26:10 +0000

> The entire IPv6 header including the header chain SHOULD NOT exceed

If you think about it, the whole point of extension headers is to help "the network." If it was merely end-to-end information, whatever hosts send in the EH could just as well be encoded as options in the application layer. If it is really meant to be private, encrypt the whole thing, and show just the ESP header. You really have to wonder why anyone would send complex chains of extension headers that cannot be parsed by routers.

-- Christian Huitema

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Jun 2013 04:00:54 +0200

Hi, Brian,

> (or whatever magic number we decide on).

I fully agree. -- For instance, at least the individual version of this
I-D included wording along those lines (at the time, the I-D was
required the entire header chain to be within the first 1280 bytes of a
packet).

> We might need some words to justify that, but they can be found

How about something along the lines of:

* A large number of deployed systems reportedly drop packets that do not
contain the entire IPv6 header chain within the first XXX bytes.

* Since extension headers represent overhead to transmission of IPv6
payloads, the IPv6 header chain is expected to be small fraction of a
full-sized packet. With an IPv6 minimum MTU of 1280 bytes, a limit of
XXX bytes for the entire header chain already allows for YYY % of overhead.

(for the first bullet, we could add an informative reference to Warren
et al's I-D).

Thanks!

Best regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Jun 2013 15:26:26 +1200

> You mean like what I said in the below email: 

Sure, except that this would add it to a standards track draft
(fwiw).

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Jun 2013 15:31:53 +1200

> on what the magic number should be?

It seems that you'd get different answers according to the capability
of each manufacturer's silicon. 256 would be a marker in the sand
for future hardware, and it doesn't seem to be craziness. But
maybe it's worth inventing a "worst reasonable case" packet with
some rational combination of headers.

    Brian

---

From: Ole Troan <[email-masked]>
Date: Tue, 11 Jun 2013 11:01:24 +0200

</chair>

> If you think about it, the whole point of extension headers is to help "the network." If it was merely end-to-end information, whatever hosts send in the EH could just as well be encoded as options…

historical revisionism? ;-)
I thought the invention of extension headers was there to strongly compel routers not to parse into the packet.

a router does ECMP on the 5-tuple. the extension header chain doesn't help with that.
a middlebox makes some policy decision on arbitrary bits in the packet (including L7). I'm not sure I see what help the middlebox
gets from the extension header chain here?

in my view there is no difference between the following cases:
 - 2nd fragment
 - extension header chain longer than first packet
 - unknown extension header
 - unknown L4
 - ESP

a firewall/filtering router with the policy of only allowing packets with known L4, will drop the packet in all the above cases.
only fixing the extension header issue doesn't solve the "problem" (in quotation marks since I'm not sure we all agree there is one).

what should we as the IETF do?

we could accommodate our protocols to become more firewall friendly,
e.g. deprecate IP layer fragmentation, deprecate extension headers (or limit their length).
but, do we then also push the Internet further away from an open end to end capable Internet,
stifle innovation in transport etc?

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Jun 2013 13:39:50 +0200

On 06/11/2013 11:01 AM, Ole Troan wrote:
>
> a router does ECMP on the 5-tuple. the extension header chain doesn't
> help with that. a middlebox makes some policy decision on arbitrary
> bits in the packet (including L7). I'm not sure I see what help the
> middlebox gets from the extension header chain here?
> 
> - unknown L4 - ESP

These cases are different (at least from a fw point of view).

- 2nd fragment is okay, beacuse you'd apply the fltering policy t the
first fragment.

- extension header chain longer than first apcket is harmful

- Unknown ext header is enough to block as "unwanted traffic"

- unknown layer 4 is enough to block

- ESP may or may not be okay depending on your policy

> a firewall/filtering router with the policy of only allowing packets
> with known L4, will drop the packet in all the above cases. 

Not really. For instance, stateless filters allow non-first fragments.

> we could accommodate our protocols to become more firewall friendly, 

Yes -- or be prepared that more traffic is blocked.

> e.g. deprecate IP layer fragmentation, deprecate extension headers

Me, I would deprecate fragmentation, nor would I deprecate extension
headers. I would, however, limit the size of the extension header chain
(to some value... whether 256 bytes, 1280 bytes, or whatever).

> but, do we then also push the Internet
> further away from an open end to end capable Internet, stifle
> innovation in transport etc?

This cat is out of the bug (and has been out of the bag for.. what? 20
years?). Firewalls block unknown traffic.

And from a netadmin pov, you usually want your network to do what's
required to do, and not more than that -- that's what "default deny" is
about.

You don't really want an attacker to hack your network using something
for which there wasn't a legitimate use case (legitimate == such traffic
was needed by the task to be performed, and this was known as such to
the admin).

---

From: joel jaeggli <[email-masked]>
Date: Tue, 11 Jun 2013 14:06:04 +0200

> - 2nd fragment is okay, beacuse you'd apply the fltering policy t the
Wierdly I'm not that interested in a filtering half a dos attack. which 
is probably what happens with amplification and EDNS0 or just some joker 
sending me a metric ton of fragments.

---

From: Ole Troan <[email-masked]>
Date: Tue, 11 Jun 2013 14:12:44 +0200

[...]

> was needed by the task to be performed, and this was known as such to

it is far from that clear cut. it depends on where in the network you are.
in my home at least my hosts are a lot better at dropping unwanted traffic than my CPE is.

I would be interested in an analysis of where and how header parsing is used.

ISP: ECMP, DOS
Enterprise border: Default drop anything I don't understand (firewall), including reassembly of fragments
Data centre border: Only allow legitimate applications?

I don't think there is much the IETF can do with the protocols it designs that will help in the case where
someone operates a "throw anything I don't understand away" policy.

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Jun 2013 14:18:07 +0200

> sending me a metric ton of fragments.

That is a separate issue. The discussion was about which packets were
harmful from an inspection point of view.

Whether to filter fragments or not is a different issues, and probably
depends which device the fragments are destined to, and whether there
can be a legitimate use case for them or not (e.g., you might want to
allow fragments for clients, but drop them if they are destined to your
web server... in the same way that you might filter fragments to your
router, but not through your router).

Cheers,

---

From: "George, Wes" <[email-masked]>
Date: Wed, 12 Jun 2013 19:22:41 -0400

From: [email-masked] [mailto:[email-masked]] On Behalf Of Nalini Elkins

[WEG] The IETF doesn't do compliance testing either. The only teeth in any IETF standard is you as a customer telling a vendor that they must support a set of IETF standards (that you explicitly define by giving them a list), and then doing your own testing to ensure that it meets your requirements, and not buying it or requiring fixes from said vendor if it fails your tests because it didn't implement the standard completely or correctly.

Wes George

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.