From weinholt at csbnet.se Thu Sep 4 16:47:39 2008 From: weinholt at csbnet.se (=?utf-8?Q?G=C3=B6ran?= Weinholt) Date: Thu Sep 4 16:48:03 2008 Subject: Running IPv6 on a large L2 network Message-ID: Hello IPv6 operators, I'm wondering if anyone here has advice for how to manage IPv6 abuse on a large L2 network. For IPv4 our HP ProCurve switches support IP lockdown, ARP-protect etc which prevents most of the nastiness for IPv4. The switches do not have similar functions for IPv6. What I'd like is to prevent (or detect and rectify) things like neighbor table poisoning and advertisements of bad routes. Something like a list of all the ways IPv6 can be abused on an L2 network would be very helpful. As an example: if someone sets up radvd and announces the 2000::/3 prefix, all hosts on the LAN will have an on-link route for 2000::/3 (at least this is what happens in Linux). This route is more specific than the default route, so now all traffic will go on-link. The attacker can then answer neighbor solicitations for all addresses, and forward the traffic to the real router (i.e. do a MITM attack). Even if I disable the attacker's network connection, the route will still be there on the hosts so a confederate can perform the actual MITM attack. Even if I can find and disconnect the confederate, IPv6 will still be broken for all hosts until the 2000::/3 route expires. But the more common IPv6 problem on our network is that someone configures their Windows machine to "share" a network connection, and Windows then helpfully starts announcing a 6to4 prefix. I wrote this program to stop innocent hosts from using those addresses (written in one day, probably only works on Linux, requires python-pcapy): http://staff.csbnet.se/~weinholt/tools/ipknuff This still leaves the on-link route for the announced prefix. Is there any way that I can tell hosts to throw away that route before it expires? Regards, -- G?ran Weinholt Network Administrator, Chalmers Studentbost?der From jeroen at unfix.org Thu Sep 4 16:58:47 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Thu Sep 4 16:58:53 2008 Subject: Running IPv6 on a large L2 network In-Reply-To: References: Message-ID: <48BFF7A7.2040007@spaghetti.zurich.ibm.com> G?ran Weinholt wrote: > Hello IPv6 operators, > > I'm wondering if anyone here has advice for how to manage IPv6 abuse > on a large L2 network. For IPv4 our HP ProCurve switches support IP > lockdown, ARP-protect etc which prevents most of the nastiness for > IPv4. The switches do not have similar functions for IPv6. > > What I'd like is to prevent (or detect and rectify) things like > neighbor table poisoning and advertisements of bad routes. Something > like a list of all the ways IPv6 can be abused on an L2 network would > be very helpful. A *lot* of issues, mostly concerning RA and other ICMP messages though. One advantage for you though: a /64 is virtually unlimited address space. As you mention abuse though, you will want to install a tool like NDPmon to at least record MAC<->IPv6 address relations, especially with RFC3041 in mind. You will also want to lock down ports based on MAC and other nasty tricks. Then again, you didn't specify how nasty the environment is; When I hear L2 and "security" though and "protection against X" I always think of 802.1x so that you at least authenticate the baddies and can track them easily based on something else than what they provide you. Of course you have at least a port number hopefully. > As an example: if someone sets up radvd and announces the 2000::/3 > prefix, all hosts on the LAN will have an on-link route for 2000::/3 > (at least this is what happens in Linux). That is because Linux is broken then, it should only accept an RA'd prefix which is a /64. (I wonder how it would construct a full IP address from a /3 + 64bits of EUI-64 anyway...) > This route is more specific than the default route Even if somebody simply sets up an RA'd block that would give a nice default route already, depending then on the host it will pick yours or another. [..] > This still leaves the on-link route for the announced prefix. Is there > any way that I can tell hosts to throw away that route before it > expires? Needs to be configured on a per-host basis unfortunately unless you can do the filtering in the middle of your network. IP was meant for routing, not for switching... Microsoft has a nice list though: http://technet.microsoft.com/en-us/library/bb726956.aspx Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20080904/aeedddf8/signature.bin From dwhite at olp.net Thu Sep 4 19:12:45 2008 From: dwhite at olp.net (Dan White) Date: Thu Sep 4 19:13:04 2008 Subject: Running IPv6 on a large L2 network In-Reply-To: <48BFF7A7.2040007@spaghetti.zurich.ibm.com> References: <48BFF7A7.2040007@spaghetti.zurich.ibm.com> Message-ID: <48C0170D.2060505@olp.net> Jeroen Massar wrote: > When I hear L2 and "security" though and "protection > against X" I always think of 802.1x so that you at least authenticate > the baddies and can track them easily based on something else than what > they provide you. Of course you have at least a port number hopefully. > or 802.1q. If your network design supports it, you could put each customer/end-point into their own VLAN, or Q-in-Q VLAN, for layer 2 protection. That of course offers its own set of challenges, such as how to scale your router(s). We're looking at moving to this approach, for other reasons as well, in our broadband network. Most of our vendors support next to nothing in the area of IPv6, but they do have good ethernet support. Linux also has Q-in-Q support, which makes for a cheap IPv6 router. - Dan From weinholt at csbnet.se Fri Sep 5 13:12:33 2008 From: weinholt at csbnet.se (=?utf-8?Q?G=C3=B6ran?= Weinholt) Date: Fri Sep 5 13:12:52 2008 Subject: Running IPv6 on a large L2 network In-Reply-To: <48BFF7A7.2040007@spaghetti.zurich.ibm.com> (Jeroen Massar's message of "Thu\, 04 Sep 2008 16\:58\:47 +0200") References: <48BFF7A7.2040007@spaghetti.zurich.ibm.com> Message-ID: [I sent a reply yesterday that hasn't arrived yet. The moderator can just delete it. I apologize for any duplicates.] Jeroen Massar writes: > G?ran Weinholt wrote: >> What I'd like is to prevent (or detect and rectify) things like >> neighbor table poisoning and advertisements of bad routes. Something >> like a list of all the ways IPv6 can be abused on an L2 network would >> be very helpful. > > A *lot* of issues, mostly concerning RA and other ICMP messages though. > > One advantage for you though: a /64 is virtually unlimited address > space. As you mention abuse though, you will want to install a tool like > NDPmon to at least record MAC<->IPv6 address relations, especially with > RFC3041 in mind. You will also want to lock down ports based on MAC and > other nasty tricks. Then again, you didn't specify how nasty the > environment is; When I hear L2 and "security" though and "protection > against X" I always think of 802.1x so that you at least authenticate > the baddies and can track them easily based on something else than what > they provide you. Of course you have at least a port number hopefully. It's a student dorm network, so there is bound to be some people that will try something just to see what will happen. In the future it's not unlikely that viruses will try various mischief. I do have their switch port number, but I still need to detect the mischief. 802.1x is not very useful for our network. >> As an example: if someone sets up radvd and announces the 2000::/3 >> prefix, all hosts on the LAN will have an on-link route for 2000::/3 >> (at least this is what happens in Linux). > > That is because Linux is broken then, it should only accept an RA'd > prefix which is a /64. (I wonder how it would construct a full IP > address from a /3 + 64bits of EUI-64 anyway...) I forgot to write that I sent a /64 along with the /3 prefix. Linux generates an address and route for the /64, but also adds a route for the /3. Windows Vista also adds an on-link route for the /3. >> This route is more specific than the default route > > Even if somebody simply sets up an RA'd block that would give a nice > default route already, depending then on the host it will pick yours or > another. Yeah, but since I have a MAC<->port mapping I can just disconnect the user that sent the RA. Neighbor unreachability detection will then hopefully keep traffic to the real router working. In the scenario I posted it doesn't matter if I disconnect the user that sent the RA, the network will still be broken for other hosts because of the bogus on-link route. To remove the route I might send my own RA with the announced prefixes and a very low lifetime, but the lowest lifetime allowed according to RFC4862 is two hours (ironically changed recently to address a possible DoS...) So right now if someone performs this attack here at the dorm, all I can do is tell students to either remove the route manually or reboot if they want IPv6 to work again. I guess this is similar to the problems with rogue DHCP servers, but router advertisements affect everyone at once so there is no time to disconnect the rouge radvd before the damage is done. > [..] >> This still leaves the on-link route for the announced prefix. Is there >> any way that I can tell hosts to throw away that route before it >> expires? > > Needs to be configured on a per-host basis unfortunately unless you can > do the filtering in the middle of your network. > > IP was meant for routing, not for switching... I will keep my eye out for switches with IPv6 support then, especially routing switches. > Microsoft has a nice list though: > http://technet.microsoft.com/en-us/library/bb726956.aspx The audience for that page seems to be enterprises and maybe not dorms, so not too interesting for us unfortunately. Regards, -- Network Administrator, Chalmers Studentbost?der From david.freedman at uk.clara.net Sat Sep 6 00:09:12 2008 From: david.freedman at uk.clara.net (david.freedman@uk.clara.net) Date: Sat Sep 6 00:09:22 2008 Subject: Filtering ULA? Message-ID: Is there any good reason why I shouldn't be filtering the ULA (RFC4193) range at the edge (FC00::/7) ? I was looking over http://www.space.net/~gert/RIPE/ipv6-filters.html today and didn't spot it in the relaxed filter, The RFC (section 4.3) is a bit vague on filtering and just says "Routers that maintain peering arrangements between Autonomous Systems throughout the Internet should obey the recommendations for site border routers, unless configured otherwise." The RIPE policy proposal 2007-05 (http://www.ripe.net/ripe/policies/proposals/2007-05.html) mentions: "It is also important to reinforce that the ULA prefix (FC00::/7) it is not routable in the global Internet (i.e. not designed to be used as IPv6 PI) and consequently must be filtered." As much as I would guess the answer to this would be "if you are concerned, use the strict filter", I'm in the process of revisiting my IPv6 edge security and would be interested if anybody can think of a good reason not to do this, or if by doing this one *should* as the RFC suggests provide ICMP6 feedback to the client indicating the filtered nature of the space (*shudder*) Dave. ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net From fred at cisco.com Sat Sep 6 00:30:35 2008 From: fred at cisco.com (Fred Baker) Date: Sat Sep 6 00:36:24 2008 Subject: Filtering ULA? In-Reply-To: References: Message-ID: <64808506-C81B-4FF8-8693-17CBD19D5F7E@cisco.com> On Sep 5, 2008, at 3:09 PM, david.freedman@uk.clara.net wrote: > Is there any good reason why I shouldn't be filtering the ULA > (RFC4193) > range at the edge (FC00::/7) ? My understanding: You should *absolutely* be filtering the ULA range of prefixes from you customers unless you have an agreement to do otherwise, and then you should implement that agreement. There are some strictures on the form of the agreement; if a network agrees to share a ULA with another network, it should be shared between those networks and not with others. In general - and if I were writing a contract that permitted ULA exchange I would include this in the contract - I would expect an ISP to refuse all ULA prefixes from customers and expect customers of ISPs to share ULAs over some form of VPN or private connectivity. If you don't do that, a ULA is a random prefix that a network decided to use, and may conflict with some other network that randomly picked the same prefix. Think about it... From gert at space.net Sun Sep 7 14:17:57 2008 From: gert at space.net (Gert Doering) Date: Sun Sep 7 14:18:20 2008 Subject: Running IPv6 on a large L2 network In-Reply-To: References: <48BFF7A7.2040007@spaghetti.zurich.ibm.com> Message-ID: <20080907121757.GS25927@Space.Net> Hi, On Fri, Sep 05, 2008 at 01:12:33PM +0200, G?ran Weinholt wrote: > It's a student dorm network, so there is bound to be some people that > will try something just to see what will happen. In the future it's > not unlikely that viruses will try various mischief. I do have their > switch port number, but I still need to detect the mischief. 802.1x is > not very useful for our network. You could actually try to move towards a more "routed" environment - with IPv6, you could give every student their own routed /64, and whatever mischief one of them is going to do will only affect his own machines. (And yes, getting there without breaking the IPv4 stuff will be "interesting"). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From weinholt at csbnet.se Tue Sep 9 12:43:04 2008 From: weinholt at csbnet.se (=?utf-8?Q?G=C3=B6ran?= Weinholt) Date: Tue Sep 9 12:43:18 2008 Subject: Running IPv6 on a large L2 network In-Reply-To: (=?utf-8?Q?=22G=C3=B6ran?= Weinholt"'s message of "Fri\, 05 Sep 2008 13\:12\:33 +0200") References: <48BFF7A7.2040007@spaghetti.zurich.ibm.com> Message-ID: weinholt@csbnet.se (G?ran Weinholt) writes: > In the scenario I posted it doesn't matter if I disconnect the user > that sent the RA, the network will still be broken for other hosts > because of the bogus on-link route. To remove the route I might send > my own RA with the announced prefixes and a very low lifetime, but the > lowest lifetime allowed according to RFC4862 is two hours (ironically > changed recently to address a possible DoS...) Ok, I did some tests and both Linux and Windows Vista will actually honor a AdvValidLifetime and AdvPreferredLifetime of zero. So now I just have to write a program that counteracts bad RAs and everything should be fine. Thanks for the other suggestions in this thread, but if we could afford to upgrade to a routed network (with one VLAN per customer or what have you) we would. :) Regards, -- G?ran Weinholt, Network Administrator, Chalmers Studentbost?der From tjc at ecs.soton.ac.uk Tue Sep 9 12:53:51 2008 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue Sep 9 12:54:07 2008 Subject: Running IPv6 on a large L2 network In-Reply-To: References: <48BFF7A7.2040007@spaghetti.zurich.ibm.com> Message-ID: <20080909105351.GF30756@login.ecs.soton.ac.uk> On Tue, Sep 09, 2008 at 12:43:04PM +0200, G?ran Weinholt wrote: > weinholt@csbnet.se (G?ran Weinholt) writes: > > In the scenario I posted it doesn't matter if I disconnect the user > > that sent the RA, the network will still be broken for other hosts > > because of the bogus on-link route. To remove the route I might send > > my own RA with the announced prefixes and a very low lifetime, but the > > lowest lifetime allowed according to RFC4862 is two hours (ironically > > changed recently to address a possible DoS...) > > Ok, I did some tests and both Linux and Windows Vista will actually > honor a AdvValidLifetime and AdvPreferredLifetime of zero. So now I > just have to write a program that counteracts bad RAs and everything > should be fine. > > Thanks for the other suggestions in this thread, but if we could > afford to upgrade to a routed network (with one VLAN per customer or > what have you) we would. :) I'm about to do a revision of this draft: http://tools.ietf.org/id/draft-chown-v6ops-rogue-ra-01.txt so any feedback is timely. We also have a modified rafixd that I'll see if we can put up somewhere for people to fetch/use if they wish. -- Tim From tjc at ecs.soton.ac.uk Tue Sep 9 13:47:24 2008 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue Sep 9 13:47:40 2008 Subject: Running IPv6 on a large L2 network In-Reply-To: References: <48BFF7A7.2040007@spaghetti.zurich.ibm.com> Message-ID: <20080909114724.GJ30756@login.ecs.soton.ac.uk> On Tue, Sep 09, 2008 at 11:53:51AM +0100, Tim Chown wrote: > On Tue, Sep 09, 2008 at 12:43:04PM +0200, G?ran Weinholt wrote: > > weinholt@csbnet.se (G?ran Weinholt) writes: > > > In the scenario I posted it doesn't matter if I disconnect the user > > > that sent the RA, the network will still be broken for other hosts > > > because of the bogus on-link route. To remove the route I might send > > > my own RA with the announced prefixes and a very low lifetime, but the > > > lowest lifetime allowed according to RFC4862 is two hours (ironically > > > changed recently to address a possible DoS...) > > > > Ok, I did some tests and both Linux and Windows Vista will actually > > honor a AdvValidLifetime and AdvPreferredLifetime of zero. So now I > > just have to write a program that counteracts bad RAs and everything > > should be fine. > > > > Thanks for the other suggestions in this thread, but if we could > > afford to upgrade to a routed network (with one VLAN per customer or > > what have you) we would. :) > > I'm about to do a revision of this draft: > > http://tools.ietf.org/id/draft-chown-v6ops-rogue-ra-01.txt > > so any feedback is timely. > > We also have a modified rafixd that I'll see if we can put up somewhere > for people to fetch/use if they wish. The code is at http://ramond.sf.net, a revised version of rafixd tweaked by an MSc student here. -- Tim From dwhite at olp.net Tue Sep 9 17:36:33 2008 From: dwhite at olp.net (Dan White) Date: Tue Sep 9 17:36:44 2008 Subject: Running IPv6 on a large L2 network In-Reply-To: <20080909105351.GF30756@login.ecs.soton.ac.uk> References: <48BFF7A7.2040007@spaghetti.zurich.ibm.com> <20080909105351.GF30756@login.ecs.soton.ac.uk> Message-ID: <48C69801.9070906@olp.net> Tim Chown wrote: > > I'm about to do a revision of this draft: > > http://tools.ietf.org/id/draft-chown-v6ops-rogue-ra-01.txt > > so any feedback is timely. > > We also have a modified rafixd that I'll see if we can put up somewhere > for people to fetch/use if they wish. > > Tim, A scenario you may want to consider for section 3 is layer two separation. A common layer two technology in broadband networks is rfc1483 bridging, or RBE in cisco terminology: http://www.cisco.com/en/US/tech/tk175/tk817/tsd_technology_support_protocol_home.html which uses ATM, DSL or other protocols to create a point to point connection between the customer's CPE/modem back to a BRAS router: http://www.google.com/search?hl=en&q=bras+router&btnG=Search which will enforce IPv4 static assignment, or observe/proxy DHCPv4 requests to enforce DHCP lease times. It uses proxy arp an other 'tricks' to allow multiple customers to share the same IPv4 subnet while enforcing layer two separation. Some vendors have also implemented IPv6 functionality into this scenario. This link has some examples: http://www.cisco.com/en/US/docs/ios/12_4t/12_4t2/htrbeqos.html Another scenario along the same point-to-point strain is VLAN separation, where each customer's traffic gets tagged to a specific VLAN (or their DSL/ATM traffic gets converted to a VLAN) and hauled back to a router that performs the same type of RBE work on a VLAN interface (one VLAN interface per customer on the router). The advantage is that all traffic gets routed between customers, and no two customers see each other's RAs. The downside is that is requires manual configuration on the router for each customer. - Dan From ipv6ops at consolejunkie.net Sun Sep 14 10:14:57 2008 From: ipv6ops at consolejunkie.net (Leen Besselink) Date: Sun Sep 14 10:15:21 2008 Subject: Running IPv6 on a large L2 network In-Reply-To: <20080909105351.GF30756@login.ecs.soton.ac.uk> References: <48BFF7A7.2040007@spaghetti.zurich.ibm.com> <20080909105351.GF30756@login.ecs.soton.ac.uk> Message-ID: <20080914081453.GA4344@home.consolejunkie.net> On Tue, Sep 09, 2008 at 11:53:51AM +0100, Tim Chown wrote: > On Tue, Sep 09, 2008 at 12:43:04PM +0200, G?ran Weinholt wrote: > > weinholt@csbnet.se (G?ran Weinholt) writes: > > > In the scenario I posted it doesn't matter if I disconnect the user > > > that sent the RA, the network will still be broken for other hosts > > > because of the bogus on-link route. To remove the route I might send > > > my own RA with the announced prefixes and a very low lifetime, but the > > > lowest lifetime allowed according to RFC4862 is two hours (ironically > > > changed recently to address a possible DoS...) > > > > Ok, I did some tests and both Linux and Windows Vista will actually > > honor a AdvValidLifetime and AdvPreferredLifetime of zero. So now I > > just have to write a program that counteracts bad RAs and everything > > should be fine. > > > > Thanks for the other suggestions in this thread, but if we could > > afford to upgrade to a routed network (with one VLAN per customer or > > what have you) we would. :) > > I'm about to do a revision of this draft: > > http://tools.ietf.org/id/draft-chown-v6ops-rogue-ra-01.txt > > so any feedback is timely. > > We also have a modified rafixd that I'll see if we can put up somewhere > for people to fetch/use if they wish. > I sometimes read this list when I have time. And that started me thinking and then usually things go bad. So tell me if I'm stupid. What if we, the kind of early adaptors of IPv6 compiled a list of 'possible bad packets' and send it to the switch vendors so they can add a filter for them. I really hate workarounds and yes, I don't mind a workaround when I need it 'now, now, now'. But I do want to know the workaround can go away eventually. I know we'll be buying more switches eventually, updating firmware, removing old, etc. So why not make life easier ? I mean if you have an advanced switch it can already look at your IPv4-header and prioritize based on TCP/IP port-number and what not. Also I hear IPv6 has a 'fixed header' to make it easy for route vendors to route, but that also means it's easier for switch vendors to filter, right ? Is there anyone on this list who has good connections with there switch-vendors ? So, I suggest adding these on the list first: - RA, a per port setting (or for a very simple switch, just the uplink-port ?) - Type 0, Routing header (per port or possible all ports on a very simple switch) Any other idea's ? > -- > Tim > > > From trejrco at gmail.com Sun Sep 14 21:01:15 2008 From: trejrco at gmail.com (trejrco@gmail.com) Date: Sun Sep 14 21:00:56 2008 Subject: "RA Guard" In-Reply-To: <20080914100008.5771D17B6F@mail3.cluenet.de> References: <20080914100008.5771D17B6F@mail3.cluenet.de> Message-ID: <2109234774-1221418845-cardhu_decombobulator_blackberry.rim.net-2110559999-@bxe276.bisx.prod.on.blackberry> WRT - "RA, a per port setting (or for a very simple switch, just the uplink-port ?)" ... That is a work in progress, look up 'RA Guard'. :) Sent from my Verizon Wireless BlackBerry -----Original Message----- From: ipv6-ops-request@lists.cluenet.de Date: Sun, 14 Sep 2008 12:00:08 To: Subject: ipv6-ops Digest, Vol 42, Issue 5 Send ipv6-ops mailing list submissions to ipv6-ops@lists.cluenet.de To subscribe or unsubscribe via the World Wide Web, visit http://lists.cluenet.de/mailman/listinfo/ipv6-ops or, via email, send a message with subject or body 'help' to ipv6-ops-request@lists.cluenet.de You can reach the person managing the list at ipv6-ops-owner@lists.cluenet.de When replying, please edit your Subject line so it is more specific than "Re: Contents of ipv6-ops digest..." Today's Topics: 1. Re: Running IPv6 on a large L2 network (Leen Besselink) ---------------------------------------------------------------------- Message: 1 Date: Sun, 14 Sep 2008 10:14:57 +0200 From: Leen Besselink Subject: Re: Running IPv6 on a large L2 network To: ipv6-ops@lists.cluenet.de Message-ID: <20080914081453.GA4344@home.consolejunkie.net> Content-Type: text/plain; charset=us-ascii On Tue, Sep 09, 2008 at 11:53:51AM +0100, Tim Chown wrote: > On Tue, Sep 09, 2008 at 12:43:04PM +0200, G?ran Weinholt wrote: > > weinholt@csbnet.se (G?ran Weinholt) writes: > > > In the scenario I posted it doesn't matter if I disconnect the user > > > that sent the RA, the network will still be broken for other hosts > > > because of the bogus on-link route. To remove the route I might send > > > my own RA with the announced prefixes and a very low lifetime, but the > > > lowest lifetime allowed according to RFC4862 is two hours (ironically > > > changed recently to address a possible DoS...) > > > > Ok, I did some tests and both Linux and Windows Vista will actually > > honor a AdvValidLifetime and AdvPreferredLifetime of zero. So now I > > just have to write a program that counteracts bad RAs and everything > > should be fine. > > > > Thanks for the other suggestions in this thread, but if we could > > afford to upgrade to a routed network (with one VLAN per customer or > > what have you) we would. :) > > I'm about to do a revision of this draft: > > http://tools.ietf.org/id/draft-chown-v6ops-rogue-ra-01.txt > > so any feedback is timely. > > We also have a modified rafixd that I'll see if we can put up somewhere > for people to fetch/use if they wish. > I sometimes read this list when I have time. And that started me thinking and then usually things go bad. So tell me if I'm stupid. What if we, the kind of early adaptors of IPv6 compiled a list of 'possible bad packets' and send it to the switch vendors so they can add a filter for them. I really hate workarounds and yes, I don't mind a workaround when I need it 'now, now, now'. But I do want to know the workaround can go away eventually. I know we'll be buying more switches eventually, updating firmware, removing old, etc. So why not make life easier ? I mean if you have an advanced switch it can already look at your IPv4-header and prioritize based on TCP/IP port-number and what not. Also I hear IPv6 has a 'fixed header' to make it easy for route vendors to route, but that also means it's easier for switch vendors to filter, right ? Is there anyone on this list who has good connections with there switch-vendors ? So, I suggest adding these on the list first: - RA, a per port setting (or for a very simple switch, just the uplink-port ?) - Type 0, Routing header (per port or possible all ports on a very simple switch) Any other idea's ? > -- > Tim > > > ------------------------------ _______________________________________________ ipv6-ops mailing list ipv6-ops@lists.cluenet.de http://lists.cluenet.de/mailman/listinfo/ipv6-ops End of ipv6-ops Digest, Vol 42, Issue 5 *************************************** From mohacsi at niif.hu Sun Sep 14 22:30:31 2008 From: mohacsi at niif.hu (Mohacsi Janos) Date: Sun Sep 14 22:30:38 2008 Subject: Running IPv6 on a large L2 network In-Reply-To: <20080914081453.GA4344@home.consolejunkie.net> References: <48BFF7A7.2040007@spaghetti.zurich.ibm.com> <20080909105351.GF30756@login.ecs.soton.ac.uk> <20080914081453.GA4344@home.consolejunkie.net> Message-ID: On Sun, 14 Sep 2008, Leen Besselink wrote: > On Tue, Sep 09, 2008 at 11:53:51AM +0100, Tim Chown wrote: >> On Tue, Sep 09, 2008 at 12:43:04PM +0200, G?ran Weinholt wrote: >>> weinholt@csbnet.se (G?ran Weinholt) writes: >>>> In the scenario I posted it doesn't matter if I disconnect the user >>>> that sent the RA, the network will still be broken for other hosts >>>> because of the bogus on-link route. To remove the route I might send >>>> my own RA with the announced prefixes and a very low lifetime, but the >>>> lowest lifetime allowed according to RFC4862 is two hours (ironically >>>> changed recently to address a possible DoS...) >>> >>> Ok, I did some tests and both Linux and Windows Vista will actually >>> honor a AdvValidLifetime and AdvPreferredLifetime of zero. So now I >>> just have to write a program that counteracts bad RAs and everything >>> should be fine. >>> >>> Thanks for the other suggestions in this thread, but if we could >>> afford to upgrade to a routed network (with one VLAN per customer or >>> what have you) we would. :) >> >> I'm about to do a revision of this draft: >> >> http://tools.ietf.org/id/draft-chown-v6ops-rogue-ra-01.txt >> >> so any feedback is timely. >> >> We also have a modified rafixd that I'll see if we can put up somewhere >> for people to fetch/use if they wish. >> > > I sometimes read this list when I have time. And that started me thinking and then > usually things go bad. So tell me if I'm stupid. > > What if we, the kind of early adaptors of IPv6 compiled a list of 'possible bad packets' > and send it to the switch vendors so they can add a filter for them. > > I really hate workarounds and yes, I don't mind a workaround when I need it > 'now, now, now'. But I do want to know the workaround can go away eventually. > > I know we'll be buying more switches eventually, updating firmware, removing old, etc. > > So why not make life easier ? > > I mean if you have an advanced switch it can already look at your IPv4-header > and prioritize based on TCP/IP port-number and what not. > > Also I hear IPv6 has a 'fixed header' to make it easy for route vendors > to route, but that also means it's easier for switch vendors to filter, right ? > > Is there anyone on this list who has good connections with there switch-vendors ? > > So, I suggest adding these on the list first: > > - RA, a per port setting (or for a very simple switch, just the > uplink-port ?) proposal exists for more than a year now. Just vendor has to implement. http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ra-guard-01.txt 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 From ipv6ops at consolejunkie.net Mon Sep 15 08:56:10 2008 From: ipv6ops at consolejunkie.net (Leen Besselink) Date: Mon Sep 15 08:56:16 2008 Subject: Running IPv6 on a large L2 network In-Reply-To: References: <48BFF7A7.2040007@spaghetti.zurich.ibm.com> <20080909105351.GF30756@login.ecs.soton.ac.uk> <20080914081453.GA4344@home.consolejunkie.net> Message-ID: <20080915065609.GA4499@home.consolejunkie.net> On Sun, Sep 14, 2008 at 10:30:31PM +0200, Mohacsi Janos wrote: > proposal exists for more than a year now. Just vendor has to implement. > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ra-guard-01.txt > OK, thank you Janos and trejrco, that's completely clear. From dwcarder at wisc.edu Mon Sep 15 17:19:12 2008 From: dwcarder at wisc.edu (Dale W. Carder) Date: Mon Sep 15 17:19:21 2008 Subject: Running IPv6 on a large L2 network In-Reply-To: <20080914081453.GA4344@home.consolejunkie.net> References: <48BFF7A7.2040007@spaghetti.zurich.ibm.com> <20080909105351.GF30756@login.ecs.soton.ac.uk> <20080914081453.GA4344@home.consolejunkie.net> Message-ID: <7401F5E7-A5A1-41B6-957D-E173C72C6C28@wisc.edu> On Sep 14, 2008, at 3:14 AM, Leen Besselink wrote: > > So, I suggest adding these on the list first: > > - RA, a per port setting (or for a very simple switch, just the > uplink-port ?) > - Type 0, Routing header (per port or possible all ports on a very > simple switch) > > Any other idea's ? Drop incoming packets from edge ports with a source port of udp/547 to prevent rouge dhcpv6 servers. Dale From trejrco at gmail.com Tue Sep 16 14:56:55 2008 From: trejrco at gmail.com (TJ) Date: Tue Sep 16 14:57:25 2008 Subject: preventing malicious DHCPv6 stuff In-Reply-To: <20080916100006.905BF17F9C@mail3.cluenet.de> References: <20080916100006.905BF17F9C@mail3.cluenet.de> Message-ID: <001001c917fb$b94ab180$2be01480$@com> > >On Sep 14, 2008, at 3:14 AM, Leen Besselink wrote: >> >> So, I suggest adding these on the list first: >> >> - RA, a per port setting (or for a very simple switch, just the >> uplink-port ?) >> - Type 0, Routing header (per port or possible all ports on a very >> simple switch) >> >> Any other idea's ? > >Drop incoming packets from edge ports with a source port of udp/547 to >prevent rouge dhcpv6 servers. > >Dale And possibly "keep an eye" open for ff02::1:2 and ff05::1:3 traffic in unexpected places ... (I am hoping vendors produce (in Cisco-speak) "DHCPv6 Guard", similar in function to "DHCP Guard" for IPv4 ... would be a nice compliment to the "RA Guard" functionality they are working on. Anyone know if Cisco has that on their list ... ?) /TJ From iljitsch at muada.com Mon Sep 22 14:11:32 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon Sep 22 14:11:57 2008 Subject: Filtering ULA? In-Reply-To: References: Message-ID: <71EC5ACE-DFFB-4C18-88A1-D2FCE2DE7C81@muada.com> On 6 sep 2008, at 0:09, david.freedman@uk.clara.net wrote: > Is there any good reason why I shouldn't be filtering the ULA > (RFC4193) > range at the edge (FC00::/7) ? Are you talking about the prefix or the packets? Obviously everyone only allows prefixes from customers that are actually the right prefixes for those customers so the ULA stuff is rejected implicitly. Towards your own ISPs or peers you could reject the prefix because nobody should be advertising it. But if you have a default then you can send packets to those locations anyway... As for the packets: what if someone generates an ICMP too big message with a ULA source address? That could happen. It would be really bad if people filtered out those packets because that creates PMTUD black holes. From david.freedman at uk.clara.net Mon Sep 22 18:08:18 2008 From: david.freedman at uk.clara.net (David Freedman) Date: Mon Sep 22 17:53:42 2008 Subject: Filtering ULA? In-Reply-To: <71EC5ACE-DFFB-4C18-88A1-D2FCE2DE7C81@muada.com> References: <71EC5ACE-DFFB-4C18-88A1-D2FCE2DE7C81@muada.com> Message-ID: <48D7C2F2.70201@uk.clara.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > As for the packets: what if someone generates an ICMP too big message > with a ULA source address? That could happen. It would be really bad if > people filtered out those packets because that creates PMTUD black holes. I was talking about the packets. Yes, its possible to receive a multitude of signals sourced from ULA addresses, I find the terminology slightly warped when talking about ICMP messages from non "internet" sources (The "I" in ICMP being the point here) , but accept that, currently with IPv4 people do indeed send messages from unrouted space. I suppose I could allow ICMP from ULA as part of my ICMP policy (rate limited etc..) which would be a good compromise. Dave. - -- David Freedman Group Network Engineering Claranet Limited http://www.clara.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI18LxtFWeqpgEZrIRAuDqAKC9wnvVMb+jATASkVJOD7fKP+qyGwCguUN9 LDcpKvGXUVTcspWyYEwCwLc= =j/bT -----END PGP SIGNATURE----- From dr at cluenet.de Mon Sep 22 21:33:19 2008 From: dr at cluenet.de (Daniel Roesen) Date: Mon Sep 22 21:33:21 2008 Subject: List moving to new server Message-ID: <20080922193319.GA26408@srv01.cluenet.de> Hi, within the next few hours, I'm going to move the list to a new server (which has IPv6 connectivity *g*). I will announce completion later. Best regards, Daniel (list operator) -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From dr at cluenet.de Mon Sep 22 22:28:34 2008 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 22 Sep 2008 22:28:34 +0200 Subject: List moving to new server In-Reply-To: <20080922193319.GA26408@srv01.cluenet.de> References: <20080922193319.GA26408@srv01.cluenet.de> Message-ID: <20080922202834.GA28072@srv01.cluenet.de> On Mon, Sep 22, 2008 at 09:33:19PM +0200, Daniel Roesen wrote: > within the next few hours, I'm going to move the list to a new server This is (hopefully) completed now. The folks who tried to answer to my posts while I was in mid of moving (hi Pekka), retry. :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From david.freedman at uk.clara.net Mon Sep 22 22:30:26 2008 From: david.freedman at uk.clara.net (David Freedman) Date: Mon, 22 Sep 2008 21:30:26 +0100 Subject: FW: Filtering ULA? References: <71EC5ACE-DFFB-4C18-88A1-D2FCE2DE7C81@muada.com> Message-ID: --> going slightly OT here so please excuse... Well, this means extra annoyance for me because I use loose uRPF at the edge (so I can drop RFC1918 sourced traffic), none of my hardware supports any bypass acls (GSR Engine >2) so I either have to turn it off and revert to plain old ACLs (and lose my ability to do source based blackholing) or leave it on and not worry about the edge case people sending ICMP from unrouted address space. Its about time ICMP had an overhaul, this is silly, what would happen If I sent TOOBIG messages from random sources at the same time as a TCP handshake to people, could I cause them to reduce their MSS to the point where the connection performed badly? What happened if I did this in the reverse direction i.e to a popular content site which used PMTUd to all its clients ? Could I cause it to perform badly to everybody? And what about unreachable messages? no checking on those , I understand some TCP stacks on seeing these will drop the connection (to prevent hanging) and return EHOSTUNREACH/ENETUNREACH to the app, what happens if I spray these about referencing sources such as popular sites, will these stacks drop their connections (if only during handshake?) According to RFC1122: A Destination Unreachable message that is received MUST be reported to the transport layer. The transport layer SHOULD use the information appropriately; for example, see Sections 4.1.3.3, 4.2.3.9, and 4.2.4 below. A transport protocol that has its own mechanism for notifying the sender that a port is unreachable (e.g., TCP, which sends RST segments) MUST nevertheless accept an ICMP Port Unreachable for the same purpose. So its great securing TCP using sequence numbers, but the statelessness of ICMP makes for an attack vector, no? Dave. Pointers anybody? ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net -----Original Message----- From: Pekka Savola [mailto:pekkas at netcore.fi] Sent: Mon 9/22/2008 21:00 To: Iljitsch van Beijnum Cc: David Freedman; ipv6-ops at lists.cluenet.de Subject: Re: Filtering ULA? On Mon, 22 Sep 2008, Iljitsch van Beijnum wrote: > As for the packets: what if someone generates an ICMP too big message with a > ULA source address? That could happen. It would be really bad if people > filtered out those packets because that creates PMTUD black holes. Sometimes folks (usually from a network X using RFC1918 space internally) start complaining about network Y breaking PMTUD because they filter RFC1918 or some other bogus addresses on the border. As if network X had some $DEITY given right to break connectivity by exposing RFC1918 addresses to the outside and expecting the others to special-case around their brokenness. If it isn't routed, it's bogus and should be dropped. If you expose unroutable address space to outside, don't make it others' fault if it causes breakage. The same applies to ULA space IMHO. (And that's what the spec says as well.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20080922/76764af0/attachment.html From pekkas at netcore.fi Mon Sep 22 22:31:39 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 22 Sep 2008 23:31:39 +0300 (EEST) Subject: Filtering ULA? Message-ID: (re-send due to list change) On Mon, 22 Sep 2008, Iljitsch van Beijnum wrote: > As for the packets: what if someone generates an ICMP too big message with a > ULA source address? That could happen. It would be really bad if people > filtered out those packets because that creates PMTUD black holes. Sometimes folks (usually from a network X using RFC1918 space internally) start complaining about network Y breaking PMTUD because they filter RFC1918 or some other bogus addresses on the border. As if network X had some $DEITY given right to break connectivity by exposing RFC1918 addresses to the outside and expecting the others to special-case around their brokenness. If it isn't routed, it's bogus and should be dropped. If you expose unroutable address space to outside, don't make it others' fault if it causes breakage. The same applies to ULA space IMHO. (And that's what the spec says as well.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From pekkas at netcore.fi Mon Sep 22 22:38:13 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 22 Sep 2008 23:38:13 +0300 (EEST) Subject: Filtering ULA? In-Reply-To: References: <71EC5ACE-DFFB-4C18-88A1-D2FCE2DE7C81@muada.com> Message-ID: On Mon, 22 Sep 2008, Iljitsch van Beijnum wrote: >> If it isn't routed, it's bogus and should be dropped. If you expose >> unroutable address space to outside, don't make it others' fault if it >> causes breakage. > > Well, then what are people who use ULA addressing for some of their routers > internally supposed to do? There is no RFC that says this is not allowed and > also no RFC that borrows a non-ULA address from another interface (like with > link local) so either write those RFCs, don't use PMTUD or expect problems at > your end. First of all, you should really figure out if ULA is such a great idea in the first place. But if you use it (e.g. in SOHO or similar "sometimes disconnected" case) -- don't decrease MTU in your internal network, so you'll never have to send ICMP Packet Too Big's to the outside. No problem then.. David, yes, the source address in ICMP PMTUD messages is irrelevant. The attack you mention is possible. It's discussed in detail in http://tools.ietf.org/html/draft-ietf-tcpm-icmp-attacks-03 Section 7. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From tjc at ecs.soton.ac.uk Tue Sep 23 11:40:20 2008 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 23 Sep 2008 10:40:20 +0100 Subject: List moving to new server In-Reply-To: References: <20080922193319.GA26408@srv01.cluenet.de> Message-ID: <20080923094020.GC2866@login.ecs.soton.ac.uk> On Mon, Sep 22, 2008 at 10:28:34PM +0200, Daniel Roesen wrote: > On Mon, Sep 22, 2008 at 09:33:19PM +0200, Daniel Roesen wrote: > > within the next few hours, I'm going to move the list to a new server > > This is (hopefully) completed now. > > The folks who tried to answer to my posts while I was in mid of moving > (hi Pekka), retry. :-) Looks to be working just fine :) Received: from mail1.cluenet.de (mail1.cluenet.de [2001:1440:201:101::5]) by cormorant.ecs.soton.ac.uk (cormorant.ecs.soton.ac.uk [2001:630:d0:f110::25c]) id k8LLSr0309224911Nn ret-id none; Mon, 22 Sep 2008 21:29:05 +0100 Received: from srv03.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by mail1.cluenet.de (Postfix) with ESMTP id CD56910810E for ; Mon, 22 Sep 2008 22:28:35 +0200 (CEST) Cheers, -- Tim From steve at ibctech.ca Tue Sep 23 15:51:11 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 23 Sep 2008 09:51:11 -0400 Subject: List moving to new server In-Reply-To: <20080923094020.GC2866@login.ecs.soton.ac.uk> References: <20080922193319.GA26408@srv01.cluenet.de> <20080923094020.GC2866@login.ecs.soton.ac.uk> Message-ID: <48D8F44F.7020308@ibctech.ca> Tim Chown wrote: > On Mon, Sep 22, 2008 at 10:28:34PM +0200, Daniel Roesen wrote: >> On Mon, Sep 22, 2008 at 09:33:19PM +0200, Daniel Roesen wrote: >>> within the next few hours, I'm going to move the list to a new server >> This is (hopefully) completed now. >> >> The folks who tried to answer to my posts while I was in mid of moving >> (hi Pekka), retry. :-) > > Looks to be working just fine :) I concur: Received: from mail1.cluenet.de (HELO mail1.cluenet.de) (2001:1440:201:101::5) by 2607:f118::b6 with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Sep 2008 09:41:09 -0000 Steve From gert at space.net Sat Sep 27 09:22:20 2008 From: gert at space.net (Gert Doering) Date: Sat, 27 Sep 2008 09:22:20 +0200 Subject: List moving to new server In-Reply-To: <20080922202834.GA28072@srv01.cluenet.de> References: <20080922193319.GA26408@srv01.cluenet.de> <20080922202834.GA28072@srv01.cluenet.de> Message-ID: <20080927072220.GN32832@Space.Net> Hi, On Mon, Sep 22, 2008 at 10:28:34PM +0200, Daniel Roesen wrote: > On Mon, Sep 22, 2008 at 09:33:19PM +0200, Daniel Roesen wrote: > > within the next few hours, I'm going to move the list to a new server > This is (hopefully) completed now. $ telnet mail1.cluenet.de 25 Trying 2001:1440:201:101::5... Connected to mail1.cluenet.de. Escape character is '^]'. 220 mail1.cluenet.de ESMTP Postfix congratulations! (Yes, I know. We're still doing IPv4-only mail here. Waiting for the promised Ironport IPv6 support...) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From arnold at nipper.de Sat Sep 27 10:21:16 2008 From: arnold at nipper.de (Arnold Nipper) Date: Sat, 27 Sep 2008 10:21:16 +0200 Subject: List moving to new server In-Reply-To: <20080927072220.GN32832@Space.Net> References: <20080922193319.GA26408@srv01.cluenet.de> <20080922202834.GA28072@srv01.cluenet.de> <20080927072220.GN32832@Space.Net> Message-ID: <48DDECFC.1000903@nipper.de> On 27.09.2008 09:22 Gert Doering wrote > (Yes, I know. We're still doing IPv4-only mail here. Waiting for > the promised Ironport IPv6 support...) > When will this happen? Same for CP ... Best regards, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold at nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20080927/d71e83ee/attachment.bin From gert at space.net Sat Sep 27 10:49:21 2008 From: gert at space.net (Gert Doering) Date: Sat, 27 Sep 2008 10:49:21 +0200 Subject: List moving to new server In-Reply-To: <48DDECFC.1000903@nipper.de> References: <20080922193319.GA26408@srv01.cluenet.de> <20080922202834.GA28072@srv01.cluenet.de> <20080927072220.GN32832@Space.Net> <48DDECFC.1000903@nipper.de> Message-ID: <20080927084921.GU32832@Space.Net> Hi, On Sat, Sep 27, 2008 at 10:21:16AM +0200, Arnold Nipper wrote: > On 27.09.2008 09:22 Gert Doering wrote > > > (Yes, I know. We're still doing IPv4-only mail here. Waiting for > > the promised Ironport IPv6 support...) > When will this happen? Same for CP ... Last thing we heard is "first (internal) beta will be available at end of Q2", and I *think* they were talking about "Q2 2008"... I haven't pressed the issue, but since we're nearing the end of Q3, I've asked my colleagues (who maintain the relationship with Ironport) to re-open the case and start nagging... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20080927/ee78ddbe/attachment.bin