MinutesRouting SIGWednesday 23 February 2005, Kyoto International Conference HallMeeting commenced: 2:00 pm Chair: Philip Smith The Chair introduced the session and explained the agenda. Contents
There were no open action items. Brian Skeen, Boeing The presenter gave an overview of Boeing’s Internet access services, including the limitations when designing system architecture for aircraft. The presenter noted that the current standard for network mobility relies on host mobility rather than network connectivity, which is not appropriate for mobile aircraft networks. The IETF NEMO Working Group has been addressing this problem, but only in relation to IPv6 networks. The presentation explained some of the typical challenges for mobile aircraft networks. For example, a typical flight from Asia to Europe will access three different ground stations. This results in a need for seamless handoff between transponders and ground stations. The presenter noted there was an issue of latency in mobile aircraft networks of up to around three seconds. The presenter explained that when a plane is within a particular region, it is dynamically homed to a gateway within that region. The plane's route is advertised in that region through one AS. When it moves out of that region, that region's AS stops advertising the route, and the new region's AS starts advertising it. The presenter noted that Boeing advertises /24 routes, but is aware of the problem of growing number of routes in the global table. It was noted that, to date, no one has filtered Boeing's /24s but that an aggregate route is also advertised in case the more specific routes are filtered. Prefix churn has not been a problem because the route changes only happen a few times a day. The presentation included a demonstration of real routes announced in November 2004. The presenter noted that the data showed that route flapping and dampening did not seem to be an issue. Questions and discussion Action items
The presentation explained the reasons for needing secure BGP routing. It was noted that while BGP is a critical part of the Internet, it is also vulnerable to human error. In addition, BGP vulnerabilities could be exploited by spammers and hackers to wiretap traffic or degrade service through a DoS attack on a router. The presenter noted that it BGP vulnerabilities can be used to masquerade as DNS root server. The presenter gave an overview on how BGP updates work and how, if any of the assumptions are broken, major problems can arise. It was noted that security for BGP needed to be appropriate for the way BGP currently works and should work on a system of least privilege. The presenter noted that there should be a "fire breaks" approach so any one network’s security errors cannot affect the entire Internet. The presentation explained that there are two major issues for BGP security: 1) improving current implementations, and 2) changing architecture of routing. The speaker summarised the key aims of secure BGP: it must be able to detect authorised and unauthorised routes, and verify ASes and prefix holders. No date for implementation for S-BGP has been put forward, but the implementation will be incremental. The presenter noted that there are currently two activities in the IETF related to S-BGP. In the routing area, there is one document in the RFC editor queue on threats to routing and another three documents on analysis and requirements for routing security. In the PKIX Working Group, there is discussion on X.509 extensions for IP addresses and AS numbers, which should provide a cornerstone in the architecture to help prevent misconfiguration in the future. Questions and discussion Action items
This presentation was an elaboration on more technical aspects involved in implementing S-BGP. The speaker noted that S-BGP is an architectural approach to securing BGP. It is an extension of BGP and has an infrastructure component. S-BGP uses IPsec to provide point-to-point security between routers, which the speaker noted was a security improvement over MD5 checksums currently in use today. The speaker preferred the concept of a hierarchical IANA to RIR to ISP model for Certificate Authorities issuing X.509 certificates for ASNs and address prefixes. The speaker also recognised that historical allocations would add a little complexity to the certificate hierarchy. However, AS numbers would be more straightforward since they are not hierarchical. A key difference between tradition PKI use and its potential use in S-BGP is that S-BGP will not be using certificates to identify the organisation holding the certificate, but rather will be using the PKI format to bind a prefix to an entity that has a private key. The corresponding public key is then used to authorise - not identify - organisations. The presented noted that in the route verification model of PKI, it is not the routers that verify the certificates. Instead, people will do that manually and then pass on the answers to the routers. The speaker explained the importance of route attestations, where the next AS number is put into the path of a BGP update announcement before it to that next AS number. This ensures that the route is passed to the right destination. The presenter explained that PKI repositories associated with S-BGP would need to store all certificates, certificate revocation lists, and address attestation lists. There would be a need to have a number of such repositories for robustness, but not so many that coordination between repositories becomes difficult. Network operators would visit these repositories to upload and download information. Operators may need to do this once a day, so the presenter noted that there was not a need for high availability in the way demanded by root server operations. The speaker noted that are still residual vulnerabilities in S-BGP due to BGP itself. For example, no sequence numbering available so it cannot be obvious that updates have arrived out of sequence. The presenter finished the presentation by explaining that S-BGP is possible to implement now. In fact, the speaker has already implemented a small-scale model of S-BGP. Most current routers could handle the digital signature processing needed but may not have the memory to cope with signature storage. Questions and discussion Action items [Break 3:40 - 4:00pm] Tomoya Yoshida, OCN Presentation [pdf] The presentation outlined the various routing protocols and backbone topology for the OCN Economy Services used since 1996. The speaker explained that redundancy has been built into the topology to ensure connectivity; previously, if the Osaka PoP had become unavailable, it would have caused major problems. The presenter noted difficulties in using both Cisco and Juniper routers within the network. For example, Cisco’s router count of one route flap is registered as two flaps in Juniper routers, since Juniper counts both the withdrawal and re-advertisement of the route. The presenter explained how the network had dealt with route hijacks experienced in the past. As soon as OCN notices a route hijack, OCN announces a more specific route to the Internet, then contacts their upstreams to stop the hijacked route. The speaker explained that route security such as S-BGP or IRR would help to prevent future route hijacking incidences. Questions and discussion Action items Tomoya Yoshida, OCN Presentation [pdf] The presentation outlined the RouteViews project and its development. RouteViews consists of eight routers that collect realtime information about BGP sessions. The speaker explained that RouteViews is a repository of historical routing data back to 1997, which began as an operational tool, but is now also used for research. The speaker explained how the use of a zebra software router for RouteViews2 allowed better data collection methods and allowed updates to be logged as they occurred. This allowed updates to be available to RouteViews users almost immediately. The presenter noted that as high-resolution data became more available, two problems emerged: 1) MRT has a one second resolution, and 2) some data events seem to be multihop BGP sessions rather than the BGP speakers themselves. There is currently an effort underway to put RouteViews directly on IX fabrics. Since May 2003, IPv6 routing information has been collected via RouteViews6. Questions and discussion Action items
The presenter noted that what he was about to show was an application of the RouteViews data. The presented displayed graphs demonstrating how it was possible to see the effects of the Internet boom in 2000 and the subsequent Internet bust in the growth of the Internet routing table. About a quarter of the address space in IPv4 is currently being advertised in BGP. Since 2003, more rollouts of address space have become apparent. Since mid 2004, there had been less flapping of /8s on the global routing table. However, the speaker noted that there is no evidence of any better or worse aggregation practices. The speaker reported that during the Internet boom, the number of ASes changed from 3000 systems up to 12,000 systems. After the Internet crash, the growth of ASes became more linear. Currently, there are about 18000 ASes in use. The speaker suggested that this is a sign that BGP is becoming more connected. The speaker demonstrated how the routing table would drop from a current total of 160,000 routes to 40,000 routes if networks stopped routing more specific routes and prepending. The speaker noted that in the IPv6 routing table, in total about a /17 is currently being routed. This consists of the routes of around 500 networks. Of networks using IPv6, only 11 networks are using IPv6 exclusively. The speaker played the latest version of the BGP movie. The speaker commented that the BGP data showed that ASNs appear to have about a three-year life. After that time, networks seem to stop using that ASN and starting announcing a new ASN. Questions and discussion Action items Randy Bush, IIJ Presentation [pdf] The speaker noted that the research on anycast was a result of the fact that it was general operational advice not to use anycast, but that there appeared to have been many cases where anycast seems to work. To test anycast performance, an experiment was conducted to see which instance of an anycast root server would reply to requests (using both UDP and TCP). The presenter explained that the experiment was not about testing the reliability of root servers but was about testing BGP and iBGP routing behaviour. The speaker explained that the result of the experiments had only just begun to be analysed and should not be considered to be complete. The speaker noted that the effects observed from the experiment were probably due to forces such as inter-ISP EBGP and IBGP. The speaker reported that during test queries to root server I, many different anycast instances of the root server were seen during the experiment. The speaker noted that K root server gets about 70 switches within the 10 seconds of the last switch. The speaker reported that the experiment also measured the drops when probing the root servers (that is, when no reply was received). He noted that drops appeared to be random. This led the speaker to suggest that the issue seems to be more about an AS’s routing rather than about root server stability. However, he noted that the cause of a problem would make no difference to the users. The presenter suggested that intra-AS anycast may be more stable than inter-AS anycast, but could not say this was the case conclusively. Questions and discussion Action items Randy Bush, IIJ Presentation [pdf] The presentation gave an overview of why BGP noise is not a good predictor of bad packet delivery. The speaker suggested that BGP announcements may actually be part of the cure and not the problem itself. In the experiment described in the presentation, there was an attempt to measure the relationship between BGP noise and bad packets. The experiment used RouteViews data from the time around large Internet events like Code Red, Nimda, and Slammer. The speaker noted that there was no correlation between packet delivery and BGP updates during Code Red and Nimda episodes. With Slammer, however, packets were delayed but not lost. The speaker suggested the next step needed to analyse the effect of BGP noise is to measure performance directly through factors such as jitter and delay. Questions and discussion Action items The Chair thanked the presenters. Meeting closed: 12:25 pm Minuted by: Sam Dickinson Open action items
|
