RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi Brian, -Original Message- From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] Sent: Friday, October 11, 2013 3:42 PM To: Templin, Fred L Cc: Fernando Gont; Ray Hunter; 6man Mailing List; ietf@ietf.org Subject: Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard Fred, On 12/10/2013 08:56, Templin, Fred L wrote: Hi Brian, -Original Message- From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] Sent: Friday, October 11, 2013 12:50 PM To: Fernando Gont Cc: Templin, Fred L; Ray Hunter; 6man Mailing List; ietf@ietf.org Subject: Re: Last Call: draft-ietf-6man-oversized-header-chain- 08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard On 12/10/2013 06:04, Fernando Gont wrote: ... 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. 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. 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. 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. 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 fred.l.temp...@boeing.com Brian
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi Ron, -Original Message- From: Ronald Bonica [mailto:rbon...@juniper.net] Sent: Saturday, October 12, 2013 7:07 PM To: Brian E Carpenter; Templin, Fred L Cc: Fernando Gont; 6man Mailing List; ietf@ietf.org; Ray Hunter Subject: RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard +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. 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 fred.l.temp...@boeing.com 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 is ready. This draft mitigates a known problem in terms of the current IPv6 standards.
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi Ron, At 16:55 13-10-2013, Ronald Bonica wrote: Are you suggesting that we don't address the problem because the 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
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Not that I am aware of. -Original Message- From: SM [mailto:s...@resistor.net] Sent: Monday, October 14, 2013 11:20 AM To: Ronald Bonica Cc: ietf@ietf.org Subject: RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard Hi Ron, At 16:55 13-10-2013, Ronald Bonica wrote: Are you suggesting that we don't address the problem because the 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
Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Fred, On 15/10/2013 06:38, Templin, Fred L wrote: ... 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. If it messes up tunnels, then it's not ready. That doesn't follow. See below. 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. 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
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi Brian, -Original Message- From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] Sent: Monday, October 14, 2013 12:34 PM To: Templin, Fred L Cc: Fernando Gont; Ray Hunter; 6man Mailing List; ietf@ietf.org Subject: Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard Fred, On 15/10/2013 06:38, Templin, Fred L wrote: ... 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. If it messes up tunnels, then it's not ready. That doesn't follow. See below. 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. 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. 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 fred.l.temp...@boeing.com No, I don't think it's worth considering that case before specifying this mitigation. Brian
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
SM, Are you suggesting that we don't address the problem because the code is too complex to touch? Ron -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of SM Sent: Sunday, October 13, 2013 1:00 AM To: ietf@ietf.org Subject: Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard At 11:55 02-10-2013, The IESG wrote: 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 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
Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Templin, Fred L mailto:fred.l.temp...@boeing.com 11 October 2013 17:33 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. Which AFAIK is undefined in practical terms. Especially in the presence of jumbo payload extension headers or fragments. So are you saying the current draft has no value? 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. 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)? 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). The goal is to give the middlebox enough information so that it can parse as deeply into the headers as it wants to. 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. 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
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
+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 is ready. This draft mitigates a known problem in terms of the current IPv6 standards.
Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
At 11:55 02-10-2013, The IESG wrote: 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 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
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...) Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
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? 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. 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. 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
RE: RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
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
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi Fernando, -Original Message- From: Fernando Gont [mailto:fg...@si6networks.com] Sent: Friday, October 11, 2013 1:36 AM To: Ray Hunter; Templin, Fred L; brian.e.carpen...@gmail.com Cc: 6man Mailing List; ietf@ietf.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.l.temp...@boeing.com Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
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. 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, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi Ray, -Original Message- From: Ray Hunter [mailto:v6...@globis.net] Sent: Friday, October 11, 2013 9:59 AM To: Templin, Fred L Cc: brian.e.carpen...@gmail.com; ietf@ietf.org; 6man Mailing List Subject: Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard Templin, Fred L mailto:fred.l.temp...@boeing.com 11 October 2013 17:33 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. 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 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. 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
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi Fernando, -Original Message- From: Fernando Gont [mailto:fg...@si6networks.com] Sent: Friday, October 11, 2013 10:04 AM To: Templin, Fred L; Ray Hunter; brian.e.carpen...@gmail.com Cc: 6man Mailing List; ietf@ietf.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.l.temp...@boeing.com Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
On 12/10/2013 06:04, Fernando Gont wrote: ... 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. 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
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi Brian, -Original Message- From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] Sent: Friday, October 11, 2013 12:50 PM To: Fernando Gont Cc: Templin, Fred L; Ray Hunter; 6man Mailing List; ietf@ietf.org Subject: Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard On 12/10/2013 06:04, Fernando Gont wrote: ... 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. 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. 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 fred.l.temp...@boeing.com
Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Fred, On 12/10/2013 08:56, Templin, Fred L wrote: Hi Brian, -Original Message- From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] Sent: Friday, October 11, 2013 12:50 PM To: Fernando Gont Cc: Templin, Fred L; Ray Hunter; 6man Mailing List; ietf@ietf.org Subject: Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard On 12/10/2013 06:04, Fernando Gont wrote: ... 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. 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. 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. 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
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
-Original Message- From: Ronald Bonica [mailto:rbon...@juniper.net] Sent: Tuesday, October 08, 2013 5:46 PM To: Ole Troan; Templin, Fred L Cc: i...@ietf.org; ietf@ietf.org Subject: RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard I agree with Ole. 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 fred.l.temp...@boeing.com Ron -Original Message- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Ole Troan Sent: Tuesday, October 08, 2013 12:17 PM To: Templin, Fred L Cc: i...@ietf.org; ietf@ietf.org; IETF-Announce Subject: Re: Last Call: draft-ietf-6man-oversized-header-chain- 08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard Fred, Hi, I would like to make a small amendment to what I said in my previous message as follows: 4) Section 5, change the final paragraph to: 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. I would claim that additional encapsulation headers are already considered in the 1280 minimum MTU. as in: 1500 - 1280. cheers, Ole
Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Fred, -Original Message- From: Ronald Bonica [mailto:rbon...@juniper.net] Sent: Tuesday, October 08, 2013 5:46 PM To: Ole Troan; Templin, Fred L Cc: i...@ietf.org; ietf@ietf.org Subject: RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard I agree with Ole. 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. 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 signature.asc Description: Message signed with OpenPGP using GPGMail
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi Ole, -Original Message- From: Ole Troan [mailto:otr...@employees.org] Sent: Wednesday, October 09, 2013 9:54 AM To: Templin, Fred L Cc: Ronald Bonica; i...@ietf.org; ietf@ietf.org Subject: Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard Fred, -Original Message- From: Ronald Bonica [mailto:rbon...@juniper.net] Sent: Tuesday, October 08, 2013 5:46 PM To: Ole Troan; Templin, Fred L Cc: i...@ietf.org; ietf@ietf.org Subject: RE: Last Call: draft-ietf-6man-oversized-header-chain- 08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard I agree with Ole. 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. 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. 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 fred.l.temp...@boeing.com cheers, Ole
Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Fred, -Original Message- From: Ronald Bonica [mailto:rbon...@juniper.net] Sent: Tuesday, October 08, 2013 5:46 PM To: Ole Troan; Templin, Fred L Cc: i...@ietf.org; ietf@ietf.org Subject: RE: Last Call: draft-ietf-6man-oversized-header-chain- 08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard I agree with Ole. 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. 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. 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. 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 signature.asc Description: Message signed with OpenPGP using GPGMail
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi Ole, -Original Message- From: Ole Troan [mailto:otr...@employees.org] Sent: Wednesday, October 09, 2013 10:31 AM To: Templin, Fred L Cc: Ronald Bonica; i...@ietf.org; ietf@ietf.org Subject: Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard Fred, -Original Message- From: Ronald Bonica [mailto:rbon...@juniper.net] Sent: Tuesday, October 08, 2013 5:46 PM To: Ole Troan; Templin, Fred L Cc: i...@ietf.org; ietf@ietf.org Subject: RE: Last Call: draft-ietf-6man-oversized-header-chain- 08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard I agree with Ole. 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. 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. 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. 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. :-) 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 fred.l.temp...@boeing.com cheers, Ole
Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Fred, See below... On 10/10/2013 06:42, Templin, Fred L wrote: Hi Ole, -Original Message- From: Ole Troan [mailto:otr...@employees.org] Sent: Wednesday, October 09, 2013 10:31 AM To: Templin, Fred L Cc: Ronald Bonica; i...@ietf.org; ietf@ietf.org Subject: Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard Fred, -Original Message- From: Ronald Bonica [mailto:rbon...@juniper.net] Sent: Tuesday, October 08, 2013 5:46 PM To: Ole Troan; Templin, Fred L Cc: i...@ietf.org; ietf@ietf.org Subject: RE: Last Call: draft-ietf-6man-oversized-header-chain- 08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard I agree with Ole. 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. 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. 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. 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. :-) 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. 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
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
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 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. 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. 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 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
Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Fred, Hi, I would like to make a small amendment to what I said in my previous message as follows: 4) Section 5, change the final paragraph to: 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. I would claim that additional encapsulation headers are already considered in the 1280 minimum MTU. as in: 1500 - 1280. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi Ole, -Original Message- From: Ole Troan [mailto:otr...@employees.org] Sent: Tuesday, October 08, 2013 9:17 AM To: Templin, Fred L Cc: ietf@ietf.org; IETF-Announce; i...@ietf.org Subject: Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard Fred, Hi, I would like to make a small amendment to what I said in my previous message as follows: 4) Section 5, change the final paragraph to: 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. I would claim that additional encapsulation headers are already considered in the 1280 minimum MTU. as in: 1500 - 1280. 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 fred.l.temp...@boeing.com cheers, Ole
Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
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: I would claim that additional encapsulation headers are already considered in the 1280 minimum MTU. as in: 1500 - 1280. 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, 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. 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? Yes. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
I agree with Ole. Ron -Original Message- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Ole Troan Sent: Tuesday, October 08, 2013 12:17 PM To: Templin, Fred L Cc: i...@ietf.org; ietf@ietf.org; IETF-Announce Subject: Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard Fred, Hi, I would like to make a small amendment to what I said in my previous message as follows: 4) Section 5, change the final paragraph to: 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. I would claim that additional encapsulation headers are already considered in the 1280 minimum MTU. as in: 1500 - 1280. cheers, Ole
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi, I would like to make a small amendment to what I said in my previous message as follows: 4) Section 5, change the final paragraph to: 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 fred.l.temp...@boeing.com -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Templin, Fred L Sent: Friday, October 04, 2013 1:42 PM To: ietf@ietf.org; IETF-Announce Cc: i...@ietf.org Subject: RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard 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 fred.l.temp...@boeing.com -Original Message- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of The IESG Sent: Wednesday, October 02, 2013 11:55 AM To: IETF-Announce Cc: i...@ietf.org 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 ietf@ietf.org mailing lists by 2013-10-16. Exceptionally, comments may be sent to i...@ietf.org 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
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
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 fred.l.temp...@boeing.com -Original Message- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of The IESG Sent: Wednesday, October 02, 2013 11:55 AM To: IETF-Announce Cc: i...@ietf.org 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 ietf@ietf.org mailing lists by 2013-10-16. Exceptionally, comments may be sent to i...@ietf.org 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 i...@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
