[RPSEC] RPSEC Minutes (IETF 58 - Minn)

[Tony Tauber <[e-mail]>]

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

CHAIRS: Russ White <[e-mail]>
        Tony Tauber <[e-mail]>

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


_______________________________________________
RPSEC mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rpsec