Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
On 8-mei-2007, at 21:00, Tim Enos wrote: I would also prefer that RH0 be silently dropped but could live with an ICMPv6 error message being sent back to the sending host Why is everyone so in love with silently dropping? This only makes troubleshooting harder. See RFC 2460 and imagine that type 0 is not recognized: If, while processing a received packet, a node encounters a Routing header with an unrecognized Routing Type value, the required behavior of the node depends on the value of the Segments Left field, as follows: If Segments Left is zero, the node must ignore the Routing header and proceed to process the next header in the packet, whose type is identified by the Next Header field in the Routing header. If Segments Left is non-zero, the node must discard the packet and send an ICMP Parameter Problem, Code 0, message to the packet's Source Address, pointing to the unrecognized Routing Type. Additionally, it would be helpful if we could separate the issues on the table. There are many of them, and not all solutions apply to all of them: - source routing can be used for amplification - IPv6 source routing is enabled by default on most implementations - IPv6 source routing can't be disabled on some implementations - BSD will _forward_ IPv6 source routed packets even when IPv6 forwarding is disabled - apparently, there is no check whether the same addresses appear multiple time in many implementations IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
Hi Bob/all, I advocate for option #1. IMO, the paper found by following the link below makes a good case against the use of IPv6 Routing Header Type 0: http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf. The following I-D (perhaps among others) also succinctly delineates the potential security problems with its use: draft-savola-ipv6-rh-ha-security-03.txt. Whether it's the potential to reach a hidden host via a visible one, the ability to use reflection to launch a DoS attack, or other security issues as noted both on this list and the above referenced papers (and others), deprecation of Routing Header Type 0 (aka option #1) is best. The implicit curriculum of #2 and #3 really seems to be that RH0 processing can be enabled. Also, to me it seems that #4 just gives us slightly less of a bad thing. Even workarounds such as ingress filtering with properly configured ACLs could also technically be used by an attacker. I would also prefer that RH0 be silently dropped but could live with an ICMPv6 error message being sent back to the sending host (error messages are rate-limited). Not processing but forwarding RH0 does not seem to make sense. Best Regards, Timothy Enos Rom 8:28 From: Bob Hinden [EMAIL PROTECTED] Date: 2007/04/25 Wed PM 07:39:40 CDT To: IETF IPv6 Mailing List ipv6@ietf.org Subject: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues] [trimming this to just the IPv6 w.g.] We think the question for the IPv6 working group on this topic is does the working group want to do anything to address the issues raised about the Type 0 routing header. Possible actions include: 1) Deprecate all usage of RH0 2) Recommend that RH0 support be off by default in hosts and routers 3) Recommend that RH0 support be off by default in hosts 4) Limit it's usage to one RH0 per IPv6 packet and limit the number of addresses in one RH0. These examples are not all mutually exclusive. Please respond to the list with your preference and justifications. Thanks, Bob Hinden / Brian Haberman IPv6 W.G. Chairs p.s. We will send a note to the other lists that the IPv6 w.g. will be discussing this issue. IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Type 0 Routing Header issues
On Mon, Apr 30, 2007 at 05:43:04PM -0700, james woodyatt wrote: I further recommend the draft standards be amended to require that RH0 be rejected with an ICMP error when received at the first destination and dropped silently in all other cases. This will allow operators to identify and neutralize preemptively exactly those nodes which do not comply with the amended standard. I was wondering if this is actually useful. I would expect that operators would want to find hosts that blindly process RH0 headers, not machines that send them or machines that don't process them. Sending an ICMP message would seem only to flag up machines that send RH0 or machines that don't process RH0, which doesn't seem so useful. If an operator wanted to scan for machines that process RH0 headers, then patched machines sending ICMP messages might nearly be a hinderance. David. IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: itojun2.0 (RE: IPv6 Type 0 Routing Header issues)
now, in KAME we meant to make t-shirt code then spec, not spec then code' Now T-shirt is available at http://www.kame.net/. see http://www.natisbad.org/ for the summary of the problem as well as list of link to the press coverages. i'm adding more items to the design database. if you need more variety (such as teddy bear or mug cup) just drop me a note. it's 9AM JST so US people can just ring me on Skype or cellphone (just finger me). itojun IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Type 0 Routing Header issues
Le 1 mai 07 à 23:18, George V. Neville-Neil a écrit : Actually I like this solution. Now, not to beat a dead horse more, but when can a draft be set up to talk about this? I would already have pushed a submission but I'm not familiar with the associated IETF process. I suspect it will take me quite some time to do it the wrong way. Can someone more familiar with it initiate the submission? I'll be happy to take part to the discussions and reviewing process. Cheers, a+ -- Arnaud Ebalard EADS Innovation Works - IT Sec Research Engineer PGP KeyID:047A5026 FingerPrint:47EB85FEB99AAB85FD0946F30255957C047A5026 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Type 0 Routing Header issues
At Thu, 3 May 2007 13:41:12 +0200, Ebalard, Arnaud wrote: Le 1 mai 07 à 23:18, George V. Neville-Neil a écrit : Actually I like this solution. Now, not to beat a dead horse more, but when can a draft be set up to talk about this? I would already have pushed a submission but I'm not familiar with the associated IETF process. I suspect it will take me quite some time to do it the wrong way. Can someone more familiar with it initiate the submission? I'll be happy to take part to the discussions and reviewing process. I too can be involved in the draft, but also have never written one on my own. Best, George IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Type 0 Routing Header issues
On May 3, 2007, at 5:41 PM, [EMAIL PROTECTED] wrote: At Thu, 3 May 2007 13:41:12 +0200, Ebalard, Arnaud wrote: Le 1 mai 07 à 23:18, George V. Neville-Neil a écrit : Actually I like this solution. Now, not to beat a dead horse more, but when can a draft be set up to talk about this? I would already have pushed a submission but I'm not familiar with the associated IETF process. I suspect it will take me quite some time to do it the wrong way. Can someone more familiar with it initiate the submission? I'll be happy to take part to the discussions and reviewing process. I too can be involved in the draft, but also have never written one on my own. hello gentleman, found some answers about creating and submitting RFCs here: http://www.rfc-editor.org/rfcfaq.html some tips here ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt peace marc Best, George -- Development is when you know the answer, but not how to get there. Applied research is when you know the question, but not the answer. Pure research is when you don't know the question. web: http://www.let.de .local http://stattfernsehen.com IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
Eric Klein wrote: [..] I am sorry if I was unclear. I am on both lists and understand their diffrences. No, you are confusing [EMAIL PROTECTED] with [EMAIL PROTECTED] They are not the same. The first has nothing to do with the IETF and can't care much about what the IETF will decide, they will most likely look at it and take it into consideration, but that is it. Please actually READ what I write. My concern is that both lists are reviewing this problem and looking for a solution independently of each other. So I am wondering which group is more appropriate for a soltuion, thus the topic would fall under: 1. IPv6 WG 2. v6OPS WG As this definitely concerns the IPv6 Protocol, as the RT0 is part of the protocol and that is broken it belongs in ipv6@ietf.org (IPv6 WG) and not in v6ops which is also not where this discussion is taking place. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
On 5/3/07, Jeroen Massar [EMAIL PROTECTED] wrote: I am sorry if I was unclear. I am on both lists and understand their diffrences. No, you are confusing [EMAIL PROTECTED] with [EMAIL PROTECTED] They are not the same. The first has nothing to do with the IETF and can't care much about what the IETF will decide, they will most likely look at it and take it into consideration, but that is it. Actually I am refering to IETF V6OPS WG [EMAIL PROTECTED]http://mail.softhome.net/email/login/EricLKlein%40SoftHome.net.authcustom/0BC8674E7137F0F2DDE11B156B482B25/1178221322?folder=NAPform=quickaddpos=17newname=IETF+V6OPS+WGnewaddr=v6ops%40ops.ietf.org not the one on cluenet, as this is where the discussion is occuring. Please actually READ what I write. My concern is that both lists are reviewing this problem and looking for a solution independently of each other. So I am wondering which group is more appropriate for a soltuion, thus the topic would fall under: 1. IPv6 WG 2. v6OPS WG As this definitely concerns the IPv6 Protocol, as the RT0 is part of the protocol and that is broken it belongs in ipv6@ietf.org (IPv6 WG) and not in v6ops which is also not where this discussion is taking place. I agree in where this should be taking place, but disagree that it is only taking place here. Please see the thread starting with message: http://ops.ietf.org/lists/v6ops/v6ops.2007/msg00302.html Fore the discussion in the OPS WG Eric IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
Theo, Congratulations. You've joined the other 20 or so people whose mail my machine will delete unread from now on. Brian IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
On Tue, 1 May 2007, Brian E Carpenter wrote: Theo, Congratulations. You've joined the other 20 or so people whose mail my machine will delete unread from now on. what about keeping those sort of personal stuff out of this (and other) and other mailinglist? I care zip about you or him, I'm here on this list to follow a discussion about something a bit more important. -- -- Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID [EMAIL PROTECTED] | - IPv6 is The Key! --- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
Eric Klein wrote: I have just noticed that this topic seems to be going on simutaniously on both the IPv6 and v6OPS mailing lists. The two threads are not coordinated, but both seem very concerned with IPv6 Type 0 Routing Header issues. [..] It concerns me that the two teams are working seperatly to solve the same issue. You misunderstand. These are two separate groups, although some members of them fall under both groups and participate in both. Which is a good thing as without one the other doesn't exist and vice versa, thus feed back from both into both is very important. Unfortunately not everybody can participate in both as some people have networks to run etc ;) To make it a bit clearer: The [EMAIL PROTECTED] list is for IPv6 Operational matters. This list contains folks who have actual have enable or root on the network routers around the globe and who can take immediate effect on their workings. As such these people have fortunately, where possible, already taken action to resolve this issue by filtering out Routing Header Type 0 from propagating through their networks. Most of them are awaiting a fix from Juniper though, to resolve it for those routers which actually comprise the largest amount of the IPv6 backbones. These people operating them do this for the benefit of their own organization and thus take their decisions based on the simple metric: does it impact revenue or my operating of the network. As it does pose a danger it is a simple equation to resolve it. The general consensus in this community seems to be to filter out IPv6 Routing Headers of Type 0 completely. The only argument raised by some is that it is useful for 'reverse traceroute', but as that doesn't work when a network properly does uRPF (which it should be doing!) this is far from useless in most cases anyway. uRPF in general makes RH0 completely useless anyway. Having uRPF enabled in most cases mitigates this attack already perfectly fine. Unless of course folks have defaults pointing both ways or the RH0 path is following the correct interface direction. Hard but possibly doable. The ipv6@ietf.org list is for the standardization of the IPv6 protocol. Here is specified how those routers should behave, what the packet data should/must look like etc. There are a lot of different people from a lot of different backgrounds all with different interests in this group, as such, as they don't all have the same goal, not all can be satisfied in one go, unlike the operators who run their network for profit, and consensus have to be reached first amongst all the parties for this to be resolved. Although this group defines the initial RFC, the Operators, next to the Vendors, actually implement them. The standard in the end thus is actually what both groups together come up with. As IPv6 is not a standard yet, we'll just have to write a draft to amend the current IPv6 RFC to resolve this issue. All that said though, as the Operative community is already mostly filtering out RH0, there seems to be little options left where RH0 still is useful... Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
theo, i feel your pain. but at the heart of your issues there's a logic error or perhaps two, and it's turning your input here into a distractive sideshow. the first error i saw was when you wanted to prevent certain people from having input into ietf decision making based on engineering errors they'd made in the past. i've made plenty of engineering errors in the past, some of which are enshrined in rfc's, yet i know i learned from those errors and am a better engineer for the learning. it's unwise to assume that someone who has erred is thus never again going to be useful, and also impractical to assume that noone else will listen to that person when forming consensus around new issues as they come up, no matter what errors they've made. the second and more important error is to assume that ietf is relevant. if you look carefully you'll see that the SSH protocol has been shaped far more by your OpenSSH effort than by the ietf or any commercial vendors, and SMTP likewise more by Sendmail and Postfix than by ietf or any commercial vendors, and DNS likewise more by BIND than by ietf or any commercial vendors. in the old days, ietf consensus could make or wreck an idea. these are not those days. compared to the power and relevance of open source software, ietf may as well be declared dead for all the relevance it has at this stage. again, i feel your pain. i'm still shaking my head over the lost opportunity that was A6/DNAME, and i've watched with horrified fascination as DNSSEC has taken over a dozen years to become the undeployable laboratory toy it is. i meant every word of http://fm.vix.com/internet/governance/bonjour-fwd.html and i understand perfectly well where your rage is coming from. but you've gotta stop harping on it and looking for folks to blame personally, it's not helping and it's not going to help and it's hurtful and going to hurt more. IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
On 5/1/07, Jeroen Massar [EMAIL PROTECTED] wrote: Eric Klein wrote: I have just noticed that this topic seems to be going on simutaniously on both the IPv6 and v6OPS mailing lists. The two threads are not coordinated, but both seem very concerned with IPv6 Type 0 Routing Header issues. [..] It concerns me that the two teams are working seperatly to solve the same issue. You misunderstand. These are two separate groups, although some members of them fall under both groups and participate in both. Which is a good thing as without one the other doesn't exist and vice versa, thus feed back from both into both is very important. Unfortunately not everybody can participate in both as some people have networks to run etc ;) Jeroen, I am sorry if I was unclear. I am on both lists and understand their diffrences. My concern is that both lists are reviewing this problem and looking for a solution independently of each other. So I am wondering which group is more appropriate for a soltuion, thus the topic would fall under: 1. IPv6 WG 2. v6OPS WG 3. Some sort of joint discussions 4. Inter-Area WG I do not see how the multiple lists will coordinate their solutions if there is confusion over the ownership of the issue. Eric IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Type 0 Routing Header issues
At Mon, 30 Apr 2007 17:43:04 -0700, james woodyatt wrote: On Apr 27, 2007, at 05:38, Ebalard, Arnaud wrote: Bob Hinden [EMAIL PROTECTED] wrote: Possible actions include: 1) Deprecate all usage of RH0 2) Recommend that RH0 support be off by default in hosts and routers 3) Recommend that RH0 support be off by default in hosts 4) Limit it's usage to one RH0 per IPv6 packet and limit the number of addresses in one RH0. These examples are not all mutually exclusive. From my perspective, RH0 should be deprecated to simplify IPv6 specification, stacks' implementations and suppress associated threats. Keeping the generic RH mechanism will be sufficient for new protocols to __carefully__ provide associated functionalities (if any), just like the designers of Mobile IPv6 did with RH2 (IMHO, processing limited to MIPv6 implementations, no external forwarding, one address max, ...). I agree that all transmissions of RH0 should be deprecated, and I further recommend the draft standards be amended to require that RH0 be rejected with an ICMP error when received at the first destination and dropped silently in all other cases. This will allow operators to identify and neutralize preemptively exactly those nodes which do not comply with the amended standard. Actually I like this solution. Now, not to beat a dead horse more, but when can a draft be set up to talk about this? I'd like to at least know that the code I'm implementing will be somewhat close to the final outcome of this discussion. Thanks, George IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
Theo, Your language is unfitting for professional discussion, in my opinion. The issue having been raised, we should deal with it as an engineering matter. Brian IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
I have just noticed that this topic seems to be going on simutaniously on both the IPv6 and v6OPS mailing lists. The two threads are not coordinated, but both seem very concerned with IPv6 Type 0 Routing Header issues. This is seperate to the rash of Linux related warnings that have come out in the new IPv6 news - weekly summary : *Security: *Linux Kernel IPv6 Protocol Type 0 Route Header Remote Denial of Service Vulnerability http://www.ipv6tf.org/news/counter.php?id=2837http://mail.softhome.net/email?timestamp=1177957366md5=pRuj%2BiFkKKYGt0gdD1Wxmg%3D%3Dredirect=http%3A%2F%2Fwww.ipv6tf.org%2Fnews%2Fcounter.php%3Fid%3D2837 FreeBSD Security Advisory - IPv6 Routing Header 0 is dangerous http://www.ipv6tf.org/news/counter.php?id=2834http://mail.softhome.net/email?timestamp=1177957366md5=pRuj%2BiFkKKYGt0gdD1Wxmg%3D%3Dredirect=http%3A%2F%2Fwww.ipv6tf.org%2Fnews%2Fcounter.php%3Fid%3D2834 OpenBSD IPv6 Type 0 Route Headers Denial of Service http://www.ipv6tf.org/news/counter.php?id=2819 It concerns me that the two teams are working seperatly to solve the same issue. Eric IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Type 0 Routing Header issues
On Apr 27, 2007, at 05:38, Ebalard, Arnaud wrote: Bob Hinden [EMAIL PROTECTED] wrote: Possible actions include: 1) Deprecate all usage of RH0 2) Recommend that RH0 support be off by default in hosts and routers 3) Recommend that RH0 support be off by default in hosts 4) Limit it's usage to one RH0 per IPv6 packet and limit the number of addresses in one RH0. These examples are not all mutually exclusive. From my perspective, RH0 should be deprecated to simplify IPv6 specification, stacks' implementations and suppress associated threats. Keeping the generic RH mechanism will be sufficient for new protocols to __carefully__ provide associated functionalities (if any), just like the designers of Mobile IPv6 did with RH2 (IMHO, processing limited to MIPv6 implementations, no external forwarding, one address max, ...). I agree that all transmissions of RH0 should be deprecated, and I further recommend the draft standards be amended to require that RH0 be rejected with an ICMP error when received at the first destination and dropped silently in all other cases. This will allow operators to identify and neutralize preemptively exactly those nodes which do not comply with the amended standard. -- j h woodyatt [EMAIL PROTECTED] IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
I think we can safely put to bed the idea that the designers were dolts who didn't learn from history. That doesn't mean there weren't dolts involved in the process.:-) Bob, actually, why should we put anything to bed? Are you statements not some put it to bed, shove it under the carpet game? Really -- why not just call them stupid dolts? Why not hold them accountable? Is accountability suddenly un-American and un-IETF? The only people who I see discounting accountability (on various lists) are the ones who either don't understand the scope and impact of the problem, or are to escape the impact of the disaster that IETF has thrown at the IPV4 operators who now suddenly face this problem of IPV6-over-tunnels on the networks they operate. Talk to some operators. It's no longer DoS. You take your DoS, you IPV6 it, and voila -- it's DoS x 100, at least. You wait and see. So, why do we need to wipe the slate clean? Why not should we not identify the academics involved in IETF who are unaware of the pushback against source routing that happened in 1992-1995? If people are unaware if how IPV4 source routing was pushed back against, should they be at all involved in an any future IETF process that rubber stamps their kind of bullshit in a New generation protocol? If you don't blame the people who pushed for this crap, who will you blame? Noone? Or is the wiping clean of the slate just another retarded IETF process that will let this stupid mistake be made again, by an IETF that thinks that the academic inclusion, uber ales, minus actual code in use principle they believe in helps they build things better than crap? If I have come to one viewpoint in life it is this: IF NOONE LEARNS, NOONE LEARNS. And here I see Bob Hindin (and perhaps some others) making apologies for his buddies who he personally gave the scope to screw things up this badly. Bob, you were there. You are one of the dolts. If IETF has no accountability at present time, now is the time for accountability. You guys were given a *responsibility* to try to do right, hell -- the industry and goverments gave you a MANDATE. Instead you fucked the dog, and my lord, you fucked the dog to death, and potentially the cat and the canary too. Bob, I don't know who totally fucked this up; not exactly. But either the leaders of the process did, or... noone did. And I think we need to know who did fuck it up, so that they never let their stupid ideas of process enter into the Internet game again, or the researchers they listened to (who totally ignore an IETF directive of security concerns must be addressed.) If you were unaware of the vendor and operator push-back against IPV4 source routing, and let this go through, then you are #1 retard of the century. If you did not, but simply managed researchers who sold you a bum ride -- you need to say who they were or you are an even bigger retard. Yes, I am mean. But Bob, I have dealt with you before and you should have gotten out of technology a long time ago. IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
Theo, On Apr 27, 2007, at 10:42 PM, ext Theo de Raadt wrote: I think we can safely put to bed the idea that the designers were dolts who didn't learn from history. That doesn't mean there weren't dolts involved in the process.:-) Bob, actually, why should we put anything to bed? Are you statements not some put it to bed, shove it under the carpet game? Before you launch a personal attack on me on the list you at least attack the words I actually wrote on the topic. I have not suggested putting anything to bed. This is clearly a problem we should fix. Bob IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Type 0 Routing Header issues
On Fri 27 Apr '07 at 02:06 George V. Neville-Neil [EMAIL PROTECTED] wrote: Hi, I would be interested in a list of cases FOR the Type 0 Routing Header. If there are no good cases for it, it seems to me that removing it is the best thing to do. I quite like traceroute for the return path. Which would also explain why Hosts are meant to process the routing header. A. -- Alun Evans IOS Software Engineer, cisco Systems. http://www.cisco.com/go/ipv6/ IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Type 0 Routing Header issues
Alun Evans wrote: On Fri 27 Apr '07 at 02:06 George V. Neville-Neil [EMAIL PROTECTED] wrote: Hi, I would be interested in a list of cases FOR the Type 0 Routing Header. If there are no good cases for it, it seems to me that removing it is the best thing to do. I quite like traceroute for the return path. This 'problem' can be solved with looking glass websites, not which such an obvious security problem as RH0. That said, there should be a well defined system for Looking Glasses. Please see the proposal I made to the RIPE Database WG to define these: http://www.ripe.net/ripe/maillists/archives/db-wg/2007/msg00040.html As there where at least no negative comments, I guess I should make a more formal proposal soon to solve this, for both IPv4 and IPv6 and in a standard way (hoping that the other RIR's will follow in providing this data too, but as some RIR's don't have a real IRR yet that might take time). Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Type 0 Routing Header issues
On Fri, Apr 27, 2007 at 10:19:01AM +0100, Jeroen Massar wrote: This 'problem' can be solved with looking glass websites, not which such an obvious security problem as RH0. Surely the number of looking glass websites are a clear sign of a difficency in IPv4? (Also, having to parse input to web pages and pass information to command line tools has had more than its fair share of security problems ;-) David IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
On Apr 26, 2007, at 17:17, james woodyatt wrote: [...] I still don't think type code *ZERO* is the wrong choice [...]. Oops. This should have read, I still think type code *ZERO* is the wrong choice... Sorry for any confusion. don't worry, the world is in panic like 1912. everybody is in panic(). itojun IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Type 0 Routing Header issues
Hi Alun, Hi *, Le 27 avr. 07 à 11:04, Alun Evans a écrit : I would be interested in a list of cases FOR the Type 0 Routing Header. If there are no good cases for it, it seems to me that removing it is the best thing to do. I quite like traceroute for the return path. Which would also explain why Hosts are meant to process the routing header. The thing is that we are dealing here with IPv6, the network layer protocol that we expect to carry most of the data and communications exchanged in the world in a near future. What we want that protocol to provide is an efficient and resilient service. As we all know (i hope so), this can only be achieved by keeping its basis light and simple, and preventing useless extensions to pollute routers' stacks (especially core routers). This has been a design goal of IPv6, to limit the processing performed by routers (no checksum in IPv6 header, fixed size, limited number of fields, no fragmentation in the network, smart address aggregation, ...). IMHO, having RH0 in the specification is an error. You more than many others should agree on the fact that complexity and stability/security do not fit well together, especially in stacks' implementations : - Cisco IOS had implementation issues regarding RH0, - all *BSD stacks (including Mac OS X) also made mistakes regarding RH0 processing, - Linux just prevented its use even in router mode (2.6.20.9). And those points are only implementation issues. So if you add to those facts that the mechanism is also potentially impacting at the infrastructure level, I think this clearly outweighs the convenience of remote traceroutes and co., which by the way seem to be used by 3 geeks around the world. From my perspective, RH0 should be deprecated to simplify IPv6 specification, stacks' implementations and suppress associated threats. Keeping the generic RH mechanism will be sufficient for new protocols to __carefully__ provide associated functionalities (if any), just like the designers of Mobile IPv6 did with RH2 (IMHO, processing limited to MIPv6 implementations, no external forwarding, one address max, ...). Cheers, a+ -- Arnaud Ebalard EADS Innovation Works - IT Sec Research Engineer PGP KeyID:047A5026 FingerPrint:47EB85FEB99AAB85FD0946F30255957C047A5026 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
On Wed, Apr 25, 2007 at 05:39:40PM -0700, Bob Hinden wrote: [trimming this to just the IPv6 w.g.] We think the question for the IPv6 working group on this topic is does the working group want to do anything to address the issues raised about the Type 0 routing header. Possible actions include: 1) Deprecate all usage of RH0 2) Recommend that RH0 support be off by default in hosts and routers 3) Recommend that RH0 support be off by default in hosts 4) Limit it's usage to one RH0 per IPv6 packet and limit the number of addresses in one RH0. These examples are not all mutually exclusive. Please respond to the list with your preference and justifications. It seems to me 2, maybe combined with 4, would be appropriate for now. I've read or thought about two theoretical uses: - use it to enforce a specific path that's less costly (commercially) than the default, or to avoid crossing a hostile part of the network. It occurs to me that access to such a path would probably be secured by IPSec or similar; naked, unsecured redirection would be useless in this context. - use it to access otherwise unrouted to the public networks Again, those would either be guarded by IPsec or some other VPN technology, or not really useful. Anyway, if any such setup would need RT0 in a controlled enviroment, it could be switched back on there. (After controlling RT0 *transmission* past the environment borders.) Regards, -is IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
itojun2.0 (RE: IPv6 Type 0 Routing Header issues)
even though Japanese, itojun2.0 is much like Theo so bare with me. i will use quite a language, so it's X-rated. and for those who didn't know, theo finally plan about enabling INET6 on cvs.openbsd.org and studying jinmei/shima/qingli book. our 15 years of effort was not a waste! then this doomsday news. how ironical. That's a BSD bug, not a standard bug. no, both. RFC problem: - standard introduced mistake in RFC1883 - RFC2460 (dropped loose/strict bit, at the same time maxhop/rthdr0 bumped to 128) for this hinden or deering needs harakiri - no limit in # routing headers in packet diagram just show typical header ordering not limitation so it's a big pitfall. in a very small font you can put as many routing headers in a packet!! for ths i guess deering harakiri exercise: how many hops you can make if link MTU=1280? or 9000? - even HOST must forward rthdr (we have checked w/ Steve 1000 times so KAME does not need harakiri, Deering is) implementation support - we were too spec conformant :-) - didn't know hinden/deering are spec writer, no coder they may have code when they were young, but in 1995 they had grandchild or big kid - forcused too much onto IPv6, forgot about 1992 common sense routing header considered harmful (another ironical coindidence, INET92 kobe was where ipng effort was started). because IPv4 option was dead from the beginning (WIDEs mobility protocol, VIP, used IPv4 option and it could not reach the States due to banned IPv4 option for this one, KAME needs to harakiri. with this doomsday situation and feel of guilt, how can i (or kame) take even a nap? that's why you see i keep posting and posting. deering is total slacker because he's in canada fishing Salmon!! i tried very hard to reach the author, and hinden came to us with total non-understanding and optimism when tomorrow is the doomsday. how do you think? nokia people, someone is trying to impersonate lovely hinden. if i'm wrong and it was real hinden he sent to SM club and spanked by thousands of dominas before harakiri. but that's may actually what makes him happy. but joy of SM and bondage world will finish by harakiri, we gladly allow him to enjoy SM and bondage. now, think about how IETF work as ex-IAB: in IPv4 days: - implement and test - then write a draft or, - BSD IPv4 code is there - everyone cheated and looked at it today: - write a draft with pipe dream - spam IESG - then implement - big issue happen - go back to 1 now, in KAME we meant to make t-shirt code then spec, not spec then code' clearly KAME made successful spec then code, but it was because Jun Murai bawed million (if not billion) times to get people like jinmei (he's ICHIRO or GOILLA MATSUI of toshiba), kazu (in project management he is also ICHIRO) and me (king of v6, jinmei beats me in careful spec reading because i'm spine-coder and nanosleep guy) to make IPv6 samurais, which is IPv6. and we seriously we devoted our very lives onto that i was dumped by two or three girlfriends. that guilt adds up. then spice domestic violence by father, knowledge of DNA and darwin theory (hate father, then hate myself because half of my blood is toilet water), you have a guy with mental illness. yes, that's very reason you do not bump into me at IETF venue. too much computing hurts you, i know, but to deploy IPv6 in spec then code way we need a Kamikaze attack by IPv6 samurais. let us assume 2^128 was not enough. another set of harakiri and feel guilt. i would go suicide. not suicide attack, but the game hangman. to summarize, to stop this kind of doomsday spec issue we have to switch our mind from spec then code to code then spec. require 2 interoperable independent implementation to submit draft. effects are: - robust protocol - much fewer drafts - no spam-like loony tune drafts - iesg hapy - iesg queue flushes quickly so, everyone will happy. if you object, you can call me any time, i won't be able to sleep until very last IPv6-capable machine gets upgraded. hope it will finish before i become zombie. i leave code then spec discussion to current IESG/IAB. at least IESG will be extremely happy about it. do not hesitate to cc: me, if it is IAB/IESG and email amount moderate so
Re: itojun2.0 (RE: IPv6 Type 0 Routing Header issues)
he is also ICHIRO) and me (king of v6, jinmei beats me in careful spec reading because i'm spine-coder and nanosleep guy) to make IPv6 samurais, which is IPv6. $s/IPv6\.$/KAME./ it's miracle that i need to correct only one typo. my hands are shaking due to 24x7. now i can finally take a nap. you can see if i'm awake/bbusy bby skype status of itojun.hagino (do not DDoS me please) itojun2.0 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
1) Deprecate all usage of RH0 2) Recommend that RH0 support be off by default in hosts and routers 3) Recommend that RH0 support be off by default in hosts 4) Limit it's usage to one RH0 per IPv6 packet and limit the number of addresses in one RH0. My preference is 2 or alternatively 1. I am currently not aware of any real use case for Type 0 header (but please educate me if there is some). It has been known to be dangerous for a long time and without a use case, it seems waste of energy to work on 4 or other more detailed limitations to make it safe. In particular I would very much like to see us publishing the RFC deprecating/turning this off soon. Developing the rules for 4 is possible, but it will take time. More fundamentally, I believe functions like this need to be tailored to a specific need before they can be made restricted enough to be safe and useful at the same. This is what was done with Type 2, for instance. If we will see a future need for something like this, I suspect that it may need a new Type number anyway. Alternative 3 is an interesting one. It would actually align IPv6 with current IPv4 specifications. RFC 1812 calls for a configuration option to turn off source routes, but requires the default to be that the source routes are processed. I'm not sure this is right, however... perhaps we should update corresponding IPv4 specifications at the same time, too. Jari IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: IPv6 Type 0 Routing Header issues
Manfredi, Albert E wrote: -Original Message- From: Tony Hain [mailto:[EMAIL PROTECTED] Sent: Thursday, April 26, 2007 6:52 PM As I recall the primary goal was to allow a system to state a specific transit path because it was the one that the subscriber had a contract with. Think dialing a local number to get a specific long-distance carrier's presence, rather than paying the extortion rate that the local provider charges for their random selection of long-distance. That makes good sense for the sending host. But the receiving host would have no reason to forward anything beyond the destination address of the packet, no matter what the extension header says. Except for the case of multiple IP addresses in that host, which I had not considered. Well by definition a host does not forward, else it becomes a router. In any case, I don't recall discussion about using it for alternate path selection to the same destination, but assuming the source tried RH0 using the address set from dns, it would be a lot simpler than the shim6 sillyness with exactly the same security downsides. The thing that it doesn't do is take the alternate addressing out of the source host and put it under control of the network boundary policy. If Steve Deering wanted all hosts, whether set to forward packets or not, to process extension headers, my only conclusion is that he was thinking of multiple IP addresses in that host. Except for hop-by-hop, the extension headers are explicitly about taking the end-to-end options out of the base IPv6 header. Essentially every extension header is there for processing by the receiving host. The fact that there are artifacts of the routing extension that might be useful to the receiving host was not a design goal. Just trying to figure out what the corner cases are. What you are witnessing is the eternal struggle for -control- between the end system oriented implementers and the network operations oriented implementers. There are use cases on both sides that can will be abused. People tend to disparage the use cases that don't fit their particular take on the 'who is in control' issue, and rather than defining best practice configurations they would rather take the easy out of abolishing things that give the other side some degree of control. Tony IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
Bob, On Wed, 2007-04-25 at 17:39 -0700, Bob Hinden wrote: We think the question for the IPv6 working group on this topic is does the working group want to do anything to address the issues raised about the Type 0 routing header. Possible actions include: 1) Deprecate all usage of RH0 2) Recommend that RH0 support be off by default in hosts and routers 3) Recommend that RH0 support be off by default in hosts 4) Limit it's usage to one RH0 per IPv6 packet and limit the number of addresses in one RH0. These examples are not all mutually exclusive. Please respond to the list with your preference and justifications. I am a bit surprised that the security problems with the routing header come as some sort of revelation at this stage. The intent, as I recall, in including this feature was to duplicate IPv4 source routing (originally strict source routing was supported) with all the problems, but get the specification of the processing cleaned up. That was accomplished in spades. As I recall from my conversations with him, Steve Deering never wanted this mess in the specification in the first place. I don't think it was part of SIPP but I don't have the spec handy. My recollection of a conversation with Steve on this topic back in the previous century, at an IPv6 bake-off, was that it was forced upon us by the politics of the IPng process. I think we can safely put to bed the idea that the designers were dolts who didn't learn from history. That doesn't mean there weren't dolts involved in the process.:-) That said I am in favor of 2. It is the easiest to retrofit onto existing implementations. The question I have is what action should a host and/or router take if it receives a datagram with a routing header while support is disabled: 1) ICMPv6 destination unreachable/admininistratively prohibited. 2) Other ICMPv6 destination unreachable. 3) Silent discard. I vote for 3 but I could be convinced about 1 or 2. It appears that IPv4 is supposed to do the equivalent of 1. Tim Hartrick IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: IPv6 Type 0 Routing Header issues
i don't understand, rthdr0 must be killed, grilled, diced into million pieces. say farewell. you did not do my exercise even: - how many hops you can make w/ a packet sized 1280? itojun Manfredi, Albert E wrote: -Original Message- From: Tony Hain [mailto:[EMAIL PROTECTED] Sent: Thursday, April 26, 2007 6:52 PM As I recall the primary goal was to allow a system to state a specific transit path because it was the one that the subscriber had a contract with. Think dialing a local number to get a specific long-distance carrier's presence, rather than paying the extortion rate that the local provider charges for their random selection of long-distance. That makes good sense for the sending host. But the receiving host would have no reason to forward anything beyond the destination address of the packet, no matter what the extension header says. Except for the case of multiple IP addresses in that host, which I had not considered. Well by definition a host does not forward, else it becomes a router. In any case, I don't recall discussion about using it for alternate path selection to the same destination, but assuming the source tried RH0 using the address set from dns, it would be a lot simpler than the shim6 sillyness with exactly the same security downsides. The thing that it doesn't do is take the alternate addressing out of the source host and put it under control of the network boundary policy. If Steve Deering wanted all hosts, whether set to forward packets or not, to process extension headers, my only conclusion is that he was thinking of multiple IP addresses in that host. Except for hop-by-hop, the extension headers are explicitly about taking the end-to-end options out of the base IPv6 header. Essentially every extension header is there for processing by the receiving host. The fact that there are artifacts of the routing extension that might be useful to the receiving host was not a design goal. Just trying to figure out what the corner cases are. What you are witnessing is the eternal struggle for -control- between the end system oriented implementers and the network operations oriented implementers. There are use cases on both sides that can will be abused. People tend to disparage the use cases that don't fit their particular take on the 'who is in control' issue, and rather than defining best practice configurations they would rather take the easy out of abolishing things that give the other side some degree of control. Tony IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
I am a bit surprised that the security problems with the routing header come as some sort of revelation at this stage. The intent, as I recall, yup, it's such 1992 problem. hinden and kame needs harakiri. handy. My recollection of a conversation with Steve on this topic back in the previous century, at an IPv6 bake-off, was that it was forced upon us by the politics of the IPng process. I think we can safely put to bed the idea that the designers were dolts who didn't learn from history. That doesn't mean there weren't dolts involved in the process.:-) steve and bob are too optimistic/academic, or too focused into ipv6 so that they forget about ipv4. they need to come to japan and take real world ipv6 tutorial then visit Calgary for security tutorial by theo. it's just like boot camp (no, not apple's, but army). openbsd group meeting, called c2k7 next month, and theo will gladly sneak you in so that they can put two of you into BBQ grill (but they may free to bomit). That said I am in favor of 2. It is the easiest to retrofit onto 2 is not the right answer. bzzzt. bad boy. you ate 10 minutes of sleeping time of mine. itojun PS: for those of you contacted me to say sleep man, stop. my skype is keep rebooting and my cellphone battery is dying... it's sleep man spam. IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
Hi *, Le 26 avr. 07 à 02:39, Bob Hinden a écrit : [trimming this to just the IPv6 w.g.] We think the question for the IPv6 working group on this topic is does the working group want to do anything to address the issues raised about the Type 0 routing header. Possible actions include: 1) Deprecate all usage of RH0 2) Recommend that RH0 support be off by default in hosts and routers 3) Recommend that RH0 support be off by default in hosts 4) Limit it's usage to one RH0 per IPv6 packet and limit the number of addresses in one RH0. These examples are not all mutually exclusive. Please respond to the list with your preference and justifications. After the time spent playing with the mechanism, my conclusion is that RH0 is clearly too powerful and impacting to still allow core routers and even simple routers to process it by default. For host case, forwarding of packets with RH0 is an error (quite obviously) and even processing is questionable. Regarding the needs, 99.999...% of worldwide IPv6 traffic does not use the mechanism and still perfectly flows. The remaining part is from researchers or attackers that want to DoS infrastructure elements or bypass filtering devices. Just as Paul Vixie asked, I would also be interested to hear from people that use it in a day to day basis and for valid reasons. Where some will argue that you can still filter incoming traffic that includes Type 0 Routing Header in destination sites, this is clearly not a solution, but only a bad workaround as it may still be too late at that point. If 4) is selected and even if a low number of addresses are allowed, anycast will still be defeated. Among others, maintainers of infrastructures that uses this routing scheme should be asked before selecting that action. If 3) is selected and hosts simply drop all packets that include RH0 (_even_ those with a null SegLeft value), this will clearly limit the interest of the mechanism for attackers, as none of their packets will be processed on an ultimate destination (I mean upper layer processing in default configuration). This action will not prevent amplification issues. If 2) is selected, this will also prevent attackers from using the mechanism on routers (on networks that are not specifically configured to accept it) to perform all the nasty things Philippe and I presented. This idea has already been ported to the attention of vendors (Cisco and Juniper) as the default configuration of their routers at the moment is to support RH0 by default (as expected from the specification). From my perspective, this action should be selected if 1) has too many side effects. If 1) is selected, this would simplify the specification (more than 15% deals with RH), simplify stacks and would also put a final conclusion to the blind source routing issues that bother everyone for years. My preference goes to this one. IMHO, the main concern associated with that removal is MIPv6: the side effects on RH2 should be carefully considered, if any. hope this helps, Regards, a+ -- Arnaud Ebalard EADS Innovation Works - IT Sec Research Engineer PGP KeyID:047A5026 FingerPrint:47EB85FEB99AAB85FD0946F30255957C047A5026 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Type 0 Routing Header issues
I am facing a similar dilemma. Currently editing version 2.0 draft of the US DoD DISR Product Profiles for IPv6 and considering adding a THOU SHALT NOT or at least it would be a great idea if you didn't forward based on RH0 due to this vulnerability. At the very least I will note this risk, suggesting that vendors SHOULD provide a means of disabling RH0, and also consider disabling by default. Especially interested in strong opinions from vendors about difficulty in complying if that were the case. Cross posting to NAv6TF as well, but please reply directly to [EMAIL PROTECTED] and avoid cluttering up the lists with specific objections and suggestions. I will summarize back to the lists. Thanks Ed J. Rob Austein wrote: At Wed, 25 Apr 2007 09:41:09 +0200 (CEST), Mohacsi Janos wrote: The current patch provided by OpenBSD/FreeBSD makes *BSD IPv6 implemenation non-conformant to standard. Sometimes violating the standard is the only reasonable thing for an implementor to do. The (IPv4) stack I worked on back in the '90s shipped with forwarding of directed broadcast disabled by default, long before anybody had heard of a smurf attack. The stack had a compile-time option to enable forwarding of directed broadcast; from memory, the documentation for that option went something like this: This option exists solely to allow this software to comply with RFC 1812. Directed broadcast is dangerous, no matter what RFC 1812 says. Never enable this option under any circumstances. Eventually the IETF gathered the collective will to update the standard, but as implementors we would have been derelict in our duty to our customers had we waited for the IETF. -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or [EMAIL PROTECTED] IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Type 0 Routing Header issues
Hi, On Wed, Apr 25, 2007 at 09:41:09AM +0200, Mohacsi Janos wrote: I think this is not a solution. The problems of routing header type 0 well know by the community since long time. This has been documented for more than 2-3 years know (raised 4 years ago). Are there any consensus, that type 0 routing header should be deprecated? Until that it is documented to be filtered if there is no need for it. The current patch provided by OpenBSD/FreeBSD makes *BSD IPv6 implemenation non-conformant to standard. Well, one could argue that the standard isn't very well-written then - a machine that is a *host* should NEVER forward packets, period. That's what we have routers for, and there is a well-defined way to change a *BSD machine from a host to a router (turn on ip6.forwarding). I would rather focus on pf changes - allow filtering based on the routing header type. Currently you can filter based existence/non-existence of routing header type. This is currently clearly not enough Extending pf(4) accordingly would certainly be a good thing, as it could help other machines behind a NetBSD firewall. (BTW - what's pf(4) doing if a packet comes with with RH0? Which address does it use for ACL checking, and which address is used for state setup?) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Type 0 Routing Header issues
Hi, On Wed, Apr 25, 2007 at 10:46:54AM +0200, Remi Denis-Courmont wrote: On Wed, 25 Apr 2007 10:24:08 +0200, Gert Doering [EMAIL PROTECTED] wrote: Well, one could argue that the standard isn't very well-written then - a machine that is a *host* should NEVER forward packets, period. That's a BSD bug, not a standard bug. The IPv6 specification says host must process RT0. It does not say they must forward packets as if they were routers on the sole basis of RT0 presence. By the current spec (as far as I understand), if a host receives a RT0, it must process it. Then it must apply the same rules to the new packet destination as it would do to any packet it receives; in particular, if the packet cannot be delivered locally, it is dropped. You do the exact same thing when you receive a packet from link-layer while you are not the destination at network-layer. Thanks for the clarification. Indeed, this explains the necessity to process the RH0 header locally (it might point to a different address on the *same host*). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279 pgp7gSQZ7duGb.pgp Description: PGP signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: IPv6 Type 0 Routing Header issues
-Original Message- From: Gert Doering [mailto:[EMAIL PROTECTED] On Wed, Apr 25, 2007 at 10:46:54AM +0200, Remi Denis-Courmont wrote: On Wed, 25 Apr 2007 10:24:08 +0200, Gert Doering [EMAIL PROTECTED] wrote: Well, one could argue that the standard isn't very well-written then - a machine that is a *host* should NEVER forward packets, period. That's a BSD bug, not a standard bug. The IPv6 specification says host must process RT0. It does not say they must forward packets as if they were routers on the sole basis of RT0 presence. By the current spec (as far as I understand), if a host receives a RT0, it must process it. Then it must apply the same rules to the new packet destination as it would do to any packet it receives; in particular, if the packet cannot be delivered locally, it is dropped. You do the exact same thing when you receive a packet from link-layer while you are not the destination at network-layer. Thanks for the clarification. Indeed, this explains the necessity to process the RH0 header locally (it might point to a different address on the *same host*). Which would be a good tool for anyone intending a DOS attack on that single host. I've been trying to figure out why Steve Deering wanted RHO to be supported in hosts and routers. Maybe this was the reason. Multiple IP addresses in a host. Bert IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
Le 26 avr. 07 .AN` 02:39, Bob Hinden a Nicrit :*B ah, finally. i even try to reach Steve saying no time for Salmon fishing, man. [trimming this to just the IPv6 w.g.] We think the question for the IPv6 working group on this topic is does the working group want to do anything to address the issues raised about the Type 0 routing header. Possible actions include: 1) Deprecate all usage of RH0 2) Recommend that RH0 support be off by default in hosts and routers 3) Recommend that RH0 support be off by default in hosts 4) Limit it's usage to one RH0 per IPv6 packet and limit the number of addresses in one RH0. These examples are not all mutually exclusive. Please respond to the list with your preference and justifications. are you still did not get the urgency? haven't you read my analysis and THE PDF file? it's total doomsday for IPv6 (if not the planet). we were really lucky that IPv6-haters did not get it. do you know how many sleepless nights i have been spending starting last Friday (when theo woke me up and pointed me to the PDF). we must spread the word never miss the next software update from Apple since Apple is the most dangerous beast since it does 6to4/teredo (oops, was teredo MS only?) by default. we have already leaked it to the japanese press people. i wonder how many of them are clever enough to understand it (i told my close friend but he works for TV station, so i even leaked the real effect). itojun PS: if i do not get postel award (if not novel prize of peace) i'll quit KAME and become a new life as a freelance IPv6 evangelist. first target is Skype, which is totally IPv6-unfriendly. IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
Bob Hinden wrote: [trimming this to just the IPv6 w.g.] We think the question for the IPv6 working group on this topic is does the working group want to do anything to address the issues raised about the Type 0 routing header. Possible actions include: 1) Deprecate all usage of RH0 2) Recommend that RH0 support be off by default in hosts and routers I see these two as being equivalent. If RH0 is going to be off by default in routers, then it's for all intents and purposes unusable and should be fully deprecated. no, do not place sysctl. devote time to develop new type 'routing header type 123' instead. it does not have bad sideffect but can perform something like rthdr0. in this doomsday story and samurais saving the planet, we were extremely lucky beacause: - iPv6-haters still didn't get it (or did they changed their mind?) - MIP6 was NOT using rthdr0 it's a message from god. itojun IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: IPv6 Type 0 Routing Header issues
Before you kill this off too quickly, James Woodyatt's proxy redirection is a perfect example of a use for Type 0 Routing Headers. He wants the firewall to redirect traffic through a designated point (what this header was designed to do), and the only hammer at his immediate disposal was IPv6/IPv6 nat. It is certainly reasonable to have a BCP that says 'these should be filtered at policy boundaries unless there is a good reason to do otherwise', but they are a tool to solve some very specific corner cases. Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Jankiewicz Sent: Wednesday, April 25, 2007 8:13 AM To: [EMAIL PROTECTED] Cc: Rob Austein; ipv6@ietf.org; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: IPv6 Type 0 Routing Header issues I am facing a similar dilemma. Currently editing version 2.0 draft of the US DoD DISR Product Profiles for IPv6 and considering adding a THOU SHALT NOT or at least it would be a great idea if you didn't forward based on RH0 due to this vulnerability. At the very least I will note this risk, suggesting that vendors SHOULD provide a means of disabling RH0, and also consider disabling by default. Especially interested in strong opinions from vendors about difficulty in complying if that were the case. Cross posting to NAv6TF as well, but please reply directly to [EMAIL PROTECTED] and avoid cluttering up the lists with specific objections and suggestions. I will summarize back to the lists. Thanks Ed J. Rob Austein wrote: At Wed, 25 Apr 2007 09:41:09 +0200 (CEST), Mohacsi Janos wrote: The current patch provided by OpenBSD/FreeBSD makes *BSD IPv6 implemenation non-conformant to standard. Sometimes violating the standard is the only reasonable thing for an implementor to do. The (IPv4) stack I worked on back in the '90s shipped with forwarding of directed broadcast disabled by default, long before anybody had heard of a smurf attack. The stack had a compile-time option to enable forwarding of directed broadcast; from memory, the documentation for that option went something like this: This option exists solely to allow this software to comply with RFC 1812. Directed broadcast is dangerous, no matter what RFC 1812 says. Never enable this option under any circumstances. Eventually the IETF gathered the collective will to update the standard, but as implementors we would have been derelict in our duty to our customers had we waited for the IETF. -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or [EMAIL PROTECTED] IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: IPv6 Type 0 Routing Header issues
As I recall the primary goal was to allow a system to state a specific transit path because it was the one that the subscriber had a contract with. Think dialing a local number to get a specific long-distance carrier's presence, rather than paying the extortion rate that the local provider charges for their random selection of long-distance. Tony -Original Message- From: Manfredi, Albert E [mailto:[EMAIL PROTECTED] Sent: Thursday, April 26, 2007 8:03 AM To: Gert Doering Cc: ipv6@ietf.org Subject: RE: IPv6 Type 0 Routing Header issues -Original Message- From: Gert Doering [mailto:[EMAIL PROTECTED] On Wed, Apr 25, 2007 at 10:46:54AM +0200, Remi Denis-Courmont wrote: On Wed, 25 Apr 2007 10:24:08 +0200, Gert Doering [EMAIL PROTECTED] wrote: Well, one could argue that the standard isn't very well-written then - a machine that is a *host* should NEVER forward packets, period. That's a BSD bug, not a standard bug. The IPv6 specification says host must process RT0. It does not say they must forward packets as if they were routers on the sole basis of RT0 presence. By the current spec (as far as I understand), if a host receives a RT0, it must process it. Then it must apply the same rules to the new packet destination as it would do to any packet it receives; in particular, if the packet cannot be delivered locally, it is dropped. You do the exact same thing when you receive a packet from link-layer while you are not the destination at network-layer. Thanks for the clarification. Indeed, this explains the necessity to process the RH0 header locally (it might point to a different address on the *same host*). Which would be a good tool for anyone intending a DOS attack on that single host. I've been trying to figure out why Steve Deering wanted RHO to be supported in hosts and routers. Maybe this was the reason. Multiple IP addresses in a host. Bert IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
I thought we already limited to 1 RH0 per packet, but I will have to go back and take a closer look. As I said on V6ops, before you kill this off too quickly, James Woodyatt's proxy redirection is a perfect example of a valid use for Type 0 Routing Headers. He wants the firewall to redirect traffic through a designated point (what this header was designed to do), and the only hammer at his immediate disposal was IPv6/IPv6 nat. What I don't know is if the firewall can insert one that did not exist, because the source wouldn't know about his 'transparent' proxy. It is certainly reasonable to have a BCP that says 'these should be filtered at policy boundaries unless there is a good reason to do otherwise', but they are a tool to solve some very specific corner cases. I would say that firewalls should drop these by default, but the rest of the system should recognize them as normal. Tony -Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] Sent: Thursday, April 26, 2007 3:17 AM To: IETF IPv6 Mailing List Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues] On 2007-04-26 02:39, Bob Hinden wrote: [trimming this to just the IPv6 w.g.] We think the question for the IPv6 working group on this topic is does the working group want to do anything to address the issues raised about the Type 0 routing header. Possible actions include: 1) Deprecate all usage of RH0 2) Recommend that RH0 support be off by default in hosts and routers 3) Recommend that RH0 support be off by default in hosts 4) Limit it's usage to one RH0 per IPv6 packet and limit the number of addresses in one RH0. Excuse my ignorance, but have the following three rules ever been considered? 1. The list of addresses in an RH0 MUST NOT include the packet's source address. 2. The same address MUST NOT occur more than once in an RH0. 3. A node processing an RH0 MUST discard any packet breaking these two rules. I'd be interested in whether this would eliminate the various attacks. (I'm not really advocating this, since it is added complexity for a feature that we don't obviously need anyway. But if we don't deprecate it, all the other options seem to leave the threats in place.) Brian IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
On Apr 26, 2007, at 15:58, Tony Hain wrote: As I said on V6ops, before you kill this off too quickly, James Woodyatt's proxy redirection is a perfect example of a valid use for Type 0 Routing Headers. He wants the firewall to redirect traffic through a designated point (what this header was designed to do), and the only hammer at his immediate disposal was IPv6/IPv6 nat. What I don't know is if the firewall can insert one that did not exist, because the source wouldn't know about his 'transparent' proxy. I should make clear that I'm not persuaded that use of the routing extension header gives me a way to do what I've been talking about in both V6OPS and BEHAVE. Moreover, I *really* don't think RH type code **ZERO** is a better hammer than simple IPv6 NAT. (Oh boy... I've just whacked another beehive, haven't I?) For my immediate purposes, where I only need to redirect inside the routing node between the packet filter and the node's own stack, I can probably define my own internal routing extension header type code. In fact, since the packets aren't going anywhere on the wire, I could just dispense with the extension header altogether and just overwrite the destination address in the IPv6 header while inserting an appropriate state record into the packet filter for the proxy to find. This will be functionally equivalent to using IPv6 NAT, and I'll be doing this in the code that implements the IPv4 NAT and SPI filter, but if it makes everyone feel more warm and fuzzy that no actual NAT is going on, I'll use another word for it. I wouldn't want anybody to lose more sleep. Where the situation gets a lot more interesting is when the transparent application proxy is not resident on the same node as the filter where the diversion happens. That's where the routing extension header could be necessary. In that case, I still don't think type code *ZERO* is the wrong choice, because something must *remove* the extension header on the return path for the proxy to remain transparent. -- j h woodyatt [EMAIL PROTECTED] IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
On Apr 26, 2007, at 17:17, james woodyatt wrote: [...] I still don't think type code *ZERO* is the wrong choice [...]. Oops. This should have read, I still think type code *ZERO* is the wrong choice... Sorry for any confusion. -- j h woodyatt [EMAIL PROTECTED] IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Type 0 Routing Header issues
Hi, I would be interested in a list of cases FOR the Type 0 Routing Header. If there are no good cases for it, it seems to me that removing it is the best thing to do. Best, George IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Type 0 Routing Header issues
Hi All, I think this is not a solution. The problems of routing header type 0 well know by the community since long time. This has been documented for more than 2-3 years know (raised 4 years ago). Are there any consensus, that type 0 routing header should be deprecated? Until that it is documented to be filtered if there is no need for it. The current patch provided by OpenBSD/FreeBSD makes *BSD IPv6 implemenation non-conformant to standard. I would rather focus on pf changes - allow filtering based on the routing header type. Currently you can filter based existence/non-existence of routing header type. This is currently clearly not enough Regards, Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Wed, 25 Apr 2007, George V. Neville-Neil wrote: At Wed, 25 Apr 2007 00:46:28 +0300, Jari Arkko wrote: Just in case folks are missing out on this, find below a rather nasty security issue. I cannot say that this is a big surprise, even if the specific attack is news to me and it has a major impact. Some issues with Type 0 have been known for years; I think draft-savola-ipv6-rh-ha was the first to report these. RFC 4294 warns of the issues and RFC 3775 design was based on the idea of avoiding Type 0 because it was felt that at some point Type 0 would likely be filtered due to its problems. Also, draft-ietf-v6ops-security-overview was recently approved. It notes, among other things that it may be desirable to forbid or limit the processing of Type 0 Routing Headers in hosts and some routers. So I think we should take that advice and modify the stacks that do not do the right thing today. A good first approximation is to add a configuration knob for processing Type 0 headers in both hosts and routers, with default set to off. Better firewall support for doing this would also be needed (without disabling use of Type 2, of course). FreeBSD has already committed patches disabling the processing of route header option 0 by default in all 3 of the currently shipping branches (HEAD, 6-STABLE and 5-STABLE). But we at the IETF also need to draw a conclusion about the state of Type 0. This feature needs to be retired. The sooner that decision is made the better. Those of us working on the stacks would like to remove this processing if the feature is retired. Best, George Neville-Neil (FreeBSD Security Team and Core Member) IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Type 0 Routing Header issues
On Wed, Apr 25, 2007 at 09:41:09AM +0200, Mohacsi Janos wrote: I think this is not a solution. The problems of routing header type 0 well know by the community since long time. This has been documented for more than 2-3 years know (raised 4 years ago). Are there any consensus, that type 0 routing header should be deprecated? Until that it is documented to be filtered if there is no need for it. The current patch provided by OpenBSD/FreeBSD makes *BSD IPv6 implemenation non-conformant to standard. I would rather focus on pf changes - allow filtering based on the routing header type. Currently you can filter based existence/non-existence of routing header type. It seems to me that there are at least two questions here. One is, Should IPv6 nodes process type 0 routing headers by default? The second is, should the network allow type 0 routing headers to pass? This is a bit like they choice you have for blocking a smurf attack. You can block it by turning off directed broadcasts (on the edge) or you can block it by blocking ICMP packets throughout the network. I think it may actually be that we do not want nodes to process type 0 routing headers by default, but the network should pass them. The reason for this is that the type 0 headers have useful applications which could be secured by end hosts without getting the network involved at all. Then end hosts that want to use the routing header can, and those that don't are secure by default. I could easily be wrong though... David. IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Type 0 Routing Header issues
On Wed, 25 Apr 2007 10:24:08 +0200, Gert Doering [EMAIL PROTECTED] wrote: Well, one could argue that the standard isn't very well-written then - a machine that is a *host* should NEVER forward packets, period. That's a BSD bug, not a standard bug. The IPv6 specification says host must process RT0. It does not say they must forward packets as if they were routers on the sole basis of RT0 presence. By the current spec (as far as I understand), if a host receives a RT0, it must process it. Then it must apply the same rules to the new packet destination as it would do to any packet it receives; in particular, if the packet cannot be delivered locally, it is dropped. You do the exact same thing when you receive a packet from link-layer while you are not the destination at network-layer. Whether RT0 is evil and it should be deprecated so routers do not handle it anymore is the real problem. -- Rémi Denis-Courmont http://www.remlab.net/ IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Type 0 Routing Header issues
On Wed, 25 Apr 2007 10:24:08 +0200, Gert Doering [EMAIL PROTECTED] wrote: Well, one could argue that the standard isn't very well-written then - a machine that is a *host* should NEVER forward packets, period. bzzzt. with IPv6 spec NODE (host + router) has to handle routing header type 0 and forward *even if ip6.forwarding is 0. that's the steve deering's last word before he left to Canada for retirement. itojun IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Type 0 Routing Header issues
... The problems of routing header type 0 well know by the community since long time. This has been documented for more than 2-3 years know (raised 4 years ago). Are there any consensus, that type 0 routing header should be deprecated? ... yes. nobody anywhere still thinks that this is necessary for any purpose. (if noone within the sound of my voice disagrees, then you have your proof.) ((i just wish i'd had the guts to turn it off on f-root BEFORE the cansecwest presentation, so that we would not have been such a convenient example.)) IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Type 0 Routing Header issues
... The problems of routing header type 0 well know by the community since long time. This has been documented for more than 2-3 years know (raised 4 years ago). Are there any consensus, that type 0 routing header should be deprecated? ... yes. nobody anywhere still thinks that this is necessary for any purpose. (if noone within the sound of my voice disagrees, then you have your proof.) ((i just wish i'd had the guts to turn it off on f-root BEFORE the cansecwest presentation, so that we would not have been such a convenient example.)) i heard that, in some of peering agreement contract, traceroute -g (something that works like routing header type 0) is needed (for debugging or make sure the peer is not cheating. to make them happy, we need secure version of rthdr0 which supports such use and no bad sideeffect (with new type, like routing header type 7). itojun IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Type 0 Routing Header issues
At Wed, 25 Apr 2007 09:41:09 +0200 (CEST), Mohacsi Janos wrote: The current patch provided by OpenBSD/FreeBSD makes *BSD IPv6 implemenation non-conformant to standard. Sometimes violating the standard is the only reasonable thing for an implementor to do. The (IPv4) stack I worked on back in the '90s shipped with forwarding of directed broadcast disabled by default, long before anybody had heard of a smurf attack. The stack had a compile-time option to enable forwarding of directed broadcast; from memory, the documentation for that option went something like this: This option exists solely to allow this software to comply with RFC 1812. Directed broadcast is dangerous, no matter what RFC 1812 says. Never enable this option under any circumstances. Eventually the IETF gathered the collective will to update the standard, but as implementors we would have been derelict in our duty to our customers had we waited for the IETF. IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Type 0 Routing Header issues
Yes, absolutely. Rob, I couldn't agree more. From: Rob Austein [EMAIL PROTECTED] Date: 2007/04/25 Wed AM 09:13:36 CDT To: [EMAIL PROTECTED], ipv6@ietf.org, [EMAIL PROTECTED] Subject: Re: IPv6 Type 0 Routing Header issues At Wed, 25 Apr 2007 09:41:09 +0200 (CEST), Mohacsi Janos wrote: The current patch provided by OpenBSD/FreeBSD makes *BSD IPv6 implemenation non-conformant to standard. Sometimes violating the standard is the only reasonable thing for an implementor to do. The (IPv4) stack I worked on back in the '90s shipped with forwarding of directed broadcast disabled by default, long before anybody had heard of a smurf attack. The stack had a compile-time option to enable forwarding of directed broadcast; from memory, the documentation for that option went something like this: This option exists solely to allow this software to comply with RFC 1812. Directed broadcast is dangerous, no matter what RFC 1812 says. Never enable this option under any circumstances. Eventually the IETF gathered the collective will to update the standard, but as implementors we would have been derelict in our duty to our customers had we waited for the IETF. IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
[trimming this to just the IPv6 w.g.] We think the question for the IPv6 working group on this topic is does the working group want to do anything to address the issues raised about the Type 0 routing header. Possible actions include: 1) Deprecate all usage of RH0 2) Recommend that RH0 support be off by default in hosts and routers 3) Recommend that RH0 support be off by default in hosts 4) Limit it's usage to one RH0 per IPv6 packet and limit the number of addresses in one RH0. These examples are not all mutually exclusive. Please respond to the list with your preference and justifications. Thanks, Bob Hinden / Brian Haberman IPv6 W.G. Chairs p.s. We will send a note to the other lists that the IPv6 w.g. will be discussing this issue. IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
Bob Hinden wrote: [trimming this to just the IPv6 w.g.] We think the question for the IPv6 working group on this topic is does the working group want to do anything to address the issues raised about the Type 0 routing header. Possible actions include: 1) Deprecate all usage of RH0 2) Recommend that RH0 support be off by default in hosts and routers I see these two as being equivalent. If RH0 is going to be off by default in routers, then it's for all intents and purposes unusable and should be fully deprecated. 3) Recommend that RH0 support be off by default in hosts This is what everyone already expects the behavior to be, and even people on this list have shown surprise when they have discovered that this is not the case. I'd completely agree with this. 4) Limit it's usage to one RH0 per IPv6 packet and limit the number of addresses in one RH0. The use case that I would want to use is allowing trace routes from a-b when you don't have access to either end, or for asking for a reverse trace route from a host back to yourself. These don't require multiple RH0's. If it's not done already (I've not had time to read the spec carefully), you should also check that the scope is the same (or possibly greater) to prevent people for example using RH0 to talk to hosts that only have link local addresses via a router that has a globally routable address. So, I'd prefer disabling it for end hosts, enabling it by default on routers but limiting it to only one RH0 header with the same scope. If that is not acceptable, then deprecate the entire feature. IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Type 0 Routing Header issues
Just in case folks are missing out on this, find below a rather nasty security issue. I cannot say that this is a big surprise, even if the specific attack is news to me and it has a major impact. Some issues with Type 0 have been known for years; I think draft-savola-ipv6-rh-ha was the first to report these. RFC 4294 warns of the issues and RFC 3775 design was based on the idea of avoiding Type 0 because it was felt that at some point Type 0 would likely be filtered due to its problems. Also, draft-ietf-v6ops-security-overview was recently approved. It notes, among other things that it may be desirable to forbid or limit the processing of Type 0 Routing Headers in hosts and some routers. So I think we should take that advice and modify the stacks that do not do the right thing today. A good first approximation is to add a configuration knob for processing Type 0 headers in both hosts and routers, with default set to off. Better firewall support for doing this would also be needed (without disabling use of Type 2, of course). But we at the IETF also need to draw a conclusion about the state of Type 0. This feature needs to be retired. Jari IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Type 0 Routing Header issues
At Wed, 25 Apr 2007 00:46:28 +0300, Jari Arkko wrote: Just in case folks are missing out on this, find below a rather nasty security issue. I cannot say that this is a big surprise, even if the specific attack is news to me and it has a major impact. Some issues with Type 0 have been known for years; I think draft-savola-ipv6-rh-ha was the first to report these. RFC 4294 warns of the issues and RFC 3775 design was based on the idea of avoiding Type 0 because it was felt that at some point Type 0 would likely be filtered due to its problems. Also, draft-ietf-v6ops-security-overview was recently approved. It notes, among other things that it may be desirable to forbid or limit the processing of Type 0 Routing Headers in hosts and some routers. So I think we should take that advice and modify the stacks that do not do the right thing today. A good first approximation is to add a configuration knob for processing Type 0 headers in both hosts and routers, with default set to off. Better firewall support for doing this would also be needed (without disabling use of Type 2, of course). FreeBSD has already committed patches disabling the processing of route header option 0 by default in all 3 of the currently shipping branches (HEAD, 6-STABLE and 5-STABLE). But we at the IETF also need to draw a conclusion about the state of Type 0. This feature needs to be retired. The sooner that decision is made the better. Those of us working on the stacks would like to remove this processing if the feature is retired. Best, George Neville-Neil (FreeBSD Security Team and Core Member) IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
