Securing Inter-Domain Routing
For those who have been following this activity, the good news is that the base documents on securing inter-domain routing, being developed in the RPSEC working group are now in their final stages.
The next step is to look at the issue of standardization of an inter-domain routing protocol that can incorporate these requirements. There have been a number of secure routing protocol proposals over the past few years and part of the work will be the challenging aspect of standardizing a protocol that can support security in the inter-domain routing environment. It’s likely that there will be a BOF on this topic at IETF-64. This promises to be an interesting area of IETF activity in the coming months.
Inter-Domain Routing
At IETF 63 there was a proposal to introduce a ‘Time To Live” or TTL for BGP updates. This is not the first proposal for a protocol mechanism to limit the scope of propagation of BGP updates, and no doubt will not be the last, but it does have the essential attributes of being simple in its definition and clear in its operation. Each AS decrements the TTL of an Update, and when the TTL value gets to zero the update is discarded. Given that about one half of the BGP routing table consists of more specific advertisements of existing aggregates, this method of localizing the propagation of more specific prefixes is certainly worth considering.
On another note, the revised specification for the BGP protocol proved to be a significant exercise taking some three years and 26 iterations of the draft document. The good news is that this work is now largely complete, and is currently in the publication process.
OSPF
Current work is on version 3 of this interior routing protocol. This includes aspects of support for Traffic Engineering as well as adding explicit support for various forms of mobility. There is an interesting area of trade-off here in terms of how much functionality is pushed into the routing protocol itself, and how much is taken up by the application environment.
ISIS
The Working Group is currently working on documenting a number of implementation practices and extensions. The bulk of this work is now coming to a conclusion and the next steps for ISIS appear to be on the agenda for the Routing Area.
MPLS
The current activity here includes the task of adding multicast to MPLS. No doubt one of these days we’ll see multicast become an accepted and integral part of the portfolio of IP services, but multicast provides a set of technical and business challenges that continue to make its ubiquitous deployment a challenging goal. However there is a lot of interest in multicast these days, and maybe we’ll make some progress in this. Also there is the continuing work in extending MPLS into inter-area support.
VPN Activity
Standardizing various aspects of the design of Virtual Private Networks continues to be an aspect of the IETF’s work. The original work on standardizing aspects of VPNs quickly split into two working groups, the Level2 and Level 3 VPN working groups, reflecting the two major approaches to VPN implementation. These working groups sit in the Internet Area of the IETF. The Routing Area now has a Level 1 VPN working group, looking at the aspects of providing a synthetic Layer 1 VPN between the customer’s edge devices.
Note: This article does not attempt to provide a complete summary of all IETF activities in this area. It reflects a personal perspective on some current highlights.