RIPE 60

• content to the Chair of the working group.
• format to webmaster@ripe.net.

RIPE Meeting: 60
Working Group: Routing
Status: Draft
Revision Number: 1

Date: 5 May 2010
Time: 14:00 - 15:30

Chair: Joao Damas
Minutes: Franz Schwarzinger (RIPE NCC)
Jabber: Bert Wijnen (RIPE NCC)

A. Administrative Matters

The minutes from the RIPE 59 Meeting were approved.

B. IPv6 Routing Recommendations

Rob Evans gave a presentation on IPv6 Routing Recommendations. The presentation is available at:
http://www.ripe.net/ripe/meetings/ripe-60/presentations/Evans-Agenda_and_IPv6_Routing_Recommendations.pdf

Marco Hogewoning (XS4All) stated that he likes the suggestion to mention the use of more-specific than /36. He would also like to maintain less-specific aggregates.

Rob Evans answered that there might be discrete islands of connectivity.

Marco Hogewoning replied that he understands the issue and that it is sensible in rare cases. However it is usually done just for traffic engineering. He points out that these are just suggestions to offer guidance.

Sander Steffan stated that he also likes the first option however he was unsure if "/32" or "4 bits" should be mentioned in the document.

Rob Evans replied that one purpose of the document was to act as a filter defense mechanism and mentioning bits would not serve this purpose.

Sander Steffan stated that he would like to see suggestions for people who want to de-aggregate. He also liked Marco Hogewoning's idea of aggregating where possible.

Rudiger Volk (Deutsche Telekom) stated that there should be strong wording to have the overall aggregate in the routing system. It should be expected that certain people will only accept that. He also stated that every organisation should work with their provider to make aggregation possible. He said that whatever prefix is announced should be registered with the precise matching route either in RPSL or with RKPI in the future.

Randy Bush asked about the first item suggesting more-specific /36s. He stated that the existing document says "no more specifics" which he specifically objected to on the mailing list. He requested to keep a separate document and modify the existing document to include those two bullet points.

Rob Evans replied that the existing document says to aggregate where possible. The option of de-aggregating is vague and based on more-specific /36s.

Randy Bush stated that he does not like this point. He said he likes to tell people to hand out /48s to end-sites and ask people to use this for multi-homing. There is no better scheme for multi-homing in IPv6 but people are still being blamed for it.

Rob Evans asked whether the recommendation should be to use PI or PA space for multi-homing.

Randy Bush suggested to use both.

Rudiger Volk stated that he has previously told off customers who would not be able to accept a full global routing table.

Randy Bush stated that his route is at 94% but has not crashed yet.

Marco Hogewoning responded to Randy Bush that having a recommendation for /48s might be okay, but recommends to aggregate if a person has more than one /48.

Randy Bush agreed on this point and stated that he wants strong recommendations for aggregation. However he also wanted to see a suggestion for filtering but it doesn't make sense to filter on something shorter than it is being suggested to use for multi-homers.

Rob Evans summed up that there are two viewpoints: Some people want a figure in the document. Some people want to have it taken out. He also stated that it is going to be hard to reach consensus.

Marco Hogewoning stated that there should be a figure in there, but can agree with Randy Bush that it can be /48.

Rudiger Volk stated that having a number the document that tells people should filter on that is unwise. Randy Bush's suggestion of using a /48 could work. He however questioned if suggesting a certain number of more specifics makes sense.

Martin Levy (Hurricane Electric) asked what people would have done in the IPv4 world. In reality market pressure dominated decisions back then and there was nothing written down. He also stated that it had nothing to do with any registry.

Rob Evans clarified that this is not a registry working group, but a working group of Internet operators.

Martin Levy repeated that at some point people will argue based on market pressure.

Rob Evans agreed and stated that one of the reasons for this document is to show what people in the operator community would like to see. He agreed that things will change over time.

Randy Bush stated that the /19 came from an IETF meeting in Denver.

Rudiger Volk stated that specific advice with the right wording is the way forward. He also stated that any more specifics should be specifically registered.

Rob Evans agreed. He summed up that he is happy with this outcome and is going to revise RIPE 399 along the lines that people suggested.

Rob Evans also asked for any objections. There were none.

C. Routing Security Follow-up - Discussion following on from the plenary presentation of ENISA's routing security survey.

Benno Overeinder (NLnet Labs) and Maarten Botterman (GNKS Consult) opened a discussion on Routing Security. The presentation is available at:
http://www.ripe.net/ripe/meetings/ripe-60/presentations/Benno_Overeinder-Towards_more_secure_routing_-_a_debate.pdf

Rudiger Volk stated that everybody has some responsibility for the core of the network working. Everybody should understand that it is fragile. Public perception has not yet been a big problem and most of the attacks were caused by "fat fingers". He also stated that it is important to get serious improvements before the public's perception changes since changing the public perception is essentially impossible. He also stated that it would be scary if the majority of the big players do not see any need for changes.

Randy Bush stated that the research is very biased since only 23 out of 30,000 ASs responded to the survey. He also clarified that "fat fingers" are not actual attacks, they are mistakes.

Maarten Botterman summed up that the statement Randy Bush made and mentioned RPKI as a possible solution.

Rudiger Volk stated that people should be doing a lot of things already. It should start with simple filtering and protecting systems sufficiently. The next level of routing security would require reliable, current and automatically processable information on resources on the Internet. He finally stated that adding cryptographic security to the routing pool is harder but should be seen as a final step requiring all the other levels beforehand.

Randy Bush referred to a paper written by Sharon Goldberg on defenses against certain attacks and the fact that prefix filtering is not perfect due to the weakness of the data set. He further mentioned that the weakness of the paper is the analysis based on an assumed topology. In reality, routing policies are much more complex and it is often difficult to know the actual intention of an operator.

Nick Hilliard agreed that there are gaps in routing security. RPKI and Secure BGP are all heading towards an increased difficulty and complexity that opens a whole new risk for operators. He asked if there has been any risk analysis of raised complexity vs. raised security.

Benno Overeinder stated that increased security can make the network more brittle. He asked for a proposed solution to this.

Nick Hilliard stated that the intent is to create the tools and make the options available rather than recommending everybody to use it. He stated that the biggest risk would be a split between people who do routing security well, people who do it badly and break things and people don't care. He stated that people should think about how the situation can be improved for the operators in order to avoid these problems in the future.

Geoff Huston compared routing security to email and DNS. He stated that the biggest question is if the information that has been injected in the network the same that is seen at the end. However, in routing the injected message always gets changed before it reaches the end. Therefore, routing security is much more complicated. He also stated that routing is a shared disease. People with good practices can be badly influenced by people with bad practices. He further said that people should be careful with what they give up in regards to certification hierarchy and revocation of certificates. Finally he states that people should think about which kind of routing security would work best for the whole community.

Jamie Stallwood mentioned that it is difficult getting large providers to adjust their filters. He further stated that when announcing a prefix the peering points should know that it came from them and he would like to see if each step along the path is signed by that Autonomous System.

Rudiger Volk answered to Nick Hilliard's question that risk analysis for a new model is certainly important. He further stated that the high complexity from the current system comes from the unreliable information. The good thing of RPKI is to have a globally well-defined system. He further answered to Geoff Huston that routing security is possible, even path verification, but he does not expect it to be implemented before his retirement. He finally stated that they should start doing something. Not doing anything will generate unpleasant headlines in the long run.

D. AS Topology Visibility

Randy Bush gave a presentation on AS Topology Visibility. The presentation is available at:
http://www.ripe.net/ripe/meetings/ripe-60/presentations/Bush-AS_Topology_Visibility_-_You_Can_t_Get_There_from_Here.pdf

Daniel Karrenberg asked how the data plane should be measured.

Randy Bush answered that TTM is an attempt at doing that.

Daniel Karrenberg replied that TTM was not designed for that.

Randy Bush replied that the reason RIS or RouteViews data is unsuitable for a large class of topology experiments is due to the high bias. He stated that the methodology cannot be changed since it is impossible to be successful. His presentation should be taken as a warning.

Daniel Karrenberg stated that one BGP feed is not the same as 100.

Randy Bush replied that he measured and it was.

Daniel Karrenberg said that he is not a believer of passive measurements. Active measurement probes should be put in as many places as possible.

Randy Bush replied that the data will still be highly biased since it is difficult to get probes at the edge and the core operator community cannot help with that.

Daniel Karrenberg asked if it would help to put probes closer to the edge.

Randy Bush replied that there are 30,000 pieces at the edge and it is growing quickly.

Steve Kent (BBN) said that the biggest question is: Which community do you want to serve? RIS and RouteViews have been designed for a certain thing where they do a good job.

Randy Bush agreed and states that they to a great job.

Steve Kent also agreed that researchers should be careful. It is important to look at whom we want to serve. He further stated that the RIPE NCC should provide data for the operator community rather than for PhD students who want to write a paper.

Daniel Karrenberg stated that this might be better discussed in the Data Measurement Working Group.

Randy Bush further talked about a paper at SIGCOMM. Students wanted to measure broadband usage patterns in Japan. Seven of the larger ISPs worked together and provided a lot of edge data to the students. He stated that this would be much more difficult in other parts of the world. He finally said that it is not impossible to do traffic measurements, but it is really hard.

E. A Dedicated RPSL Interface Identifier for Operational Testing

Vesna Manojlovic from the RIPE NCC gave a presentation on a dedicated RPSL interface identifier for operational testing. The presentation is available at:
http://www.ripe.net/ripe/meetings/ripe-60/presentations/Manojlovic-Pingable_address_for_operational_testing.pdf

Vesna asked how many attendees would find this proposal useful. About 20 hands were raised.

Vesna Manojlovic further asked how many attendees would actually use this functionality. Again about 20 hands were raised.

Daniel Karrenberg mentioned that for his personal server he has control over the inet-num object, however does not have control over the route object.

Randy Bush urged people who were raising their hands after Vesna Manojlovic's questions to follow up on their intent.

Nick Hilliard asked for a show of hands of people who would deliberately not use this database object. No hands were raised. He further added that the IRR toolset does not currently support this but he would add support shortly.

Joao Damas commented on Daniel Karrenberg's statement, pointing out that the inet-num object is unique to the RIPE database.

Ruediger Volk mentioned that it is on the track towards becoming an RPSL standard in a few years.

Joao Damas further said that an alteration of the inet-num object would need to be addressed differently to the route object. He proposed to take this discussion to the Database Working Group.

Marco Hogewoning responded to Daniel Karrenberg's statement about the inet-num object saying that it would be easier to mention the pingable targets on the aggregate route object rather than on the inet-num.

Daniel Karrenberg replied that his statement should be taken as anecdotal. In order to find these pingable targets would be to look at the shortest prefixes first and then look at the individual inet-num objects.

Randy Bush explained that at the last IETF conference there were problems with the IPv6 connectivity at the conference that turned out to be a PMTU tunneling issue. This issue triggered the idea for having pingable targets on the Internet that cab be easily identified using a central data repository. He further explained that it should be used only for debugging, not for computer science related measurements.

Joao Damas agreed with Randy Bush that it has operational value.

David Kessens agreed with Daniel Karrenberg that it might be a good idea to use the inet-num objects for storing this information. He further referred to a database that was used for the 6bone which was similar to a RIPE-style database. In this database they had an object that was a combined route and inet-num object. In that object they had a more generic attribute where people could add a ping, HTTP or any other application level target. He pointed out that an attribute like that would give a lot more flexibility. He suggested to allow it in both inet-num and route objects.

Daniel Karrenberg agreed with David Kessens.

Vesna Manojlovic added that the RIPE NCC published an article on IPv6 RIPENESS suggesting this feature. Soon people actually tried to add the new attribute even though it was not yet possible.

Marco Hogewoning added to David Kessens point that the attribute should not be too generic since DNS already does this.

An attendee asked if there is a specific reason for why the route object has been chosen instead of the aut-num object. He further suggested to make this option available for aut-num, route and maybe even inet-num objects.

Joao Damas responded that the author proposed it that way and Randy Bush earlier showed that routing policy within one AS might not be uniform.

The attendee repeated that it should just be optional in all 3 objects.

Randy Bush asked to further discuss this on the IETF mailing list.

Y. Mention Vince Fuller is around if any of the LISP Beta sites want to talk to him (or if anyone is interested in the current state of LISP).

There were no questions.

Z. A.O.B.

Joao Damas talked about a proposal to use the RPKI infrastructure to construct validated RIR data. This proposal was brought by Kurt Lindquist and Randy Bush. He further mentioned that this proposal has been taken over by implementations soon being available from some router vendors.

He then asked people to further comment on this topic. He also proposed to close this issue unless there is some support to further pursue it.

Rudiger Volk said that he would be happy to see the origin validation coming up in router implementations. He further said that he does not expect everybody to upgrade their routers quickly. There will be some value for those who will be moving slowly in order to get the RPSL implementation. He offered to help with the last small steps needed to make this possible. However he also added that the smaller parties could benefit from this and they should give their opinion as well.

Randy Bush asked Rudiger Volk if he still wants this feature.

Rudiger Bush replied that he indeed still wants it.

Randy Bush asked for any objections. There were none.

Joao Damas said that this will be taken to the mailing list.

Nick Hilliard added a point to the A.O.B. stating that the RPSL standard is decaying in terms of relevance to the current Internet world since it does not have good support for IPv6, internal routing, etc. He proposed to look into this issue as a working group. He asked to put a question about this on the mailing list to see if there is any interest for it.

Randy Bush replied that this topic should be discussed at the IETF.

Rudiger Volk added that the IETF does not do any implementations.

Joao Damas closed the session.