[RPSEC] Draft IETF-61 minutes

[Tony Tauber <[e-mail]>]

Unless I hear otherwise today or tomorrow morning, these will be
submitted as the minutes for IETF-61 in Washington, DC.

Thanks,

Tony
----
Routing Protocol Security Requirements WG (rpsec)

Tuesday, November 9 at 1300-1400
===================================

CHAIRS: Russ White <riw at cisco.com>
        Tony Tauber <ttauber at 1-4-5.net>

AGENDA:

 Agenda Bashing

 Requirements document status
         draft-ietf-rpsec-generic-requirements-00.txt

Made contact with the Editor (Jean-Jaques Puig) who has gotten busy
with other things lately but will have more time to devote in Jan.
Likewise engaged some other contributors (Danny McPherson and
Emanuele Jones).  Will work to revise in that timeframe.

 OSPF Vulnerability Analysis status
         draft-ietf-rpsec-OSPF-vuln-00.txt

Is a WG doc but must wait to progress until the progression of the
Generic Threats and Requirements docs.  Have talked with the primary
Author (Emanuele Jones) and asked that increment the version number
and re-submit the document to ensure that it does not expire from the
I-D repository.

 Threats document status		Sandy Murphy
         draft-ietf-rpsec-routing-threats-07.txt

Sandy presented her changes to the document.
Some changes were refinements to the language to collapse a number
of redundant or conflicting terms.  Also worked through other dangling
or otherwise problematic references.
Byzantine Failures (section 4.8) removed
The document will go to Working Group Last Call.

 BGP Attack Tree document status
         draft-convery-bgpattack-02.txt

Similarly to the OSPF Vulnerabilities draft, this document may not
progress yet.

BGP Attack Tree Risk Analysis  R. Kuhn et al.
"Incorporating Subjective Risk Values in BGP Attack Trees"
Risk assessment of BGP attacks, using NASA/AIAA standard procedure for
fault trees Includes costs associated with countermeasures and the
effectiveness of countermeasures in reducing risks.  Kent and Metzger
vigorously disputed the usefulness of this approach for security risk
assessment.  Sandy Murphy wasn't too sure about it either.

Uses NASA/AIAA for trying to quantify probability of certain risks.

Spreadsheet to do this stuff with goal to model the effect of
countermeasures also. DOS attacks particularly hard to model.

 Steve Kent: The methodology developed by AIA was appropriate for
 their environment, but they tend to be wanting when applying them to
 attacks, because the propbablility generally goes from close to 0 to
 close to 1. Why did you decide to do this sort of analysis for
 security.

 R Kuhn: This is common in many industries, so we decided to use this one.

 S Kent: I believe this methodology is questionable in this environment.

 R Kuhn: There is always the risk of human mistakes, even in the
 nuclear industry, for instance.

 Perry M: You're making certain statistical assumptions that are not
 valid. Before a fault is found, it won't be exploited at all. When a
 fault is found, it will be exploited in bulk until it's fixed. The
 variables are not independant.

 R Kuhn: We don't expect to get accurate numbers, but rather a risk comparison.

 Perry M: This analysis won't give you even a good risk comparison.

 R Kuhn: This is the type o feedback we're looking for.

 Sandy Murphy: One of the items in the attack tree said something
 about disabling a certain portion of the Internet, is your analysis
 in respect to a single router, or in respect to the entire
 Internet. How are you doing analysis on the entire Internet.

 R Kuhn: We are following the attack tree, as it's been published.

 Sandy M: How did you do these calculations?

 R Kuhn: There's a standard fault tree calculation, we can look at them later.

 Sandy M: The reason I ask is because faults are not exploited equally
 throughout the network. The nuclear power plant error does add some
 randomess, but the malcious operator are applicable to the malicious
 operator case.

 R Kuhn: Most of these attack tress work with a single router.

 Sandy M: While DOS is a big problem, the biggest problems have not
 been DOS attacks, but rather misconfigurations of routers. The
 calculations then lead away from the obvserved results.

 R Kuhn: The countermeasures we're looking at should however impact

 Markus Leach: This work is interesting, but I'd be hesitent to let
 this work broadly impact the work the WG is doing. It wouldn't occur
 to me use AIAA analysis to work with the types of systems we are
 dealing with here. AIAA analysis is for failure analysis, rather than
 malicious attacks, or malicious actors.

 R Kuhn: I agree completely. It doesn't map completely, but we thought
 it might be useful.

 BGP Security Requirements		Blaine Christian
         draft-christian-bgpsecreq-01.txt

Goal:  Provide a means to verify and assure peering relationships and
prefix advertisements, etc.
Threats:  Unauthorized announcements
Must support increment deployment
Web of trust must be supported, also Strict hierarchy of authority (users
should be able to decide which one they want)
Need to make this a working group document.

 Steve Kent: Biggest concern is the lack of rationale. We need to
 motivate each of those requirements. Start from the semantics of the
 protocol, and say: "These are security things that must be done, and
 these are the performance concerns." For instance, we're concerned
 about computational speed, we're concerned about update size,
 etc. You need to start from: "This is what BGP is supposed to do,"
 and how to secure them. Once you're past that, you can get to work on
 performance issues, and then think through processes.

 Blaine C: The hope was, through the process, and get comments.

 Steve K: I'd be glad to send you text showing what text we used when
 to come to these conclusions.

 Sandy Murphy: One thing I had noticed is that the doc covers
 requirements for solutions, and other requirements for security of
 the protocol. These should be better defined in the document.

 Sandy Murphy: BGP is a distributed system, you might have a strong
 requirement for security, but someone three hops away might not. How
 can people trust, or understand, the levels of trust other people
 might have when they produce their information?

 Blaine C: This is a big question--can you actually put that sort of
 thing in the decisions process.

 Tony T: Should we accept this as a WG doc?

 Russ W: If we accept this as a WG doc, should we take the work off
 the DT list, or pushed to the main list.

 Bill Fenner: If we make it a WG doc, then we should push it onto the
 main list.

[ Consensus call on adoption of the document as a WG work item. ]

 Tony T: The sense of the room is that it should be a WG doc. We'll
 confirm on the list.

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