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:
RFC | Status | Title |
|
RFC1267 | H | A Border Gateway Protocol 3 (BGP-3) |
RFC1269 | PS | Definitions of Managed Objects for the Border Gateway
Protocol (Version 3) |
RFC1265 | | BGP Protocol Analysis |
RFC1266 | | Experience with the BGP Protocol |
RFC1397 | PS | Default Route Advertisement In BGP2 And BGP3 Versions
Of The Border Gateway Protocol |
RFC1403 | PS | BGP OSPF Interaction |
RFC1657 | DS | Definitions of Managed Objects for the Fourth Version
of the Border Gateway Protocol (BGP-4) using SMIv2 |
RFC1745 | PS | BGP4/IDRP for IP---OSPF Interaction |
RFC1771 | DS | A Border Gateway Protocol 4 (BGP-4) |
RFC1774 | | BGP-4 Protocol Analysis |
RFC1773 | | Experience with the BGP-4 protocol |
RFC1863 | E | A BGP/IDRP Route Server alternative to a full mesh
routing |
RFC1930 | | Guidelines for creation, selection, and registration of
an Autonomous System (AS) |
RFC1966 | E | BGP Route Reflection An alternative to full mesh IBGP |
RFC1998 | | An Application of the BGP Community Attribute in
Multi-home Routing |
RFC1997 | PS | BGP Communities Attribute |
RFC2270 | | Using a Dedicated AS for Sites Homed to a Single
Provider |
RFC2385 | PS | Protection of BGP Sessions via the TCP MD5 Signature
Option |
RFC2439 | PS | BGP Route Flap Damping |
RFC2519 | | A Framework for Inter-Domain Route Aggregation |
RFC2545 | PS | Use of BGP-4 Multiprotocol Extensions for IPv6
Inter-Domain Routing |
RFC2796 | PS | BGP Route Reflection An alternative to full mesh IBGP |
RFC2842 | S | Capabilities Advertisement with BGP-4 |
RFC2858 | PS | Multiprotocol Extensions for BGP-4 |
RFC2918 | PS | Route Refresh Capability for BGP-4 |
RFC3065 | PS | Autonomous 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