Current Meeting Report

2.4.2 Inter-Domain Routing (idr)

NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date. Last Modified: 29-Jan-02
Susan Hares <>
Y Rekhter <>
Routing Area Director(s):
Randy Bush <>
Bill Fenner <>
Routing Area Advisor:
Bill Fenner <>
Technical Advisor(s):
Jon Saperia <>
Ran Atkinson <>
Mailing Lists:
To Subscribe:
In Body: subscribe idr-post
Description of Working Group:
Jon Saperia, one of the Technical Advisors, has the task to advise on technical matters related to all the MIB work in this WG.

Ran Atkinson, the other Technical Advisors, has the task to advise on technical matters related to security work in this WG.

The Inter-Domain Routing Working Group is chartered to standardize and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC 1771] capable of supporting policy based routing for TCP/IP internets. The objective is to promote the use of BGP-4 to support IP version 4 and IP version 6. The working group will continue to work on improving the scalability of BGP.

The current tasks of the WG include:

- Revise and clarify the base BGP4 document (RFC 1771). Note that RFC 1771 no longer documents existing practice and one goal of the update is document existing practice. Determine whether the document can be advanced as full Standard or needs to recycle at Proposed or Draft Standard.

- Advance RFC 2842, BGP Capability Advertisement, to Draft Standard.

- Review and Evaluate Existing RFCs on AS Confederations and Route Reflection. If changes are needed, create and advance revisions.

- Review RFC 2385 (Protection of BGP via TCP MD5 signature) to see if any changes need to be made based on current Internet practice or based on the changes to the current bgp draft. If changes are needed, create an revision. Issue the WG Last Call on advancing the document to Draft Standard.

- The existing BGP MIBs (RFC 1657) are not current with regards to BGP4. Produce a revised MIB that matches revised BGP4 document and move RFC 1657 to Historic.

- Produce MIBS for AS Confederations, Route Reflection, and Communities.

- Review and evaluate Multiprotocol BGP (RFC 2858) for advancement as Draft Standard, develop MIBs that support it.

- Complete work on an Extended Community Attribute. Develop MIB for BGP Extended Communities.

- Extend BGP to support a 4-byte AS number, develop plan for transitioning to usage of 4-byte AS numbers

- Progress along the IETF standards track a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of route filters that the peer would use to constrain/filter its outbound routing updates to the speaker. Currently defined in draft-ietf-idr-route-filter-03.txt.

- Progress along standards track an Outbound Router Filter (ORF) type for BGP, that can be used to perform aspath based route filtering. The ORF-type will support aspath based route filtering as well as regular expression based matching for address groups. Currently defined in draft-ietf-idr-aspath-orf-00.txt.

Tasks for this working group are limited to those listed above; new items to be added to the charter must be approved by the IESG.

Goals and Milestones:
Oct 01   Initial ID for MPBGP MIB
Nov 01   Submit to BGP Capability Advertisement to the IESG
Nov 01   Submit 4 BGP MIBs to IESG.
Dec 01   Submit Extended Communities draft to IESG.
Dec 01   Submit 4-byte AS ID to IESG.
Jan 02   Submit BGP4 document to IESG.
Jan 02   Initial Draft for RFC2858 (if needed)
Feb 02   BGP TCP MD5 signatures document to IESG.
Feb 02   Outbound Route Filter, Prefix and ASpath ORF draft to IESG.
Request For Comments:
RFC1267H A Border Gateway Protocol 3 (BGP-3)
RFC1269PSDefinitions of Managed Objects for the Border Gateway Protocol (Version 3)
RFC1265 BGP Protocol Analysis
RFC1266 Experience with the BGP Protocol
RFC1397PSDefault Route Advertisement In BGP2 And BGP3 Versions Of The Border Gateway Protocol
RFC1403PSBGP OSPF Interaction
RFC1657DSDefinitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2
RFC1745PSBGP4/IDRP for IP---OSPF Interaction
RFC1771DSA Border Gateway Protocol 4 (BGP-4)
RFC1774 BGP-4 Protocol Analysis
RFC1773 Experience with the BGP-4 protocol
RFC1863E A BGP/IDRP Route Server alternative to a full mesh routing
RFC1930 Guidelines for creation, selection, and registration of an Autonomous System (AS)
RFC1966E BGP Route Reflection An alternative to full mesh IBGP
RFC1998 An Application of the BGP Community Attribute in Multi-home Routing
RFC1997PSBGP Communities Attribute
RFC2270 Using a Dedicated AS for Sites Homed to a Single Provider
RFC2385PSProtection of BGP Sessions via the TCP MD5 Signature Option
RFC2439PSBGP Route Flap Damping
RFC2519 A Framework for Inter-Domain Route Aggregation
RFC2545PSUse of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing
RFC2796PSBGP Route Reflection An alternative to full mesh IBGP
RFC2842S Capabilities Advertisement with BGP-4
RFC2858PSMultiprotocol Extensions for BGP-4
RFC2918PSRoute Refresh Capability for BGP-4
RFC3065PSAutonomous System Confederations for BGP

Current Meeting Report

Minutes of the IDR meeting

1) Agenda bashing - nothing added
2) IDR document status attached [power point presentation]
3) BGP MIB v2

- 2547 MIB work will be added
- Discussion of the BGP-MIB v2 will go on the list

4) BGP Security

a) BGP Security analysis [presentation will be sent later]

BGP Security Protections (draft-murphy-bgp-protect-00.txt)
BGP Security Vulnerabilities Analysis (draft-murphy-bgp-vuln-00.txt
[see presentation

2) see Sandy's presentation for details on individual comments

Alex: Security analysis draft is outside of the working
charter. (Routing AD)
Ran: Security analysis is certainly within the charter for
a working group.

IDR working group mailing list will discuss the drafts and
whether work on this draft is within the IDR charter.
Alex (Routing AD) will also ask the IESG whether this
subject is part of our scope.

b) Securing BGPv4 using IPsec [draft-ward-bgp-ipsec-00.txt]

a) application/deployment doc and not protocol extension
b) Could be discussed in is:
a) Security policy working group
b) IPS (security policy)
c) IDR information RFC

1) section 2 - IKE is a "MUST" (an error)
2) No encryption is not an issue to the security

Alex Zinin (as Routing AD)states this is out of the charter for the
working group. We will need to revise the charter to include
this draft. The Routing ADs suggested that we await until
we have the Routing Security BOF to discuss requirements on the list.

c) TCP MD5 draft

Key Requirements for the TCP MD5 Signature Option

[No slides from Marcus, notes are rough]

a) Most credible attack is "key determination" is brute force

Took the current architecture of processors and software to
see what reasonable. The normal keys is a
12-24 byte key length with "ascii" (most common used).

Recommendation: key: use HEX structure
change keys every 90 days

b) IP Sec vs TCP MD5

Experience with public key infrastructures has
shown that a dynamic key infrastructure is difficult
to deploy.

If authentications is the only issue, use TCP MD5. If
encryption and data security is important, IPSEC is the choice.

Using IKE for dynamic Key management may be useful.
Profile for TCP MD5 re-keying for BGP would look different than

c) TCP MD5 versus HMAC MD5 - if start today use HMAC MD5.

4) BGP Integrity Check using IRR

Concerns with the draft:
a) Multi-origin AS are a normal situation and good,
so this portion of the draft should changed
b) IRR can allow multiple origin per prefix
c) Caching of the IRR Checks causes a problem
during start-up


BGP MIB Update
BGP Integrity Check using IRR