ietf
[Top] [All Lists]

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

2013-10-11 10:36:46
Hi Fernando,

-----Original Message-----
From: Fernando Gont [mailto:fgont(_at_)si6networks(_dot_)com]
Sent: Friday, October 11, 2013 1:36 AM
To: Ray Hunter; Templin, Fred L; 
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 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...)

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
fred(_dot_)l(_dot_)templin(_at_)boeing(_dot_)com

Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fgont(_at_)si6networks(_dot_)com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





<Prev in Thread] Current Thread [Next in Thread>