Current Meeting Report
Jabber Logs

2.5.3 Inter-Domain Routing (idr)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 05/30/2002

Susan Hares <>
Yakov Rekhter <>
Routing Area Director(s):
Bill Fenner <>
Alex Zinin <>
Routing Area Advisor:
Bill Fenner <>
Technical Advisor(s):
Jon Saperia <>
Ran Atkinson <>
Mailing Lists:
General Discussion:
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.
  • - draft-ietf-idr-bgp4-17.txt
  • - draft-ietf-idr-bgp4-mib-09.txt
  • - draft-ietf-idr-route-filter-06.txt
  • - draft-ietf-idr-restart-05.txt
  • - draft-ietf-idr-as4bytes-05.txt
  • - draft-ietf-idr-bgp-ext-communities-05.txt
  • - draft-ietf-idr-aspath-orf-02.txt
  • - draft-ietf-idr-bgp4-mibv2-02.txt
  • - draft-ietf-idr-dynamic-cap-02.txt
  • - draft-ietf-idr-cease-subcode-01.txt
  • - draft-ietf-idr-rfc2858bis-02.txt
  • - draft-ietf-idr-rfc2385bis-01.txt
  • - draft-ietf-idr-rfc2842bis-02.txt
  • - draft-ietf-idr-bgp-identifier-00.txt
  • - draft-ietf-idr-md5-keys-00.txt
  • Request For Comments:
    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
    RFC1930BCPGuidelines 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
    RFC2842StandardCapabilities 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

    Current Meeting Report

    IDR WG Meeting Minutes 11/18/2002
    Chair: Yakov Rekhter <>
    Recorder: Danny McPherson <>
    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 
     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 
     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?
    John Scudder: Good idea, should be WG draft, but where (here or 
    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 
    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 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 
        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 
    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 
    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 
    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
     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-wilfong-ibgp-oscillation
     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.
     o Make add-path a WG document (taking BGP Base spec hold-up into 
     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 
    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!
     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 
    Question:  Helpful if you would address motivation
    Alvaro Retana:  To verify that originator is authorized to announce the 
    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 
    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 
    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 
    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 
    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


    The BGP TTL Security Hack