Routing Protocol Security Requirements WG (rpsec)
Wednesday, November 12 at 1300-1500


CHAIRS: Russ White <riw@cisco.com>
        Tony Tauber <ttauber@genuity.net>


Agenda Bashing - Tony Tauber
 no comments


Threats document status - Tony Tauber
 draft-ietf-rpsec-routing-threats-03.txt
 Went through WG Last Call
 Went through IESG review
  Comments received, will be sent out
 Need to:
  - integrate comments
  - revise, review and/or respond
  - return to the process to progress.
 No other comments from the microphone


Requirements document - Danny McPherson
 
draft-puig-rpsec-generic-requirements-01.txt


 Building off Threats document in large part and figuring what items in 
there ought to receive mitigation and what level of requirements (eg. MAY, 
SHOULD, MUST) is warranted.  Also touches on system resource concerns.


 Needs much help from the community.
 How many have read this document? 4 or 5 hands.
 Consensus call:
  Should this draft be accepted as a WG work item?
  Sense of the room: Yes
  Will be taken to the list for confirmation.


Charter Discussion - Tony Tauber
 Routing ADs would accept protocol specific work on the charter
  Generic work muct be completed before the protocol specific work
 How many would commit to work on protocol specific documents?
  Some hands
 How many would commit to comment on protocol specific documents?
  Some hands
 Should the charter be modified to accept protocol-specific work in this WG 
with the provision that it not advance ahead of current chartered work (ie. 
Generic Threats and Requirements documents)?
 Consensus call:
 Should the charter be ammended to include protocol-specific work?
  Sense of the room:  Generably favorable, with at least one opposed.
 At the microphone:
  Steve Kent suggested that this work should go to the protocol 
specific groups, because the issues are different enough for each 
protocol to warrant seperate work by the experts in those protocols, and the 
participation isn't heavy enough in RPsec to do the work.
 WG Chairs will revise charter and send to the list for 
consideration and comments.
 Consensus call:
  Should this draft be accepted as a WG work item?
  Sense of the room: Yes
  Will be taken to the list for confirmation.



BGP Attack Tree - Sean Convery
 draft-convery-bgpattack-01.txt
 Presented information on the updates made since the last revision.
  Discussed presentations to the operational community.
  Discussed lab and real world testing of BGP security.
 Consensus call:
  Should this draft be accepted as a WG work item
   Sense of the room: Clearly in favor with no opposition.
   If modified charter is accepted on list, then this item will be 
accepted as a WG item.


OSPF Vulnerability Analysis - Emmanuele Jones
 draft-jones-OSPF-vuln-01.txt
 At the microphone:
  Acee Lindem: No disagreements on the vulnerabilities, other than the 
flooding, most people have implemented the flooding steps in the 
opposite direction. Check for its for me, before flooding the LSA. Once you 
are on someone's network, you could cause other damage.
  Tony Tauber: What sort of mitigations are avaiable?
  Emmanuele Jones: OSPF security is important, even if you could do other 
things. You have to bypass authentication/etc.
  Felix Wu: Some of this has to do with implementation, is this a 
protocol design issue?
  Emmanuele Jones: It is a protocol design issue, since the RFC does state 
the order of steps to take, which allows the attacker this hole.
  Vassilis Prevelakis: The approach between generic threats and the OSPF 
threats seem to be quite different. Should we try to standardize the 
framework of these sorts of drafts?
  Padma: I believe that we can't do much against insider attacks.  I would 
prefer to have more protection against outsider attacks.  I would like to 
see outsider/insider attacks addressed in the doc.  We should copy this 
draft to the OSPF list, as well.
  Emmanuele Jones: The draft does address insider and outsider attacks, but 
they are not easy to seperate.
  Tony Tauber: There's the notion of Byzantine failure, detection, 
recovery which is mentioned in the Threats draft and well discussed in 
other literature.  This threat relates to mis-behaving insiders 
(routers) and it's not really acceptable just to write off threats 
related to compromised routers entirely.  Consider at least checking and 
reporting errors such as receiving packets on unexpected interfaces, with 
unexpected source addresses, etc.  Some of that's done today.
  Acee Lindem: To defend this work, most implementations have some way to 
drop things cooming from unexpected interfaces, though they are not in the 
specs.
  Tony Tauber: Then we should consider those things.
  Acee Lindem: Say you have a unix box running OSPF with no 
authentication, there's no checking of where packets came from, so it's 
good to document that the implementations should check this sort of 
stuff.
  Felix Wu: Is it a protocol design issue really or 
implementation?
  Emmanuele Jones: Yes. Per the spec, order is problematic.
 Should this work be accepted as a WG item?
  Yes: Lots of hands
  No: One vote
 If the WG charter amendments are accepted, this item will be accepted as a 
WG item.


Path Security - Russ White
 draft-white-path-considerations-00.txt
 Point is that some amount of information in distance-vector and 
path-vector protocols is hidden or removed as a matter of course (eg. for 
reasons of optimization or policy).  Attempts to derive security for those 
protocols must take into account this property.
 Steve Kent: Understand what you're trying to say.  Wasn't entirely clear in 
the draft.
 Russ White: Yes, the fact that the draft's language needs 
clarification been made obvious by some of the feedback and revision is 
planned