Hi Fernando,
-----Original Message-----
From: Fernando Gont [mailto:fgont(_at_)si6networks(_dot_)com]
Sent: Friday, October 11, 2013 10:04 AM
To: Templin, Fred L; Ray Hunter;
brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com
Cc: 6man Mailing List; ietf(_at_)ietf(_dot_)org
Subject: Re: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt>
(Implications of Oversized IPv6 Header Chains) to Proposed Standard
On 10/11/2013 12:36 PM, Templin, Fred L wrote:
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...)
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.
The problem is that if you have multiple encapsulations, you can always
hit the MTU limit and fail to comply with this requirement.
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.
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.
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
fred(_dot_)l(_dot_)templin(_at_)boeing(_dot_)com
Thanks!
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fgont(_at_)si6networks(_dot_)com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492