Subject: RE: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt> (Implications of Oversized IPv6 Header Chains) to Proposed Standard

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 4 Oct 2013 20:41:35 +0000

Hi, I have a concern about this document. In the definition of "IPv6
Header Chain", it says:

  "However, if a second IPv6 header appears in the header chain, as
   is the case when IPv6 is tunneled over IPv6, the second IPv6
   header is considered to be an upper-layer header and terminates
   the header chain."

This means that stateless firewalls are being directed to discontinue
extension header parsing when a first encapsulated IPv6 header is
encountered - even though there may be many more parsable (inner)
headers that follow. As a result, the firewall would either have to
drop or forward the packet without examining the true upper layer
header. This may result in an incorrect perception that tunneled
traffic is either less reliable or more dangerous than non-tunneled
traffic.

Here are my suggested changes to address this issue:

1) Section 3, under "IPv6 Header Chain", change:

  "However, if a second IPv6 header appears in the header chain, as
   is the case when IPv6 is tunneled over IPv6, the second IPv6
   header is considered to be an upper-layer header and terminates
   the header chain."

to:

  "However, if a second IPv6 header appears in the header chain, as
   is the case when IPv6 is tunneled over IPv6, the second IPv6
   header is optionally considered to be either an upper-layer header
   that terminates the header chain or another extension header that
   continues the chain."

2) Section 3, under "Upper-layer Header", change:

  "In the general case, the upper-layer header is the first member
   of the header chain that is neither an IPv6 header nor an IPv6
   extension header."

to:

  "In the general case, the upper-layer header is the first member
   of the header chain that is not considered to be an extension header."

3) Section 3, under "Upper-layer Header", delete the following sentence:

  "However, if either an ESP header, or a second IPv6 header occur in
   the header chain, they are considered to be upper layer headers and
   they terminate the header chain."

4) Section 5, change the final paragraph to:

  "As a result of the above mentioned requirements, a packet's header
   chain length cannot exceed the Path MTU associated with its
   destination.  Hosts MAY discover the Path MTU, using procedures such
   as those defined in [RFC1981] and [RFC4821].  However, if a host does
   not discover the Path MTU, it MUST limit the header chain length to
   1024 bytes.  Limiting the header chain length to 1024 bytes ensures
   that the header chain length does not exceed the IPv6 minimum MTU
   [RFC2460] even if additional encapsulation headers are inserted by
   tunnels on the path."

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> The IESG
> Sent: Wednesday, October 02, 2013 11:55 AM
> To: IETF-Announce
> Cc: [email-masked]
> Subject: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt>
> (Implications of Oversized IPv6 Header Chains) to Proposed Standard
> 
> 
> The IESG has received a request from the IPv6 Maintenance WG (6man) to
> consider the following document:
> - 'Implications of Oversized IPv6 Header Chains'
>   <draft-ietf-6man-oversized-header-chain-08.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2013-10-16. Exceptionally, comments may
> be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>    The IPv6 specification allows IPv6 header chains of an arbitrary
>    size.  The specification also allows options which can in turn
> extend
>    each of the headers.  In those scenarios in which the IPv6 header
>    chain or options are unusually long and packets are fragmented, or
>    scenarios in which the fragment size is very small, the first
>    fragment of a packet may fail to include the entire IPv6 header
>    chain.  This document discusses the interoperability and security
>    problems of such traffic, and updates RFC 2460 such that the first
>    fragment of a packet is required to contain the entire IPv6 header
>    chain.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-6man-oversized-header-chain/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-6man-oversized-header-
> chain/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 7 Oct 2013 18:13:26 +0000

Hi, I would like to make a small amendment to what I said in my
previous message as follows:

   "As a result of the above mentioned requirements, a packet's header
   chain length MUST fit within the Path MTU associated with its
   destination.  Hosts MAY discover the Path MTU, using procedures such
   as those defined in [RFC1981] and [RFC4821]. However, if a host does
   not discover the Path MTU, it MUST assume the IPv6 minumum MTU of
   1280 bytes [RFC2460]. The host MUST then limit each packet's header
   chain length to the Path MTU minus 256 bytes in case additional
   encapsulation headers are inserted by tunnels on the path."

Thanks - Fred
[email-masked]

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Templin, Fred L
> Sent: Friday, October 04, 2013 1:42 PM
> To: [email-masked]; IETF-Announce
> Cc: [email-masked]
> Subject: RE: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt>
> chain/

---

From: Ole Troan <[email-masked]>
Date: Tue, 8 Oct 2013 18:16:30 +0200

Fred,

>   encapsulation headers are inserted by tunnels on the path."

I would claim that additional encapsulation headers are already considered in the 1280 minimum MTU.
as in: 1500 - 1280.

cheers,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 8 Oct 2013 18:33:57 +0000

Hi Ole,

> From: Ole Troan [mailto:[email-masked]]
> Sent: Tuesday, October 08, 2013 9:17 AM
> To: Templin, Fred L
> Cc: [email-masked]; IETF-Announce; [email-masked]
> Subject: Re: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt>

It is kind of like that, but what I am concerned about is tunnels
in the path that fragment either because they cannot meet the IPv6
minimum MTU without doing so, or because they are trying to allow
a larger-sized MTU when the path doesn't support it due to the
addition of the encapsulating headers.

Take the simplest case when the host assumes a path MTU of 1280.
If there is a tunnel in the path that crosses another 1280 link,
then the tunnel has to fragment, and the header chain might not
all fit within the first fragment if the host does not allow
headspace room. If the host limits the size of its header chain
to 1280 - 512 = 1024 bytes, then the entire chain should fit
within the first fragment even if there are multiple nested
tunnel ingresses on the path and each one of them fragments.

That said, I am wondering how this document relates to the
discussions we had earlier and the resulting draft from Mark
Andrews on what to do when the header chain spans multiple
fragments? Are we trying to keep the header chain all within
the first fragment or not?

Thanks - Fred

---

From: Fernando Gont <[email-masked]>
Date: Tue, 08 Oct 2013 15:51:53 -0300

Hi, Fred,

Thanks so much for your feedback! -- Please find my comments in-line...

On 10/08/2013 03:33 PM, Templin, Fred L wrote:
> then the tunnel has to fragment, 

Well, at least in theory, the tunnel could do Path-MTU... In which case,
if the underlying MTU is of, say, 1500 bytes, then you can probably go
through several layers of encapsulation, without problem.

Besides, while one would probably would nto phrase it like this, truth
is that even 512 f headers would be pretty much non-sensical: Headers
are overhead. So at the point in which you have 50$ of overhead in every
single packet, it starts looking that the inforation is probably being
conveyed in thr wrong place.

That is, in the real world, you would not even get to 1K headers even
ater several layers of encapsulation.

> the first fragment or not?

Yes.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 9 Oct 2013 00:46:27 +0000

I agree with Ole.

       Ron

> Ole Troan
> Sent: Tuesday, October 08, 2013 12:17 PM
> To: Templin, Fred L
> Cc: [email-masked]; [email-masked]; IETF-Announce

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 9 Oct 2013 15:38:14 +0000

> From: Ronald Bonica [mailto:[email-masked]]
> Sent: Tuesday, October 08, 2013 5:46 PM
> To: Ole Troan; Templin, Fred L
> Cc: [email-masked]; [email-masked]

How so? A tunnel that crosses a 1280 MTU link MUST fragment
in order to satisfy the IPv6 minMTU. If it must fragment, then
an MTU-length IPv6 header chain would not fit within the first
fragment, and we have opened an attack vector against tunnels.
This is not a matter to be agreed or disagreed with - it is
a simple fact.

Thanks - Fred

---

From: Ole Troan <[email-masked]>
Date: Wed, 9 Oct 2013 18:53:48 +0200

Fred,

> This is not a matter to be agreed or disagreed with - it is

right, and RFC2460 has this to say about it:

   IPv6 requires that every link in the internet have an MTU of 1280
   octets or greater.  On any link that cannot convey a 1280-octet
   packet in one piece, link-specific fragmentation and reassembly must
   be provided at a layer below IPv6.

cheers,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 9 Oct 2013 17:20:01 +0000

Hi Ole,

> Sent: Wednesday, October 09, 2013 9:54 AM
> To: Templin, Fred L
> Cc: Ronald Bonica; [email-masked]; [email-masked]

Very true. In this case, the "link" is the tunnel and the "link-specific
fragmentation" is IPv6 fragmentation. Which places the first part of an
MTU-length IPv6 header chain in the first fragment and the remainder of
the header chain in the second fragment.

Thanks - Fred

---

From: Ole Troan <[email-masked]>
Date: Wed, 9 Oct 2013 19:31:10 +0200

Fred,

> the header chain in the second fragment.

indeed. which would violate the MUST in oversized-header-chain.

what do we do?
a) ignore this particular corner case
b) suggest the tunnel head end to drop the packet
c) develop a new tunnel segmentations scheme that doesn't depend on IPv6 fragmentation. :-)

cheers,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 9 Oct 2013 17:42:54 +0000

Hi Ole,

> Sent: Wednesday, October 09, 2013 10:31 AM
> To: Templin, Fred L

You know I have an interest in alternative c), but that does not
address the issue of splitting the header chain across multiple
fragments. So, my choice is:

d) limit the size of the IPv6 header chain so that the chain will
fit within the first fragment by having the host limit the chain
to the MTU size minus 256 bytes.

Actually, I would be even happier if we just asked the host to limit
the size of the header chain to 1024 bytes regardless of the path MTU.

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Oct 2013 11:21:34 +1300

Fred,

See below...

> the size of the header chain to 1024 bytes regardless of the path MTU.

Since the problem recurses as we tunnel tunnels, I don't see how any
finite limit can solve the problem. 1280 itself is a pragmatic choice
of "a bit shorter than 1500".

The problem is that you are asserting that middleboxes that a tunnel
passes through are expected to examine the complete header chain of
the encapsulated packet even if the encapsulated packet is a fragment.
I think that's an unreasonable expectation. A reasonable expectation
is that middleboxes should identify the encapsulated packet as
a payload that they cannot analyse, and let it go (unless they
have a policy setting to drop tunnelled packets, which is a
different discussion).

I understood that to be the basis on which the WG reached consensus.

    Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 9 Oct 2013 23:13:11 +0000

Hi Brian,

> the encapsulated packet even if the encapsulated packet is a fragment.

Yes, but change "are expected to" to "should be able to".

> have a policy setting to drop tunnelled packets, which is a

But why? If headers beyond the first IPv6 encapsulation header are
available in the clear, the middlebox should be able to parse them
if it wants to. Wireshark already does exactly that - it keeps on
parsing beyond the first encapsulation header up to and including
the true ULP header. And, if Wireshark can do it, so can any other
middlebox that believes security would be improved by continuing
to parse the entire chain - whether or not there is a standard
saying it must not do so.

Parsing the additional headers beyond the first encapsulation header
provides defense-in-depth. Perimeter middleboxes can then weed out
the bad stuff without either allowing the bad stuff to penetrate more
deeply into the organization or dropping good stuff that should be
allowed through.

> of "a bit shorter than 1500".

The 1280 is assuming that all links in the path have a 1500 MTU and
so RFC2460 allowed (1500 - 1280) = 220 bytes for additional IPv6
headers added by nested tunnels without incurring fragmentation.
I am asserting instead that we have to allow for paths that include
links with a 1280 MTU and so tunnels will have to fragment over
such paths.

That means that the first fragmenting tunnel would have room for
1240 in the first fragment, the second fragmenting tunnel would
have room for 1200 in the first fragment, etc. That is why I would
prefer that hosts limit the size of their header chains to 1024; so
that nested tunnels that fragment will still be highly likely to
have the entire header chain in the first fragment.
 
> I understood that to be the basis on which the WG reached consensus.

Maybe the WG didn't understand that such a consensus would make
tunnels less reliable and less secure.

Thanks - Fred

---

From: Fernando Gont <[email-masked]>
Date: Fri, 11 Oct 2013 05:36:00 -0300

On 10/11/2013 04:48 AM, Ray Hunter wrote:
> 
> I think the draft does what it can in a pragmatic manner, but might
> benefit from some acknowledgement that this security approach of
> applying parsing at a single perimeter can never ever catch all variants
> of transporting FOO over BAR.

FWIW, my idea of the I-D is that it says "look, if you don't put all
this info into the first fragment, it's extremely likely that your
packets will be dropped". That doesn't mean that a middle-box may want
to look further. But looking further might imply
reassemble-inspect-and-refragment... or even reassemble the TCP stream
(e.g. think about a SSL/TCP-based VPN...)

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

---

From: Ray Hunter <[email-masked]>
Date: Fri, 11 Oct 2013 09:48:46 +0200

> Yes, but change "are expected to" to "should be able to".

I personally don't see this going anywhere.

Unless you specifically define what is a "tunnel" and you specifically
define a maximum depth of nesting.

The term Upper-Layer Protocol (ULP) is also itself a vague term IMHO
since the value of the "IPv6 next header" is taken from the same code
space as the ULP header values, and there's no specific marker or
"header length" field in IPv6 that explicitly marks a point as "This is
the end of the IPv6 header chain in all circumstances: stop header
parsing here."

Ok, there's a bunch of current code-points that are today considered as
valid ULP's or next-header values, but that is neither time invariant
nor exhaustive, so solving this issue via a registry means there will
always be middlebox code in the wild that lags any updates.

These middleboxes won't be able to differentiate between an unknown ULP,
and an unknown IPv6 next-header. That potentially makes a default pass
or drop decision awkward.

If it's so important to be able to differentiate between what is an ULP
and what is a next header, and we can't reliably do that today, maybe
that's a fundamental flaw in IPv6 that should be addressed.

> saying it must not do so.

Because it leaves open the possibility for an attacker to apply the
obfuscation we seek to limit.

> deeply into the organization or dropping good stuff that should be

There's also a myriad of tunneling technology out there.

Again, what is an ULP? Where do you stop parsing?

Is GRE a tunnel or an ULP? (GRE can run over almost anything)
Is SSH an ULP or a tunnel? (port tunneling)
Is Teredo a tunnel or is it an ULP (UDP) or both?
GRE/ LT2P over HTTP anyone?

The notion of "perimeter" is moveable in the presence of such tunnels.

Presumably there comes a point where the tunnel is terminated and the
transported packet is de-encapsulated, and that IMHO forms another
perimeter where you'd anyway have to apply further security checks.

IMHO It's only at the moment of de-encapsulation that the full semantics
of the payload are revealed in these modern times of "everything
transported over HTTP".

>> of "a bit shorter than 1500".

Agreed.

-- 
Regards,
RayH

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Oct 2013 15:33:17 +0000

Hi Ray,

> From: Ray Hunter [mailto:[email-masked]]
> Sent: Friday, October 11, 2013 12:49 AM
> To: Templin, Fred L; [email-masked]
> Cc: [email-masked]; 6man Mailing List
> Subject: Re: RE: Last Call: <draft-ietf-6man-oversized-header-chain-
> 08.txt> (Implications of Oversized IPv6 Header Chains) to Proposed
> Standard
> 
> Templin, Fred L wrote:
> > Hi Brian,
> >

The middlebox stops parsing when it decides it has seen enough. With
Wireshark at least, it blasts right through encapsulating IP headers
and continues up to and including the ultimate TCP/UDP/ICMP etc.
header inserted by the original host. The goal is to give the
middlebox enough information so that it can parse as deeply into
the headers as it wants to.

> The notion of "perimeter" is moveable in the presence of such tunnels.

We will want for middleboxes at outer perimeters to be able to parse
as many headers as they want to before releasing the packet to
middleboxes at inner perimenters. Otherwise, bad stuff can get past
the outermost perimeters and waste bandwidth and/or cause havoc
within the protected zone. 

> perimeter where you'd anyway have to apply further security checks.

Nested tunnels give you perimeters within perimeters, yes. But, we
will want the outer perimeters to be able to parse as deeply as
they want to before passing on to an inner perimeter.

> >> of "a bit shorter than 1500".

I guess I will have to repeat myself from what I said several
months ago. The 1280 came from a desire to have multiple nested
tunnels without requiring the tunnels to fragment since the
underlying links presumably all configure a 1500 MTU. But, what
would that look like in real life?

- The first tunnel would have to configure a 1280 MTU so that its
  encapsulated packets emerged as 1320
- the second tunnel would have to configure a 1320 MTU so that its
  encapsulated  packets emerged as 1360
- the third tunnel would have to configure a 1360 MTU so that its
  encapsulated packets emerged as 1400
- etc.

But, in real life, it is not possible to assume that we can lay
hands on all tunnel endpoints so as to carefully set MTUs that
satisfy the nesting level - and, when multiple administrative
domains are involved, it can't be done at all.

Please go back in the archives to where I posted the derivation
of the 1280 minMTU (circa 1997):

http://www.ietf.org/mail-archive/web/ipv6/current/msg18462.html

My conclusion is that the 1280/1500 was well intentioned, but
unfortunately not very well thought out.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Oct 2013 15:36:00 +0000

Hi Fernando,

> From: Fernando Gont [mailto:[email-masked]]
> Sent: Friday, October 11, 2013 1:36 AM
> To: Ray Hunter; Templin, Fred L; [email-masked]
> Cc: 6man Mailing List; [email-masked]

We definitely don't want that. That is why we would prefer for
the entire header chain (starting from the outermost IP header
up to and including the headers inserted by the original host)
to fit within the first fragment even if there are multiple
encapsulations on the path.

Thanks - Fred

---

From: Fernando Gont <[email-masked]>
Date: Fri, 11 Oct 2013 14:04:11 -0300

> encapsulations on the path.

The problem is that if you have multiple encapsulations, you can always
hit the MTU limit and fail to comply with this requirement.

That's why this I-D says what it says.

P.S.: Reegarding enforcing a limit on the length of the header chain, I
must say I symphatize with that (for instance, check the last individual
version of this I-D, and you'll find exactly that). But the wg didn't
want that in -- and I did raise the issue a few times. So what we have
is what the 6man wg had consensus on.

Thanks!

Cheers,

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Oct 2013 17:35:46 +0000

Hi Ray,

> Sent: Friday, October 11, 2013 9:59 AM
> To: Templin, Fred L
> Cc: [email-masked]; [email-masked]; 6man Mailing List
> > Templin, Fred L <mailto:[email-masked]>
> > 11 October 2013 17:33
> > Hi Ray,
> >
> > The middlebox stops parsing when it decides it has seen enough.
> 
> Which AFAIK is undefined in practical terms. Especially in the presence
> of jumbo payload extension headers or fragments.

Middleboxes should be able to parse as far as they want to
without hitting a hard stop as is the case if the header
chain extends into multiple packets.

> So are you saying the current draft has no value?

I am saying that it is unfriendly to tunnels that fragment, and a
simple fix is for the host to limit its header chain length to
1024 bytes.

> >  With
> > header inserted by the original host.
> 
> I like wireshark.
> 
> But how would that parsing model work in a live network without
> maintaining state between frames (and leaving your middlebox open to
> DoS
> or other resource depletion abuse)?

I don't understand the "maintaining state between frames". I am
talking about examining individual header chains within a single
packet independently of any other packets.

We may not yet know how smart middleboxes may become in this
regards. But, they will certainly never become smart enough if
they don't have the entire header chain in the first fragment. 

> IMHO "ultimate TCP/UDP/ICMP etc." is not defined. The IETF does not
> define standard protocol stacks as a totality. HTTP over TCP over IPv6
> over L2TP over GRE over PPTP VPN over IPv6 over IPv6 is not illegal. So
> this would seem to require far tighter specs on packet formats than the
> IETF would ever publish (and rightly so).

Not at all. This is about allowing middleboxes to parse through all
of the headers included by the host and any tunnel endpoints that
may have interposed themselves between the host and the middlebox.
How the middlebox parses is its own business.
 
> >  The goal is to give the
> If that is the goal then we probably need to deprecate IPv6
> fragmentation as well as a whole bunch of tunnel / encryption protocols
> IMHO, and specify that the entire packet has to fit in a single frame.
> Which I feel is unrealistic.

Not at all. The proposal is to ask the host to limit its header
chain to 1024 bytes to allow for up to 256 bytes of encapsulation
headers before the header chain would be susceptible to
fragmentation.

> Right. But if your firewall (which now has to maintain state, or which
> is forced to parse right to the end of a packet) itself becomes the
> bottleneck and the DoS target, what have you gained?

No inter-packet state - I never said or implied that. And, no one
is *forcing* the middlebox to do anything. This is about *allowing*
the middlebox to do whatever it wants.
 
> I think my customers will have to start thinking in terms of an onion
> skin model, rather than a single outer perimeter and a single "trusted"
> zone.
> Maintaining state, or full-packet-depth parsing, at the point where the
> enterprise hits the Internet is probably not going to fly.

Onion skin, yes, with each layer of the onion doing what it can
to enhance security. That is what I mean by defense in depth.

> It doesn't matter what number you pick, and 1280 is probably as good as
> it gets. The point from Brian (if I understood it correctly) was that
> any fixed number can never be sufficient, as there's no dedicated
> portion of the IPv6 MTU specifically assigned to tunneling, and no
> defined max tunnel nesting depth.

A fixed number does not limit the number of tunnel nestings, but
it does limit how many nestings can be applied before the header
chain might wrap into a second fragment. But, how many nestings
do you want? If you want up to 6 or so, then the 1024 gives adequate
space. If you want something like 10 or more, then the extension
header chain could theoretically wrap into second fragments.

Remember that the 1280/1500 was to "allow extra room" for tunnels
to add encapsulation headers without causing fragmentation. That
goal also had a fixed upper bound of 220 bytes of room so the
number of nested tunnels was limited by that action as well
(even assuming you could get the tunnel endpoints to cooperate
and make efficient use of the 220). For better or worse, 1280
gave us a fixed number that we will be stuck with forever.

Thanks - Fred

> > ---------------------------------------------------------------------
> ---
> 
> 
> --
> Regards,
> RayH

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Oct 2013 17:51:12 +0000

Hi Fernando,

> Sent: Friday, October 11, 2013 10:04 AM
> To: Templin, Fred L; Ray Hunter; [email-masked]

Yes you can, which is what I just said to Ray. But, I am not talking
about a *requirement* - I am talking about a best practice that works
in most cases.

The question is how many layers of encapsulation do you need? Let's
say you want 5 layers of encapsulation. That would still allow enough
room for all of the hosts headers to fit in the first fragment if the
host limits its header chain to 1024 bytes. But, now let's say that
you want 10 layers of encapsulation. That means that the first 5
middleboxes that examine the outermost encapsulations will not be
able to see the entire header chain, but the last 5 middleboxes that
examine the innermost encapsulations will. So, there is a limit to
the levels of defense-in-depth. But, that limit is greater than 1.

Remember also that the 1280/1500 also assumed that there would be
"just a few" layers of nested encapsulations. What I am suggesting
allows for endless recursion but limited (and reasonable) defense
in depth. 
 
> That's why this I-D says what it says.

I'm not sure this discussion was taken into account, and what the
draft says now is not friendly to tunnels.

> is what the 6man wg had consensus on.

It is not too late to get this right, and to give reasonable
treatment to tunnels that the current draft does not give.

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Oct 2013 08:49:44 +1300

On 12/10/2013 06:04, Fernando Gont wrote:
...
> is what the 6man wg had consensus on.

I agree that this was the WG consensus after considerable discussion,
which included Fred, so I'm not sure why we're discussing it again
during IETF LC.

   Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Oct 2013 19:56:44 +0000

Hi Brian,

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Friday, October 11, 2013 12:50 PM
> To: Fernando Gont
> Cc: Templin, Fred L; Ray Hunter; 6man Mailing List; [email-masked]

Technical matters should be discussed as they come to light; not
dismissed because of some real or perceived deadline. That was what
got us the 1280 MTU in the first place. Quoting from Steve Deering:

  " We would like to get this issue settled as
    soon as possible, since this is the only thing holding up the publication
    of the updated Proposed Standard IPv6 spec (the version we expect to advance
    to Draft Standard), so let's see if we can come to a decision before the ID
    deadline at the end of next week (hoping there isn't any conflict between
    "thoughtful analysis" and "let's decide quickly" :-)."

So, it wasn't necessarily the case that 1280 was a product of "thoughtful
analysis" so much as the fact that **they were rushing to get a spec out
the door**. So now, 16 years later, we get to put it back on the 6man
charter milestone list.

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Oct 2013 11:42:00 +1300

Fred,

> the door**. So now, 16 years later, we get to put it back on the 6man

We could have that discussion in 6man, sure, but I don't believe that it's
relevant to the question of whether draft-ietf-6man-oversized-header-chain
is ready. This draft mitigates a known problem in terms of the current
IPv6 standards.

    Brian

---

From: Ronald Bonica <[email-masked]>
Date: Sun, 13 Oct 2013 02:06:44 +0000

+1

Is there a way to decouple this discussion from draft-ietf-6man-oversized-header-chain? I would be glad to discuss it in the context of a separate draft.

                                                             Ron

> >
> > So, it wasn't necessarily the case that 1280 was a product of
> > "thoughtful analysis" so much as the fact that **they were rushing to
> > get a spec out the door**. So now, 16 years later, we get to put it
> > back on the 6man charter milestone list.
> 
> We could have that discussion in 6man, sure, but I don't believe that
> it's relevant to the question of whether draft-ietf-6man-oversized-
> header-chain

---

From: SM <[email-masked]>
Date: Sat, 12 Oct 2013 22:00:00 -0700

>final comments on this action. Please send substantive comments to the

This document intends to update the IPv6 specification.  I looked 
into some code (host) which would be affected by the RFC 2119 
requirement in Section 5.  The code is complex as it is.  I am not 
sure whether the requirement can be implemented without too much 
difficulty.  I have not looked into the code which processes inbound packets.

Regards,
-sm

---

From: Ronald Bonica <[email-masked]>
Date: Sun, 13 Oct 2013 23:55:21 +0000

SM,

Are you suggesting that we don't address the problem because the code is too complex to touch?

                                         Ron

> SM
> Sent: Sunday, October 13, 2013 1:00 AM
> To: [email-masked]
> This document intends to update the IPv6 specification.  I looked into
> some code (host) which would be affected by the RFC 2119 requirement in
> Section 5.  The code is complex as it is.  I am not sure whether the
> requirement can be implemented without too much difficulty.  I have not
> looked into the code which processes inbound packets.
> 
> Regards,
> -sm
> 
> 
>

---

From: Ray Hunter <[email-masked]>
Date: Fri, 11 Oct 2013 18:58:33 +0200

I like wireshark.

But how would that parsing model work in a live network without
maintaining state between frames (and leaving your middlebox open to DoS
or other resource depletion abuse)?

> ------------------------------------------------------------------------

-- 
Regards,
RayH

---

From: SM <[email-masked]>
Date: Mon, 14 Oct 2013 08:19:48 -0700

Hi Ron,
>code is too complex to touch?

It's a known problem since at least seven years.  Given that the 
problem is labelled as a security issue there would have to be some 
changes to the specification at some point.  There were design 
decisions to implement the specification and the code has been 
deployed.  The proposed outbound change is one sentence.  The code 
change to implement that one sentence requires reviewing some 
implementation decisions (re. encapsulation, etc.).  Please note that 
I am not arguing for or against a change in the RFC 2119 key 
words.  The write-up only mentions that the draft has been 
implemented on stateless firewalls.  I am curious about whether there 
are any implementations for a host.

Regards,
-sm

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 14 Oct 2013 17:38:00 +0000

Hi Brian,

> Sent: Friday, October 11, 2013 3:42 PM
> To: Templin, Fred L
> Cc: Fernando Gont; Ray Hunter; 6man Mailing List; [email-masked]
> >>> P.S.: Reegarding enforcing a limit on the length of the header
> chain,
> >> I
> "thoughtful
> it's
> is ready.

If it messes up tunnels, then it's not ready.

> This draft mitigates a known problem in terms of the current
> IPv6 standards.

If that problem is also mitigated by a measure that does not mess
up tunnels, then wouldn't that be worth considering before
finalizing this publication.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 14 Oct 2013 17:39:29 +0000

Hi Ron,

> Sent: Saturday, October 12, 2013 7:07 PM
> To: Brian E Carpenter; Templin, Fred L
> Cc: Fernando Gont; 6man Mailing List; [email-masked]; Ray Hunter
> Is there a way to decouple this discussion from draft-ietf-6man-
> oversized-header-chain? I would be glad to discuss it in the context of
> a separate draft.

I don't know if there is a way to decouple it. I believe I have shown
a way to not mess up tunnels while at the same time not messing up your
draft. That should be a win-win. In what way would imposing a 1K limit
on the IPv6 header chain not satisfy the general case?

Thanks - Fred

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 14 Oct 2013 17:46:37 +0000

Not that I am aware of.....

> From: SM [mailto:[email-masked]]
> Sent: Monday, October 14, 2013 11:20 AM
> To: Ronald Bonica
> Cc: [email-masked]
> implementation decisions (re. encapsulation, etc.).  Please note that I
> am not arguing for or against a change in the RFC 2119 key words.  The
> write-up only mentions that the draft has been implemented on stateless
> firewalls.  I am curious about whether there are any implementations
> for a host.
> 
> Regards,
> -sm
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Oct 2013 08:34:21 +1300

Fred,

On 15/10/2013 06:38, Templin, Fred L wrote:
...
> If it messes up tunnels, then it's not ready.

That doesn't follow. See below.

> finalizing this publication.

The draft mitigates a known problem with communication paths that
do not include nested tunnels requiring nested fragmentation,
where the nested tunnel has to deal with an MTU <1280 *and* where
the nested tunnel goes through a firewall that wants to analyse
the complete header chain of the innermost packet.

No, I don't think it's worth considering that case before specifying
this mitigation.

     Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 14 Oct 2013 19:55:02 +0000

Hi Brian,

> Sent: Monday, October 14, 2013 12:34 PM
> To: Templin, Fred L
> >> relevant to the question of whether draft-ietf-6man-oversized-
> header-
> >> chain
> >> is ready.
> >

But tunnels - and tunnels within tunnels - need to be considered
as part of the architecture. I have visibility into the network
operations of a major multi-national corporation, and I can tell
you that I see tunnels within tunnels in operational practice today.
I also have visibility into civil aviation and DoD networks, and
I see an emerging trend for mobile networks. Consider a mobile
network B that comes onto a link offered by mobile network A.
Then, mobile network C comes onto a link offered by B. Then, etc.
Then, the next thing you know, it's turtles all the way down.

Fragmentation is the tool that enables endless recursion. Or, at
least, recursion up to some defined limit. At least for the first
several levels of recursion, middleboxes should be able to see all
host-inserted headers within the first fragment.

Thanks - Fred

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 15 Oct 2013 15:31:16 +0900

> tunnel ingresses on the path and each one of them fragments.

Why do you think the first fragment is considerably longer
than 1024B?

As is specified in rfc791:

      In the above procedure each fragment (except the last) was made
      the maximum allowable size.  An alternative might produce less
      than the maximum size datagrams.  For example, one could implement
      a fragmentation procedure that repeatly divided large datagrams in
      half until the resulting fragments were less than the maximum
      transmission unit size.

it is allowed (and is better) to fragment a 1300B packet into two
mostly equally sized (about 700B) packets than two packets of a
1280B (or 1276B) one and a much shorter one.

It is especially so when tunnels with outer MTU of 1280B, which
can carry 700B (but not 1276B/1280B) packets without further
fragmentation, are used.

You should also assume that outer IP of a tunnel may also have
its own lengthy extension headers, length of which must also
be restricted (much below 1280B).

Note also that DNS requires each UDP packet carry a 512B message,
header chain (including UDP header) must be shorter than 989B
(minimum reassembly buffer size of IPv6 is 1500B).

Worse, as some extension headers are inserted without application
control, e.g.:

   In that case, the IPv6 node
   is not required to reduce the size of subsequent packets to less than
   1280, but must include a Fragment header in those packets so that the
   IPv6-to-IPv4 translating router can obtain a suitable Identification
   value to use in resulting IPv4 fragments. [rfc2460]

and

   The Home Address option is carried by the Destination Option
   extension header (Next Header value = 60).  It is used in a packet
   sent by a mobile node while away from home, to inform the recipient
   of the mobile node's home address. [rfc3775]

it is really hard, if not impossible, to let transport/application
protocols (such as DNS and TCP) adjust payload size to avoid
fragmentation. As noted above, even with fragmentation, DNS can't
adjust payload size below 512B.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 15 Oct 2013 15:50:37 +0900

Templin, Fred L wrote:

> headers that follow.

Even without tunnels, firewalls MUST be able to parse ICMPv6 error
messages generated behind it, even though ICMPv6 is explicitly
allowed to have its own lengthy header chain:

   Every ICMPv6 message is preceded by an IPv6 header and zero or more
   IPv6 extension headers. [rfc2463]

Even without firewalls, ICMPv6 still causes a problem because:

           As much of invoking packet
       as will fit without the ICMPv6 packet
       exceeding the minimum IPv6 MTU [IPv6] [rfc2463]

a host sending the original packet can not identify which packet
sent by it caused the error, if tail part of header-chain of
inner packet is omitted.

						Masataka Ohta

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 15 Oct 2013 13:55:23 +0000

Hi Ray,

> Sent: Monday, October 14, 2013 2:07 PM
> To: Templin, Fred L
> Cc: Ronald Bonica; Brian E Carpenter; Fernando Gont; 6man Mailing List;
> [email-masked]
> > 14 October 2013 19:39
> This draft may not go as far as you'd like (e.g. specifying a hard
> limit
> on header length as some proportion of MTU), and I'm also aware of the
> issue of MTU fragmentation and nested tunnels, but I'm still not clear
> on how this draft specifically "messes up tunnels."
>
> Can you explain what specific text in the current draft you consider
> harmful?

That hosts would be permitted to send MTU-sized header chains.

> And why that couldn't be dealt with in a later draft (that imposes
> additional limits on header chains in specific scenarios)?

Once a spec says that a host is permitted to send MTU-sized header
chains the die is cast and no later draft will be able to undo it.
The host has no idea that there may be one or more tunnels in the
path, and so has no way of knowing to alter its behavior to be
kind to tunnels.

That, plus the fact that attackers will be able to craft packets
intended to fool middleboxes by sending a fragmented tunneled
packet with the "good" part of the header chain in the first
fragment and the "bad" part of the header chain in the second
fragment.

Thanks - Fred

> Thanks.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 15 Oct 2013 14:04:03 +0000

Hi Brian,

> the complete header chain of the innermost packet.

I want to say one more word on this. You seem to be indicating that
you see what I have been explaining as a corner case. But, I believe
that in order to fix the tunnel MTU issue we will need SEAL or
something very much like it.

SEAL uses fragmentation on the first few packets regardless of the
path MTU to ensure that "middle sized" packets between 1280-1500
get through. It then turns off the fragmentation using a probing
scheme in the spirit of RFC4821. So, those first few packets that
could contain a header chain that spills over into the second
fragment are what concerns me. And, this will not be a corner
case when SEAL is used in wider deployment.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 15 Oct 2013 18:50:11 +0000

Hi Ray,

> Sent: Tuesday, October 15, 2013 9:30 AM
> To: Templin, Fred L
> > 15 October 2013 15:55
> >>>> oversized-header-chain? I would be glad to discuss it in the
> context
> >> of
> >>>> a separate draft.
> They can do that today. In fact they can legally send n* MTU-sized
> header chains, as long as the total length of an IPv6 packet is not
> exceeded.

Sure, but this draft is about setting healthy limits where there were
previously none.

> Why not? If this is a "maximum", there may always be scenarios where
> less than a maximum is appropriate.

This draft is intending to update RFC2460. Once updated, the
maximum header size requirements are cast in stone.

> RFC 2473 is pretty explicit about how to handle fragmentation (in the
> presence of nested IPv6 tunnels).
> 
> Once a packet is encapsulated in a tunnel it becomes a new "original
> packet" for the next tunnel in any nested tunnel scenario.
> 
> And PMTUD on the originating host (whether that's the original host, or
> the tunnel entry point at the previous nesting level) should receive a
> signal if the current tunnel entry node cannot handle encapsulation due
> to MTU issues (Section 7 of RFC 2473). So the originating host should
> always be informed of the MTU issue, and be able to alter its behavior
> accordingly.

We would have to go back into the long discussions on PMTUD brokenness
to show why you can't always rely on it. Hosts are *guaranteed* 1280,
but they *expect* 1500. Absent signaling from the network, that is
all they know. 

> So again, I don't see what's new in this draft.
> IMHO They can do that today (and worse).

Sure. That's because there are currently no healthy limits set. This
draft is about setting healthy limits; I am saying that as long as
we are making the effort we should get it right.

Thanks - Fred

> >>>>>> "thoughtful analysis" so much as the fact that **they were
> rushing
> >>>> to

---

From: Ray Hunter <[email-masked]>
Date: Mon, 14 Oct 2013 23:06:38 +0200

> [email-masked]

This draft may not go as far as you'd like (e.g. specifying a hard limit
on header length as some proportion of MTU), and I'm also aware of the
issue of MTU fragmentation and nested tunnels, but I'm still not clear
on how this draft specifically "messes up tunnels."

Thanks.

-- 
Regards,
RayH

---

From: Ray Hunter <[email-masked]>
Date: Tue, 15 Oct 2013 18:29:44 +0200

---

From: Fernando Gont <[email-masked]>
Date: Tue, 15 Oct 2013 20:26:10 -0300

> If it messes up tunnels, then it's not ready.

FWIW I disagree with this statement. From this perspectie, you'd also
expect middleboxes (e.g. load-balancers) to get deep into any layers of
tunnelling to decide on which link packets should be forwarded. -- and
this is clearly unrealistic (if at all desirable).

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 15 Oct 2013 20:30:15 -0300

> on the IPv6 header chain not satisfy the general case?

6man had consensus multiple times on *not* to impose this sort of limits
in this document (that's why the original limit of 1280 bytes was
removed from earlier versions of this I-D in the first place).

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 16 Oct 2013 01:09:51 -0300

On 10/14/2013 12:19 PM, SM wrote:
> It's a known problem since at least seven years.  Given that the problem
> is labelled as a security issue there would have to be some changes to
> the specification at some point.  There were design decisions to
> implement the specification and the code has been deployed.  The
> proposed outbound change is one sentence.  The code change to implement
> that one sentence requires reviewing some implementation decisions (re.
> encapsulation, etc.).  Please note that I am not arguing for or against
> a change in the RFC 2119 key words.  The write-up only mentions that the
> draft has been implemented on stateless firewalls.  I am curious about
> whether there are any implementations for a host.

There can't be implementations for hosts because this spec uses an
ICMPv6 type/code that is to be assigned by IANA upong approval of this
document.

That aside, I don't follow your reasoning. If you think the code
required for this spec is complex, take a look at e.g. the TCP code.

Thanks,

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 16 Oct 2013 15:08:11 +0000

Hi Fernando,

To repeat what has already been said many times (and hopefully for
just one final time), if the host is permitted to include an MTU-sized
header chain and if there is a tunnel on the path that needs to fragment
for whatever reason, then that header chain is going to spill into a
second fragment. Then, middleboxes that wish to examine the entire
header chain in the first fragment for whatever reason will be unable
to do so. Consensus or no, those are the facts.

Thanks - Fred

> Sent: Tuesday, October 15, 2013 4:30 PM
> To: Templin, Fred L; Ronald Bonica; Brian E Carpenter
> Cc: 6man Mailing List; [email-masked]; Ray Hunter; 6man-
> [email-masked]

---

From: Ole Troan <[email-masked]>
Date: Wed, 16 Oct 2013 17:28:52 +0200

Fred,

> to do so. Consensus or no, those are the facts.

absolutely.

the outer IPv6 header is a new datalink for the inner IPv6 header. there is no architectural difference if that L2 is IPv6, IPv4 or PPP. take IPv4 or PPP as an example, if PPP provides fragmentation, then there is no expectation that the PPP or IPv4 layer keeps the payload IPv6 header chain in one PPP or IPv4 fragment.

the rules in this document are not recursive. the header chain terminates as soon as another IPv6 header is encountered.

does that clarification help?
I'm not quite sure if the document is clear enough on this point.

Best regards,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 16 Oct 2013 15:45:07 +0000

Hi Ole,

> Sent: Wednesday, October 16, 2013 8:29 AM
> To: Templin, Fred L
> Cc: Fernando Gont; Ronald Bonica; Brian E Carpenter; 6man-
> [email-masked]; Ray Hunter; 6man Mailing List; [email-masked]
> the outer IPv6 header is a new datalink for the inner IPv6 header.
> there is no architectural difference if that L2 is IPv6, IPv4 or PPP.
> take IPv4 or PPP as an example, if PPP provides fragmentation, then
> there is no expectation that the PPP or IPv4 layer keeps the payload
> IPv6 header chain in one PPP or IPv4 fragment.
> 
> the rules in this document are not recursive. the header chain
> terminates as soon as another IPv6 header is encountered.

I disagree with the header chain terminating as soon as another IPv6
header is encounter. That defeats defense-in-depth, since outer
perimeter middleboxes would be forced to admit packets with unexamined
header chains inward to inner perimeter middleboxes. And, if the
unexamined header chains contain bad stuff inserted by an attacker,
the attack is successful.

That requirement is also not observed by common middlebox systems
such as Wireshark and tcpdump. Both will blast past encapsulating
IPv6 headers through to the header chain inserted by the original
host without stopping at the outermost IPv6 header.

Thanks - Fred

---

From: Fernando Gont <[email-masked]>
Date: Wed, 16 Oct 2013 13:09:05 -0300

Hi, Fred,

On Wed, Oct 16, 2013 at 12:45 PM, Templin, Fred L <[email-masked]
> wrote:

> the attack is successful.

The same is true if the underlying encapsulation layer is IPv4. Once you're
encapsulating, all bets are off in that respect. You should do
defense-in-depth at the tunnel ingress or egress points. Or, if you wish, a
middle-box could reassemble-inspect/filter-re-fragment

Note that no matter what hardcoded limit you enforce, an attacker willing
to evade you're security controls can always add an extra-layer of
encapsulation (assuming he controls that). Also, common security policy is
"default deny" -- so if the attacker plays dirty, his packets will be
dropped.

> host without stopping at the outermost IPv6 header.

They do what a middle-box would do in this case: whatever part of the
header chain is there, it's up to you to inspect it. As noted by Ole, when
you tunnel over IP, IP becomes a link layer... so whatever "defense in
depth" techniques you're using, they should be prepared to deal with
scenarios in which a tunneled packet does not contain the entire IPv6
header chain, since not all "link layers" (as IPv4 when IPv6 is tuneled
over IPv4) guarantee a minimum MTU of 1280 bytes.

Thanks,
Fernando

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 16 Oct 2013 16:20:19 +0000

Fernando,

Can you please re-send in plaintext, as all of the other messages in this thread
have been? Richly formatted text makes annotation impossible.

Thanks - Fred

From: [email-masked] [mailto:[email-masked]] On Behalf Of Fernando Gont
Sent: Wednesday, October 16, 2013 9:09 AM
To: Templin, Fred L
Cc: Ole Troan; [email-masked]; 6man Mailing List; [email-masked]; Ray Hunter; Fernando Gont
Subject: Re: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt> (Implications of Oversized IPv6 Header Chains) to Proposed Standard

Hi, Fred,

On Wed, Oct 16, 2013 at 12:45 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

The same is true if the underlying encapsulation layer is IPv4. Once you're encapsulating, all bets are off in that respect. You should do defense-in-depth at the tunnel ingress or egress points. Or, if you wish, a middle-box could reassemble-inspect/filter-re-fragment
Note that no matter what hardcoded limit you enforce, an attacker willing to evade you're security controls can always add an extra-layer of encapsulation (assuming he controls that). Also, common security policy is "default deny" -- so if the attacker plays dirty, his packets will be dropped.

They do what a middle-box would do in this case: whatever part of the header chain is there, it's up to you to inspect it. As noted by Ole, when you tunnel over IP, IP becomes a link layer... so whatever "defense in depth" techniques you're using, they should be prepared to deal with scenarios in which a tunneled packet does not contain the entire IPv6 header chain, since not all "link layers" (as IPv4 when IPv6 is tuneled over IPv4) guarantee a minimum MTU of 1280 bytes.
Thanks,
Fernando

---

From: Fernando Gont <[email-masked]>
Date: Wed, 16 Oct 2013 13:34:47 -0300

[Resending in plain-txt -- my apologies... I was using a web interface...]

Fred,

> the attack is successful.

The same is true if the underlying encapsulation layer is IPv4. Once
you're encapsulating, all bets are off in that respect. You should do
defense-in-depth at the tunnel ingress or egress points. Or, if you
wish, a middle-box could reassemble-inspect/filter-re-fragment

Note that no matter what hardcoded limit you enforce, an attacker
willing to evade you're security controls can always add an
extra-layer of encapsulation (assuming he controls that). Also, common
security policy is "default deny" -- so if the attacker plays dirty,
his packets will be dropped.

They do what a middle-box would do in this case: whatever part of the
header chain is there, it's up to you to inspect it. As noted by Ole,
when you tunnel over IP, IP becomes a link layer... so whatever
"defense in depth" techniques you're using, they should be prepared to
deal with scenarios in which a tunneled packet does not contain the
entire IPv6 header chain, since not all "link layers" (as IPv4 when
IPv6 is tuneled over IPv4) guarantee a minimum MTU of 1280 bytes.

Thanks,
Fernando

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 16 Oct 2013 16:54:17 +0000

Hi Fernando,

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Fernando Gont
> Sent: Wednesday, October 16, 2013 9:35 AM
> To: Templin, Fred L
> Cc: Ole Troan; Ronald Bonica; Brian E Carpenter; 6man-
> [email-masked]; Ray Hunter; 6man Mailing List; [email-masked];
> Fernando Gont
> The same is true if the underlying encapsulation layer is IPv4.

We should not default to doing as badly as IPv4.

> Once

If an outer perimeter middlebox connects to a 10Gbps link on its
outward facing interface and a 64Kbps link on its inward facing
interface, then the middlebox can allow a successful DOS attack
against its protected domain if it does not look at headers beyond
the outermost IPv6 header.

> extra-layer of encapsulation (assuming he controls that).

Yes. With a 1024 limit on the amount of extension headers a
host can add, approximately 5-6 encapsulations can be added
before the tunnel headers cause the header chain to overflow
the IPv6 minMTU. But, that means that there would still be
5-6 protected perimeters to penetrate before an attack could
penetrate through to the innermost protected domain. This is
considerable defense-in-depth.

> Also, common

Without looking past the outermost IP header, there is no way
to discern the good stuff from the bad stuff. So, default
deny will potentially drop good stuff.

> IPv6 is tuneled over IPv4) guarantee a minimum MTU of 1280 bytes.

The 1024 proposal gives 256 bytes of room for encapsulation headers
and still fit within the IPv6 minMTU - enough for 5-6 layers of defense
in depth. This is part of the analysis I believe was missing when the
IPv6 minMTU of 1280 was established.

One clarification I would like to make is that I *like* the 1280
IPv6 minMTU and do not think it was a mistake. It was the missing
analysis of what it means for tunnels that I think we are only
now exploring.

Thanks - Fred

---

From: Fernando Gont <[email-masked]>
Date: Wed, 16 Oct 2013 14:04:46 -0300

> We should not default to doing as badly as IPv4.

The point is that this is no worse than IPv4. And it is very likely
that one of underlying encapsulations will be IPv4.

> the outermost IPv6 header.

Is it me, or there are actually a plethora of attack vectors an
attacker would use (instead of this one) in such scenario?

> the IPv6 minMTU.

That depends on whether extension headers are employed in different
layer of encapsulation.

Besides, what's the different between an attacker exceeding your
hardcoded limit and traffic resulting in tunnling packets failing to
include the entire header chain?

As noted off-list, this hard limit becomes a BCP, rather than a std
update: the larger your extension header chain, the higher the chances
that your packets get dropped. For instance, your harcoded 1000 (or
whatever) value means that there are still *lots* of boxes that will
not be able to handle those packets properly, and hence will get
dropped (check the 6man and/or v6ops discussions).

Thanks,
Fernando

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 16 Oct 2013 17:22:57 +0000

Hi Fernando,

> Sent: Wednesday, October 16, 2013 10:05 AM
> To: Templin, Fred L

If an underlying encapsulation is IPv4, there is a very good
chance that the IPv4 path MTU is at least 1280. Else, the
underlying link with MTU smaller than 1280 is very likely to
be low speed. That being the case, the middlebox would have to
perform IPv4 reassembly, yes. But, that is truly a corner case,
and only when IPv4 is involved. Again, we should be striving
to do better than IPv4.

> attacker would use (instead of this one) in such scenario?

Please don't discount this scenario as contrived or unlikely; there
are certainly such low-end data links in real deployments (civil
aviation networks, DoD networks, etc.) that need DOS protection.

> That depends on whether extension headers are employed in different

Most tunneling protocols I am aware of do not specify that additional
extension headers can be added (one exception is the Encapsulation Limit
option specified by RFC2473). So, it should be reasonable for a middlebox 
to drop an encapsulated packet with an unusually long encapsulation
extension header chain inserted by the purported tunnel ingress. 
 
> include the entire header chain?

The hard-coded limit is 5-6 layers of encapsulation headers fitting
within the IPv6 minMTU but that does not stop tunnels from recursing
indefinitely. What it does do is provide a healthy number of layers
of defense in depth.

> dropped (check the 6man and/or v6ops discussions).

That's OK. Let the BCP for hosts be 1024, and I am happy.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 17 Oct 2013 13:44:09 +0000

Hi Fernando,

I want to revisit a point that needs to be corrected:

> The point is that this is no worse than IPv4.

Why should it be as bad as IPv4 when it can be better? IPv4
middleboxes that wish to do deep packet inspection may need to
gather the fragments of a fragmented datagram before deciding
whether to let them pass through. IPv6 middleboxes shouldn't
have to do that, but they will if the host is permitted to
include MTU-sized header chains and there is a tunnel on the
path that has to fragment for whatever reason.

> And it is very likely

That is not necessarily true. Tunnels are used for many reasons
other than IPv6/IPv4 transition, including routing control,
mobility, traffic engineering, multihoming, security etc.
Tunnels will be part of the IPv6 architecture long after IPv4
has faded into the sunset, so let's get this right now so we
don't have to live with legacy behavior.

Thanks - Fred