Minutes

Routing SIG

Wednesday 23 February 2005, Kyoto International Conference Hall

Meeting commenced: 2:00 pm

Chair: Philip Smith

The Chair introduced the session and explained the agenda.

Contents

  1. Review of previous open action items
  2. Global IP Network Mobility using BGP
  3. BGP security
  4. S-BGP overview
  5. Operational routing experience in NTT/OCN
  6. RouteViews project update
  7. Routing table status report and BGP movie update
  8. DNS anycast stability - early results
  9. A look at BGP storms and Internet health during the big worm attacks
  1. Review of previous open action items

  2. There were no open action items.

    Top

  3. Global IP Network Mobility using BGP

  4. Brian Skeen, Boeing

    Presentation [ppt | pdf]

    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

    • There was a question about the possible implications of moving a prefix from one AS to another. The presenter noted that they make changes to BGP policy as needed and will need to look more closely at what S-BGP will mean for this approach. There was a comment that S-BGP would work well for Boeing's use of multiple ASes. As address blocks have to be authorised for each AS, there would not be a problem switching from one AS to another.
      In reply to a query about whether the FAA see mobile plane networks as an entertainment/information issue rather than a flight operational issue, the presenter noted that the FAA considered it to be both issues because of network security concerns that are involved.
      It was questioned how Boeing performs the BGP handovers. The presenter explained that Boeing uses a route server with back end customisation. He noted that the handover is triggered by BGP itself, but that BGP itself does not extend to the plane but is used by the ground stations.

    Action items

    • None.

    Top

  5. BGP security

  6. Presentation [ppt | pdf]

    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

    • There was a question about the role RIRs have to play in the area of X.509 certificates. The speaker explained that RIRs could have one of two roles. First, RIRs could be delegated the responsibility to issue certificates to AS number and IP address holders. In this option, there would need to be a root for the certificate hierarchy, which may be filled by IANA. The second option would be to have the RIRs act as peers. In this option, the RIRs would need to coordinate among themselves to ensure there is no overlap in the certificates they issue. The presenter noted that this second option might map more accurately to the current resource management model.
    • There was a comment that in the certificate structure, there would be a problem when address space is allocated to one organisation but announced by a different organisation. It was suggested that ASNs could be better anchor points for the certification structure. The speaker responded that similar problems would occur with network acquisitions too.
    • It was noted that ISPs would also become Certificate Authorities when they hand out resources to customers, leading to a tree structure. It was suggested that another direction would be to have prefix holders authorising an AS to announce the prefix. The speaker notes that attribute certificates do not quite meet the needs for the concept of authorising ASNs to route particular prefixes.

    Action items

    • None.

    Top

  7. S-BGP overview

  8. Presentation [ppt | pdf]

    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

    • There was a question about the possibility of incremental deployment of S-PBGP since attestation would not be complete. The presented explained that it was possibly to deploy incrementally by forming small islands of S-BGP networks that would gradually connect to other S-BGP islands, increasing the level of protection to networks as the connections spread.

      It was confirmed that it would be possible to move into S-BGP by using address attestation as the first incremental step.

    Action items

    • None.

    [Break 3:40 - 4:00pm]

    Top

  9. Operational routing experience in NTT/OCN

  10. 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

    • There was a question about why the OCN network would announce more specific routes during a route hijacking incident rather than contact upstreams first. It was questioned if this meant that the upstreams were not responding fast enough. The speaker replied that there was no problem with the speed of the upstream responses.

    Action items

    • None.

    Top

  11. RouteViews project update

  12. 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

    • None.

    Action items

    • None.

    Top

  13. Routing table status report and BGP movie update

  14. Presentation [ppt | pdf]

    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

    • None.

    Action items

    • None.

    Top

  15. DNS anycast stability - early results

  16. 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

    • There was a comment from a K-root operator stressing that the speaker had noted that there really any evidence of the real source of such rapid changes between instances of anycast root server replies.
    • The speaker noted that if another similar experiment were run, it would look at unicast servers and note the drop rate.
    • It was noted that the instances with the most number of instabilities also have the most number of peers.
    • The speaker commented that one difficulty of the experiment was that it is not possibly to find information on all anycast instances of root servers.
    • It was explained that it was not possible to comment on any difference between UDP and TCP queries since that data had not yet been analysed.
    • There was a question about the outcomes of a time series analysis for the total number of probes? The speaker answered that this had not been performed yet.

    Action items

    • None.

    Top

  17. A look at BGP storms and Internet health during the big worm attacks

  18. 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

    • None.

    Action items

    • None.

The Chair thanked the presenters.

Meeting closed: 12:25 pm

Minuted by: Sam Dickinson

Top

Open action items

  • None.

Minutes | Routing SIG


Top of page
Programme | SIGs | Sponsorship | APNIC meetings | APRICOT 2005 | APNIC home
Last modified: | © 1999 - APNIC Pty. Ltd.
Contact us | Privacy statement