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