WG minutes

[Yakov Rekhter <[e-mail]>]

Folks,

Attached are the WG minutes. 

Yakov.
------------------------------------------------------------
IDR WG Meeting Minutes 11/18/2002
Chair: Yakov Rekhter <[e-mail]>
Recorder: Danny McPherson <[e-mail]>

===================================================
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 R. 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 anything, 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