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: 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: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Gert Doering wrote: Hi, On Wed, Sep 04, 2013 at 06:25:17PM +0900, Lorenzo Colitti wrote: Sure, but the majority are mandatory, and don't forget that some of them are quite large (e.g., implement RFC 6204). Also, I believe it's not the IETF's role to produce vendor requirements documents. The considerations that the IETF deals with are primarily technical, and we want this stuff from our vendors is not a technical issue. *[Med] With all due respect, you are keeping the same argument since the initial call for adoption and you seem ignore we are not in that stage. That?s not fair at all.* I'm just saying it here so that everyone in the community can see it. If it's an IETF document it has to have IETF consensus, and since I feel that the arguments were not properly taken into account in the WG (read: ignored), I think it's important that the community see them before we publish this document. +1 Gert Doering -- NetMaster I know I'm formally a couple of days late on the WGLC (work!). I agree with Lorenzo. And in any case it isn't ready to ship IMHO. e.g. How can REQ#33 and REQ#34 be enforced by a manufacturer (during compliance testing)? -- Regards, RayH
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic From: Keith Moore mo...@network-heretics.com Date: Sat, 2 Jul 2011 23:10:47 -0400 To: Cameron Byrne cb.li...@gmail.com CC: v6...@ietf.org v6...@ietf.org, IETF Discussion ietf@ietf.org Precedence: list MIME-Version: 1.0 (Apple Message framework v1084) References: 13205c286662de4387d9af3ac30ef456d3f3507...@embx01-wf.jnpr.net CAKD1Yr2Smvm0RY5iV2y06wD=rrz-uw4vbaaairnoaksr7zl...@mail.gmail.com banlktimprdnqkc1xtafskkoo5dcx3gc...@mail.gmail.com In-Reply-To: banlktimprdnqkc1xtafskkoo5dcx3gc...@mail.gmail.com Message-ID: e817a524-9db7-4553-a76f-25a9907e7...@network-heretics.com Content-Type: multipart/alternative; boundary=Apple-Mail-111-642965515 Message: 2 I find myself wondering what you mean by REAL IPv6. For me, REAL IPv6 is code that uses the IPv6 programming model, 128 bit addresses, end-to-end transparency, no NATs. 6to4 certainly qualifies. Keith Many people have many more requirements. For example, an SLA for availability and latency, low support costs, firewall security, DSCP quality of service, ability to log end point communications, intrusion detection, WAN acceleration, a deployment model that does not rely on allocating even more IPv4 addresses (that many don't have or won't have) or the good nature of other providers to provide a working relay ... 6to4 fails to meet many of those requirements. Granted, it isn't the only transition mechanism that fails to do so. IMHO Right now, we need services with native IPv6 based interfaces, with equivalent performance and equivalent features and equivalent price that we have today with IPv4. Anything that detracts from the roll out of native IPv6 based service interfaces at this time is a bad move IMVHO and hastens the day that the Internet fragments into a bunch of CGN zones, that is dominated by businesses that can afford to buy public IPv4 addresses for their servers or services, or whose business model relies on NAT traversal being difficult. I personally don't want that sort of Internet. Given that development and engineering support time is finite, I'd much rather that 6to4 was declared historic so that developers and engineers could spend more time on deployment of native IPv6 service interfaces. Having said all that, 6to4 has also caused me issues with traffic predictability, and cost significant engineering time. Turning 6to4 off by default would not be the ideal solution in my view, but it should address many if not all of my own particular issues. If that's all that's on offer, I'll take it. regards, RayH ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Keith Moore wrote: On Jul 3, 2011, at 2:23 AM, Ray Hunter wrote: IMHO Right now, we need services with native IPv6 based interfaces, with equivalent performance and equivalent features and equivalent price that we have today with IPv4. Anything that detracts from the roll out of native IPv6 based service interfaces at this time is a bad move IMVHO and hastens the day that the Internet fragments into a bunch of CGN zones, that is dominated by businesses that can afford to buy public IPv4 addresses for their servers or services, or whose business model relies on NAT traversal being difficult. I personally don't want that sort of Internet. Right now, applications developers need to be able to write and ship code that uses IPv6 and can talk to other application instances using IPv6. Anything that detracts from the ability of applications to use IPv6 at this time is a bad move IMHO and decreases the chance that there will ever be sufficient use of IPv6 (of any kind) to justify widespread deployment of native IPv6. Given that development and engineering support time is finite, I'd much rather that 6to4 was declared historic so that developers and engineers could spend more time on deployment of native IPv6 service interfaces. I have a better suggestion: let's declare NAT historic. That would free up lots of developers and engineers to spend time on both native v6 and better v6 transition mechanisms. Not only would they not need to engineer new NATs, applications developers wouldn't need to engineer new workarounds for new NATs. Everybody would win. Keith I'm presuming your second comment was facetious. I'm also presuming from your first comment that you will thus oppose the proposal to turn off 6to4 by default. Am I correct? regards RayH, ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
