Last Modifield: 05/30/2002
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.
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. |
RFC | Status | Title |
---|---|---|
RFC1105 | E | Border Gateway Protocol BGP |
RFC1164 | H | Application of the Border Gateway Protocol in the Internet |
RFC1163 | H | A Border Gateway Protocol (BGP) |
RFC1267 | H | A Border Gateway Protocol 3 (BGP-3) |
RFC1268 | H | Application of the Border Gateway Protocol in the Internet |
RFC1269 | PS | Definitions of Managed Objects for the Border Gateway Protocol (Version 3) |
RFC1266 | I | Experience with the BGP Protocol |
RFC1265 | I | BGP Protocol Analysis |
RFC1364 | PS | BGP OSPF Interaction |
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 |
RFC1656 | I | BGP-4 Protocol Document Roadmap and Implementation Experience |
RFC1655 | PS | Application of the Border Gateway Protocol in the Internet |
RFC1654 | PS | A Border Gateway Protocol 4 (BGP-4) |
RFC1745 | PS | BGP4/IDRP for IP---OSPF Interaction |
RFC1774 | I | BGP-4 Protocol Analysis |
RFC1771 | DS | A Border Gateway Protocol 4 (BGP-4) |
RFC1773 | I | Experience with the BGP-4 protocol |
RFC1863 | E | A BGP/IDRP Route Server alternative to a full mesh routing |
RFC1930 | BCP | Guidelines for creation, selection, and registration of an Autonomous System (AS) |
RFC1965 | E | Autonomous System Confederations for BGP |
RFC1966 | E | BGP Route Reflection An alternative to full mesh IBGP |
RFC1997 | PS | BGP Communities Attribute |
RFC1998 | I | An Application of the BGP Community Attribute in Multi-home Routing |
RFC2270 | I | Using a Dedicated AS for Sites Homed to a Single Provider |
RFC2283 | PS | Multiprotocol Extensions for BGP-4 |
RFC2385 | PS | Protection of BGP Sessions via the TCP MD5 Signature Option |
RFC2439 | PS | BGP Route Flap Damping |
RFC2519 | I | 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 | Standard | 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 |
RFC3345 | I | Border Gateway Protocol (BGP) Persistent Route Oscillation Condition |
IDR WG Meeting Minutes 11/18/2002 Chair: Yakov Rekhter <yakov@juniper.net> Recorder: Danny McPherson <danny@tcb.net> =================================================== Document Status Update - Yakov Rekhter o RFC 2842bis published as draft standard RFC 3392 o draft-ietf-idr-md5-keys-00 WG Last Call Ended in May 2002, current status (as shown by the IETF ID Tracker) is DEAD o draft-ietf-idr-bgp4-18.txt in WG Last Call now. 69 comments over 2 months. Thanks to Andrew Lang for keeping track. o Looking for volunteers for update to 1773 & 1774, which is required for base spec advancement. o Need to advance BGP MIB. Currently needs minor fixes to security section. Looking for WG last call end of Nov/early Dec o bgp-vuln accepted as WG document. o No other progress is permitted to be made in the WG until base spec advances. =================================================== The BGP TTL Security Hack -- Dave Meyer o draft-gill-btsh-00.txt o Vijay Gill, John Heasley, Dave Meyer authors o Mechanisms proposed in draft can be used to mitigate large number of DOS attacks on port 179 o TCP 4 tuple easy to discover, then just overload the RP. Don't have to own the router or anything in the path to impact the routing system. o Is there anything short of crypto to mitigate attacks? o Aware of No way to spoof TTL. o Assumes vast majority of EBGP peerings are between directly adjacent router. o Set TTL to 255 and if receive TTL is not 254 toss packet. o TTL value of 1 won't work per ttl 0 value can be engineered. o Then use receive path ACL to only pass receive packets to route processor if TTL is in this range. If not, silently discard. o Common practice to filter loopback IPs on the network/AS edge. Configured on per-peer basis. o Only works unless both peers implement o Protection of infrastruture beyond this requires encyption-oriented mechanisms. Dave Question to WG: Will this break anything? Question from floor: Why wasn't this in the very beginning? [hahah] John Scudder: Good idea, should be WG draft, but where (here or RPSEC?)? Yakov Rekhter: How is this related to MD5 signature? AD/Alex Zinin: BGP Specific mechanisms belong in IDR WG. Need consensus from WG to accept as WG item. Should it wait on RPSEC to finish requirements document? Probably not? Jeff Haas: Thinks it belongs in RPSEC per it could be used generically for lots of stuff. AD/Alex Zinin: Agree, but if we want to do it here for BGP then it's OK to document it here. Dave Meyer: Needs to be more than BCP peer local check for BEGP multi-hop has to be changed. Yakov Rekhter: Can WG accept now or must we wait? AD/Alex Zinin: WG should put in updated charter queue and progress thereafter. Yakov Rekhter: Vendors can still implement now. Yakov Rekhter to Dave Meyer: Keep updated, we'll add to charter after base spec is done. ========================================================== BGP Custom Decision Process -- Alvaro Retana o draft-retana-bgp-custom-decision-00.txt o Alvaro Retana & Russ White authors o Need for explicit/flexible route selection mechanism and not employ non-deterministic ROUTER_ID and similar randomness, etc... Draft Proposes: o Locally siginificant metric that can be inserted anywhere in selection process. o non-transitive extended community, knowna as "cost community", looks like this: Point of Insertion - value of attribute after which to be inserted. Community ID - so that multiple communities can be used. Cost - lowest cost preferred. o Must be deployed ubiquitously throughout AS. Question: Non-trans so it only works for IBGP side. Alvaro Retana: Yes. Comment: Capability support is needed to allevaite IBGP deployment issue? Alvaro Retana: Perhaps. Question: Any issue with Route Reflector in the middle? Alvaro Retana: No issue. Also, talks of aggregation of communities. Questions: Non-transitive so what are route reflector issues? Yakov Rekhter: Non-transitive community v. non-transitive attribute. Alvaro is talking of community, not attribute. Alvaro Question to WG: Would like to progress as WG but knows we have to wait on charter update. Question: What can this do that LOCAL_PREF can't do? Alvaro Retana: Lots. Need to prefer one exit but not absolutely like LOCAL_PREF. ========================================================== BGP Graceful Restart Implementation Report John Scudder o Survey sent out a few months ago, implemations from these folks (did I miss one??): Cisco, IPinfusion, Redabck, Riverstone, Tenor, Juniper Question from John to WG/Chair: Should an implementation report be published and submitted to WG? Should I do this under my own name per base spec hold-up? Question: Any feedback on needing to tweak grace period? John Scudder: No. Yakov Rekhter: This & Extended communities straight to IESG Can we make THIS an WG document? AD/Alex Zini: Can make WG document, can NOT progress until base spec is complete. ========================================================== Advertisement of Multiple Paths in BGP John Scudder o Introduces mechanism to permit advertisement of multiple paths for a single prefix. o New Capability TBD, no data o If capability is advertised, NLRI uses new encoding. o Adds flags (one octet) and identifier (two octets) to usual NLRI Changes versus -00 rev: o Path (route) is identified by (ID,prefix) o Flags fields added in new version: FirstPath - implicit withdraw LastPath - hint to run decision process BestPath - moved from ID o ID of 65535 means explicit withdrawal of all paths o Removed dependency on MP-BGP New Changes: o Instead of LastPath use EndofRIB marker. (has to do with BGP update packing and attribute packaging) o Editorial Motivations: o MED Oscillation Fix - Med Oscillation Documente in RFC 3345 - Currently proposed fixes reduce oscillation but introduce deployment considerations. - Enke Chen's Best-External Advertisement solution. - All reduce risk but none eliminate. - Full-mesh IBGP doesn't oscillate. - RRs (or confed) hide many clients and can only advertise one route under current semantics. - Any full solution to oscillation requires advertisement of multiple paths. o Other References: - draft-walton--bgp-rotue-oscillation-stop - draft-wilfong-ibgp-oscillation Proposal: o Would like to move forward and determine what algorithm should be used to advertise additional paths. Probably not necessary for interoperability but have to agree on path advertisement semantics. Also Useful to enable Multi-Path IBGP o Add Path also introduces clean way to do IBGP multi-path. o Could get rid of RFC 3107, which only assists labeled routes. Proposals: o Make add-path a WG document (taking BGP Base spec hold-up into consideration) o Will publish-02 document o Need folks to implement & deploy! Kireeti Kompella: What effect does this have on current way of doing implicit withdraw? John Scudder: None, we're not doing away with it. Question: What are the scalability implications of advertising multiple paths? John Scudder: Depends on path advertisement algorithm. ========================================================== Secure Origin BGP Alvaro Retana o draft-ng-sobgp-bgp-extensions-00 o Lots of discussion in RPSEC. o James Ng - Editor of current draft o Document is still a work in progress. o Need participation from vendors & operators. Needs lots of participation from everyone to implement o Please read the draft. SoBGP Operation: o Verify orign of advertisment o Verify origin of prefixes o Check the path o Flexible & very necessary to allow each AS to decide what level of verification & checking. o Any solution MUST be incrementlly deployable. o This solution Does NOT protect: peering sessions between routers. o BGP Attribute authentication o Does NOT Thanism to verify full validity of the AS_PATH. Can be checked to see if it is possible. o Introduces Topology Map concept to address who neighbor are. o Scalability concerns per Added extra protocol information, increases overhead, obviously. Defines New BGP Message - Type 6(?) o Used to carry security information within the protocol. Can also be carried outside of bgp. *** bunch more details in the draft, need to read it! Propose: o Add to the new WG charter to include BGP Security work as work item o First step should be requirements document. Should probably come from RPSEC. Question: Helpful if you would address motivation Alvaro Retana: To verify that originator is authorized to announce the route. Comments: Sigcomm2002 papers talks about route advertisements in error, etc... Good reference. Jeff Haas: Problem is that this proposal doesn't provide protection against active attack. This provides protection against things that COULD show up. Russ White: If you read draft operation you can only spoof with a valid path. Jeff Haas: Because paths aren't signed, still problems exist. John Scudder: Spec is better than nothing, have to draw line between bullet-proof and something deployable. Alvaro Retana: Need to work on requirements first! Comment: Scalability issue. Need to build chain of trust perhaps instead. Alvaro Retana: Don't need path keys, need origin keys. Vince Fuller: How is this going to be any more acceptable than past work that providers shot down? What makes this more interesting? Alvaro Retana: Not a provider, none cared to comment... Vince Fuller: Should look to IOPS work requirements from a few years back. Alvaro Retana: Everyone is more paranoid abnout secutiy now, good motivater! Comment: Backfitting security is a problem, it always is. What do you put in a router? Should this be there? How much can a router do? Less security and better other stuff may become a choice. Lots of coinflicts. John Scudder: Appealing because it can be deployed incrementally. Comment: Has another proposal but will take it to RPSEC. Russ White: Note that you CAN offload security processing on other boxes with this proposal. ======================================== ======================= Open Discussion... John Scudder: Question on Base Spec holding up all other work. When will Last Last call happen? Yakov Rekhter: Don't know. This is just WG Last Call and then IESG comments, then IETF Last Call. Can't give ANY current date. AD/Alex Zinin: Can't give hard dates. The process will be finished when the process is finished. Not that IESG is holding up work, just part of normal draft review process. Comments will be sent back to WG and it's up to WG to decide how fast we can address. Yakov Rekhter: How long will it take IESG to look at document? AD/Alex Zinin: Three parts to process: 1 AD review 2 To IESG, IETF Last Call issued. if comments back to WG. 3 No comments, to IESG telechat within two weeks. Someone on IESG may defer but can only happen for two weeks. With consent of chair can be deferred for two more but that's max. Comments need to be addressed by authors/wg and resubmit to IETF last call. When comments are provided back to WG and Addressed and document goes back to IESG it is normally not the case that new comments will arise from IESG. They try to be consistent and only supply one set of comments. Yakov Rekhter: Lack of progress in IETF Standards Track doesn't mean you can't still discuss, implement, deploy, etc.. Meeting Adjourned |