Current Meeting Report
Slides


2.4.2 Inter-Domain Routing (idr)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 05-Dec-01
Chair(s):
Susan Hares <skh@merit.edu>
Y Rekhter <yakov@juniper.net>
Routing Area Director(s):
Randy Bush <randy@psg.com>
Bill Fenner <fenner@research.att.com>
Routing Area Advisor:
Bill Fenner <fenner@research.att.com>
Technical Advisor(s):
J Saperia <saperia@mediaone.net>
Mailing Lists:
General Discussion:idr@merit.edu
To Subscribe: idr-request@merit.edu
In Body: subscribe idr-post
Archive: ftp://ftp.merit.edu/mail.archives/idr
Description of Working Group:
The Technical Advisor has the task to advice on technical matters related to all the MIB 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.
Internet-Drafts:
Request For Comments:
RFCStatusTitle
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


IDR Minutes for 12/13 meeting from 3:30pm to 5:30pm on

Agenda:

1) Charter
2) Base Documents
3) IP v6 issues on Base Documents
4) Security Issues with BGP

Action items from the working group:

1) Charter will be amended to include graceful restart.

2) Last call on the mailing list will be issued for the draft 17 of BGP.
[draft-ietf-idr-bgp4-17.txt]

3) Router-id Draft will go to the mailing list for discussion as an
IDR BCP [draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt]

4) Draft on BGP4+ Peering Using IPv6 Link-local Address
(Draft-kato- bgp-ipv6-link-local-00.txt).
Sent to the mailing list for discussion as IDR BCP.

5) Security draft will be issued as a working draft

Discussion:

1) Charter

Charter comments? Read & send comments to mail list. One error was noted:

-Graceful Restart is missing. This will be corrected in the charter this week.

No comments were received from the meeting.

2) Base Documents:

-16 has been out on the mail list.
-17 will include FSM & new appendix B.

The clean-up of mib draft to match IETF MIB will go for last call in Jan for historical [draft-ietf-idr-bgp4-mib-08.txt].

Sue Hares covered differences from -15 to current and diff between current and 1771; slides to be posted. No discussion in the meeting.

3) IP v6 issues around MP BGP for IP v6 deployment (RFC 2545)

a) Router-id for IP v6 only BGP

Alain Durand & Francis Dupont presented the router-id draft for BCP.
The router- id draft was sent to the mail list during the week of IETF.
A IP v6 only router needs a unique router-id for BGP peer. Since the IP v6 only address is 128 bits long, the 32 bit encoded address must use other encoding.

This draft proposes using the Class E space for the 32 bit address. The draft is a BCP because the 4 bytes may be too small in the future.

No opinions were listed in the working group. The authors will suggest that the Router-id draft be made a BCP. Last call on the BCP will be made in late December. [WG chair correction: January '02]

b) RFC 2858 changes with the BGP4+ Peering Using IPv6 Link local Address
(draft-kato-bgp-ipv6-link-local-00.txt)

[3:50pm - 3:55pm]

RFC 2545 suggests that the IP v6 code uses either:
- Global or
- Global and Link Local

For peering at exchange points, Bill Manning and Akira Kato found this to be wasteful of IP v6 addreses. Therefore, in this draft Bill Manning and Akira Kato suggest that this list should also include:

- link local + interface address

In RFC 2545 section 3: nexthop, the kato-bgp-ipv6-link-local draft suggests that the BGP peer fill in:

a) Global or global + link-local

The global address is filled in and ignored by the receiver if it is not valid.
The link local address is then accepted and replaces the global address.

Or,

b) Specify the neighbor by link-local address

Current API for IP v6 requires all link-local addresses to have a link local address and an interfaces inside the implementation.

This draft is both a BCP and suggests changes to the 2545 draft (2545bis) and provides BCP text. This draft will be sent to the IDR mailing list with these comments.

Implementation status is that there are two implementations that inter-operate.


Question: 1) Which global address should be placed in the next hop?
Answer: random is not a good idea, it should be user configurable.

Question 2: Which global address in the next hop?
Answer: Random is not good idea. Make it user configurable


4) MIBs (3:57 pm)


Draft mib-8 replaces RFC 1657; pretty much done; publishing as informational.
There is a problem with the security section. Last call will be done on the list in January.

2nd version of MIB to match current bgp draft and all additional BGP drafts:

Draft-ietf-idr-bgp4-mibv2-01.

There is a focus group working on BGP MIBs. Anyone can join this group,
At:
majordomo@nexthop.com
subscribe BGP-MIB

MIB needs to have further changes to accommodate the MP Extensions and AFI/SAFI changes.

Goal: have everything done by Minneapolis IETF and send to general list at that point.

To subscribe to the MIB workers draft (mibites) to help:

bgp-mib majordomo@nexthopcom

Questions: 1) ppvpn MIB has a bunch of BGP info in it ... can that be leveraged?

Answer: yes, we're trying to not duplicate and reuse as much as possible.


4) Document status - see powerpoint presentations.


5) BGP Security Issues 4:10


a) Context from mail list:

3 issues w/routers:
Router access: ssh vs. telnet
Router links: tcp/ip - tcp md5 vs. IPSec
Securing routing information

5 issues w/handling security in BGP information (sent out on mail list)

b) Sandy Murphy - BGP Security Analysis 4:15 [See presentation]
BGP protocol vulnerabilitieis

Questions:

1)(Sue Hares) How many people use AS sets?

Answer: no hands;
Cengiz Alaettinoglu: there are less than 100 sets in the routing tables.

Jeff Haas: You don't see the sets because most vendors choose a common prefix of common leading ASes.

2)(Sandy Murphy) Are there any factual errors? Should this be a WG item? Should this be in 2 drafts?

Discussion:

Cengiz: In most schemes you still need to know as is authorized to advertise the prefix, and this isn't part of BGP it must come out of band. Unless such a new out of band system is created, then IRR is the only real solution today.

Sandy: IRR is the natural place to put this, which means we need to get the IRR used more.

3) (Bill Fenner)Do we need a draft for using IPSeC with BGP?

a. Bill Fenner will check with the IESG to see if we need a profile draft

b. Sue Hares and Dave Ward will work on IP sec draft with BGP

c. An applicability statement is a good place to talk about MD5 versus IP sec


4)(Bill Fenner) Say there are 15k as-paths in the routing table; the router has to check signatures on 15k as-paths/origin pairs?


Sandy: the processing requirement for a full feed on start-up is enormous; perhaps just start using paths until calculations are done.

Working Group vote on:

This document should describe the current vulnerabilities and BCP, and possibly a second draft about things we need to build. Sandy will submit these as a working group draft.

Motion was accepted by the working group and the document(s) will be accepted as a working group document(s).

4:43 call for blue sheets; meeting adjourned.

Slides

Agenda
BGP MIB Update
Router ID in IPv6 only networks
Securing the Internetís Exterior Routing Infrastructure