Hi Ray, > -----Original Message----- > From: Ray Hunter [mailto:v6...@globis.net] > Sent: Friday, October 11, 2013 12:49 AM > To: Templin, Fred L; brian.e.carpen...@gmail.com > Cc: ietf@ietf.org; 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, > > > > Responding in a slightly re-arranged order: > > > >> 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. > > 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. > > > > > >> 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). > > 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. > > Because it leaves open the possibility for an attacker to apply the > obfuscation we seek to limit. > > > > 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. > > > There's also a myriad of tunneling technology out there. > > Again, what is an ULP? Where do you stop parsing?
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. > 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. 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. > 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. 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. > 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. > > 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". > > > > > >> 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". > > Agreed. 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 fred.l.temp...@boeing.com > > 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 > > fred.l.temp...@boeing.com > > > >> Brian > > > > > -- > Regards, > RayH
