RIPE 65

Routing Working Group - RIPE 65
Thursday, 27 September 2013, 14:00-15:30
WG co-Chairs: Joao Damas, Rob Evans
Scribe: Anand Buddhdev

A. Welcome (5 mins)

Joao Damas, WG co-Chair, thanked the scribe, chat monitor and stenographer. He apologised for the delay in getting the RIPE 64 minutes to the mailing list and asked for a two-week period of comments on the mailing list before they get approved. He announced that the Route Flap Damping document has been moved to Last Call.

B. "BGP Security Best Practices" - Ivan Pepelnjak, NIL Data Communications

The presentation is available at:
https://ripe65.ripe.net/presentations/256-draft-jdurand-bgp-security-02-RIPE65-02.pdf

Leslie Carr, Wikimedia Foundation, asked if they talked to any Internet Exchanges to find out their opinions on any given AS re-announcing their space.

Gert Doering recommended that if you do URPF filtering, then you might want to have that prefix in your routing tables, and in that case, the best way to get it there is to have the IXP announcement.  He added that what Ivan presented was the caveats, but that the text is much longer and suggested that people read the full text.

Nick Hilliard, INEX, replied that a lot of other IXPs do the same sort of thing. They announce their address ranges from their own ASN and its carried by several transit providers and appears in the DFZ. He added that they understand they are at risk of DoS attacks and in that case they could just drop the announcement. He said it wasn't really a BGP issue, but a general IXP issue. He advised against exporting the IXP prefix into their IGP. It's bad if you have multiple connections into the IXP because a split in the infrastructure will cause a lot of damage and connectivity loss.  He suggested exporting it into the internal BGP mesh instead.

Mike Hughes, smashing.net, commented that inconsistent origin AS is bad because it breaks routing loop detection, causes people to deaggregate the IXP prefix so they advertise more specifics of the IXP prefix.

Nick Hilliard, in response to Mike, said that they are in the lucky position that their IXP prefixes actual is a /25 and even if we they move up to a /24, a lot of networks will simply not accept anything more than a /24 so even if somebody does reannounce a /24 it probably won't break it just due to the structure they have.

Max Tulyuk, AMS-IX, commented that he agreed with the previous three speakers and what he mentioned is explicitly written on the website.  He asked for the community support and encouraged people not to ignore it. He added that more communication is needed between him and the IXP communities.

Eric Vyncke, Cisco, commented that the op-sec Working Group has another draft which states that for IPv6 traffic on the infrastructure that links to an IXP it can use only link local, so you are forcing everyone to use a loop back. He asked if anyone had comments.

Ivan said they should take the conversation offline so he could learn more about this.

Rob Evans pointed out that the document currently advises against Route Flap Damping and suggested that the document might want to consider the working group's pending document that said Route Flap Damping could be useful.

C. "A Case Study of IPv6 /48 Filtering" - Emile Aben, RIPE NCC

The presentation is available at:
https://ripe65.ripe.net/presentations/277-ipv6-s48-2012-emileaben.pdf

Ruediger Volk, Deutsche Telekom Technik, asked whether the /48s out of PA space had exact matching route6 objects?

Emile replied that he didn't know but could easily check.

Emile asked for feedback from the audience.

Joao clarified that all the prefixes Emile mentioned have route6 objects, so the follow up question becomes: what's the reachability of prefixes that don't have a route6 object.

Martin Levy, Hurricane Electric, complemented Emile on the good work. He asked if people cared about the difference between PA versus PI at the backbone level. He said Hurricane Electric filters different.

Ruediger replied that they filter rigidly for DTAG and don't make a distinction between PA and PI.

Gert Doering said some people filter rigidly. If it's documented, accept it, otherwise, filter it.

D. Summary of the Open Source Routing BoF - Martin Winter, ISC / OpenSourceRouting.org

The presentation is available at:
https://ripe65.ripe.net/presentations/284-OS_Bof_Summary.pdf

Martin asked whether there should be a new Open Source Working Group in RIPE.

Jan Zorz asked him to send the outcomes of the BoFs to the RIPE Programme Committee.

Joao said that new working groups are formed at the plenary and suggested that there be one more BoF session to allow people to get a feel for it before a WG is formed. The presenters just want to present this as a suggestion on Friday at the plenary, with a view to form a WG at the next meeting.

Yannis Nikolopoulos, OTE SA, supported the idea of forming this WG, and asked when we might see IS-IS for IPv6 in both Quagga and BIRD.

Martin Winter replied that in Quagga IS-IS was broken for a long time, IS-IS for IPv4 is getting there, but IS-IS for IPv6 will be done after that.

Ondrej Sury said that for BIRD it is expected for the first quarter of next year, approximately.

E. Remotely Triggered Black Holes (with configuration examples) - Nick Hilliard, INEX

The presentation is available at:
https://ripe65.ripe.net/presentations/285-inex-ripe-routingwg-amsterdam-2012-09-27.pdf

Ronan Mullally, Prolexic Technologies, said he uses real-time blackholing and that IOS-XR 4.1.1 is not reliable. He said they've seen issues with leakage through the other side. He added that it was great technology but also a great rope to hang yourself with. He advised caution about what people put in for their source-based filtering, adding that if you just take source addresses as being legitimate, you'll find somebody will send the source address of a root nameserver or one of your own IXP peers.

Nick agreed and said that the document recommended that the blackholing prefixes are filtered.

Ronan Mullally commented that when you do source base filtering it affects everything downstream of your network rather than just the victim who is being attacked.

Nick agreed and commented that that is why you want to do single prefix only, because if you take out a /24 you might take out a bit of your own infrastructure or somebody else's thing. You want to do this as finely tuned as possible, with a hammer.

Sebastian Wiesinger, noris network AG, commented on Nick's statement about remote blackholing and unicast RPF, adding that on Juniper, if you configure a Juniper RPF in loose mode, it will act as if the route was installed on any other interface and won't work. He added that with Junos 12.1, you can configure a special handling for these discard routes but only there and on the MX and some of the T routers. He said it could be seen as a feature or a bug.

Merike Kaeo, Double Shot Security, said she was a huge fan of blackhole routing and encouraged people to test it in the lab first to avoid being the one doing the trigger routing. She wondered whether there was any practical use for this with IPv6. She wasn't aware of any large-scale DDoS attacks yet.

Nick said he hadn't had to use it for IPv6, and nobody in the audience said they had seen one either.

Blake Willis, L33 Networks, commented that few small companies implement flow spec. It's more the people that either give some money to Arbor or have some geeks in the back making nice machines that inject routes or use XBGP. He added that the more he thought about it though, he feels it's a good thing and complementary to flow spec in terms of what you do with it and who can realistically implement it without a large engineering department.

Nick agreed and said there are several technologies for dealing with this problem but encouraged people that haven't tried it to implement remotely triggered black hole systems on their networks.

Blake commented that it also implies less necessity of trust between the customer and the ISP versus flow spec where you can do crazy things where this is route and it's either there or not.

Nick replied that he didn't think it was a big issue because if you restrict your customer to blackholing their space, they can do whatever they want.

Blake said that with flow spec you can do all kinds of things like policy-based routing.

Andreas Polyrakis, GRNET, thanked Nick for the presentation. He said they have black routing without source addresses. He said he was in favour of stats services and thinks ISPs should add such things and buy them with automated mitigation tools or show where information was exchanged between customers and ISPs. He said there would be some challenges there if they could propagate even further. He said that RFC 5575 is an interesting alternative and has advantages of being flexible and exchanging information over a different NLRI, so it doesn't mess up your routing table. He said it also allows for more fine-grained filtering because it can filter based on ports. You also have the possibility to rate-limit the traffic. He added that RFC 5575 was written by Cisco, Juniper and other vendors and it doesn't support IPv6, so it has some drawbacks.

Blake suggested that if you're doing NAT64 you can do port-level filtering with this.

Nick questioned Blake's mental health.

F. "Using RIPEstat for Prefix Size Filtering" - Vasco Asturiano, RIPE NCC

The presentation is available at:
https://ripe65.ripe.net/presentations/238-RIPE65-Prefix-Size-Distribution-Vasco-Asturiano.pdf

There were no questions.

Y. Interaction with Other Working Groups

Z. AOB

Andrei Robachevsky, ISOC, asked for feedback on the ISOC Routing Security Survey.