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 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