[RPSEC] RPSEC minutes from IETF 55

[Tony Tauber <[e-mail]>]

I think Russ buried mention of them in his message about the rpsec.org
website (where they're posted).

Here they are as well for any UUCP-connected folks.

Tony

------------------

Wednesday, November 20 at 1530-1730
===================================
CHAIRS: Russ White <[e-mail]>
        Tony Tauber <[e-mail]>

Minutes: Gerry Redwine, Russ White, Tony Tauber

Agenda Bashing (5 minutes)

S-BGP Workshop - Operator's Impressions (10 minutes)
  (Cancelled) * Randy Bush not in attendance

Order changed on-the-fly to have Dave Ward come just before soBGP.
Added John Ionnidis based on request earlier in the week.

Threat Analysis Drafts

draft-beard-rpsec-routing-threats-00.txt (15 minutes)
 Is there additional content needed?
 What is the best format to present the information?

 Q: Would it have to be a malicious attack ?
 A: No. Could have been a mis-configuration.

 Q: Who and how do we define high risk ?
 A: Need to build a definition and model for this.

 Q: How does this compare with the Murphy draft ?
 A: Do we consider it to be consolidated in this work

 Tony Tauber: What about disclosure of routing information ?
 Is there a presumption that routing information is kept secret?
 Doesn't seem that this goal was part of any protocol design.
 A: Need to define it as a role or risk to include routing information.

 Joel Halpern: Some things seem out of scope of what is expected of
 routers and routing protocols.  For instance what about underclaiming?
 Seems confusing.  Third or fourth parties could percieve your service
 as degraded w/o your knowing.  On the other hand, it's an operator's
 perogative to degrade their service sometimes (Ed: eg. DiffServ?)

 Yi Yang: The attacks are similar for compromised, masquerading but
 not the same.

 Radia Perlman: Insider vs. outsider.  Imagine giving a key but he's
 been compromised (that's insider).  Outsider is another router from
 another domain.


draft-murphy-threat-00.txt (15 minutes)

 Sandy:
  What type of structure document is useful?
  What content should be included?
  What is needed?

 Iljitsch van Beijnum: Local software bugs are part of routing ? The
 defect/bug is considered and insider attack?
 Sandy: Yes, in a sense.

 Q: Are bugs/defects considered a security issue?
 A: Not a security issue to other routers. Does not have to be
 accounted for by how the RP works

 Bob from ATT Comcast: How about IGP attacks that affect BGP decisions
 based on IGP cost? Where does this fit?
 Sandy: Good point.

 Yi. Spoofing router, inside or outside attacher?
 Sandy: If not the legitimate neighbor then it is an outsider.

 Radia. Clearification of insider vs outsider
	Insider- someone we should be trusting
	Outsider - should not be trusted, outside of domain

 Q: Are you saying that when there is local consequece (to the router)
 that is okay?
 A: One thing to focus on is how Routing Protocol reacts to faults
 within the center.

draft-convery-bgpattack-00.txt (15 minutes)

 Sean stepped through a small example of an attack tree

 Martin: Incorporate risk analysisk. Do you intend to do so?
 Sean: Maybe, that work is not in the draft currently and not likely
 due to the amount of variables/information.

 Alex Zinin: Is it more a method of documenting research or is it a
 method to do research?
 Sean: Both.  Some ideas need to be validated through testing.
 Alex: How good of a coverage can we get using this method vs. using
 vulnerability drafts and then going to potential attacks and threats.
 Seems to depend on the "evil" creativity of the person doing the
 analysis.  Do people approach from both directions? What do security
 people do?
 Steve Bellovin: Both.
 Sean: Sandy's BGP analysis helped with evil thoughts.

 Alex Zinin: There's some urgency w/r/t BGP in IDR
 now. Comment. Alex. What to do with doc. Useful if Sean and Sandy can
 get together to collaborate to include something in the BGP security
 section
 Sandy: What about syntax?  Why put in impossible attacks?
 Sean: Probably not binary values but degree of ease. HARD TO write an
 attack sceanario for people who just want to cause harm
 Sandy: Perhaps a different way of writing scenarios.
 Sean: Catch up with you later.

 Sandy: Some goals are just "Cause harm".  Hard to consider those.
 John Ionnidis: Who are the consumers?
 Sean: Designers, implementors, deployers.
 John: So, can tree be expressed differently depending on protocol vs.
 operational or implementor failure?
 Sean: Have some ideas about XML tool to approach this info.
 John: I have some ideas also which I could share.

 Chandra: Parts which talk about routing system attacks are most
 useful are parts which assign values which help know how to address
 problems.
 Sean: Yes.

 Felix Wu: Customer building global intrusion system. It is hard to
 assign a priority but the tree is good. What is definition of complete?
 Sean: Need WG to come to a consensuss as to the methods of attack and
 the most common ways.  Concern tree will grow, will never really be
 complete.


Discussion of next steps for threat drafts (10 minutes)

 Produce a generic draft as a milestone for WG. How to proceed?
 Consensus test: Hum says merge and authors are agreeable.

 Iljitsch van Beijnum: What about tree getting too big if all protos
 need representations?

 Discussion on whether there needs to be documents for each Routing
 Protocol or one doc for all.

 There seems to be room for both.

 John Scudder: What's a generic routing protocol?
 Mike Patton: Doing every protocol would have to be progressed
 simultaneously.
 Alex: Do generic work first.
 Tom Petch: Variety of protos, but much commonality in their function.
 Sean: Disagree that general work should come before BGP. Do both in
 parallel.
 Comment from Mic: Support generic work. Also consider things outside
 protocols.
 Michel Py: If you do generic tree, where do you put TCP?

 Alex Zinin: Transport mechanism is a generic component of routing
 protocols.  Will figure out what to do with BGP analysis work. Won't be
 blocked. This work should not impede the BGP analysis work being done
 in other groups.

 It's for protocol designers to check their work.  Keep in mind higher
 level Need goals to keep grounded in reality.

 John I: Maybe beef-up protos so that a certain ancillary problems
 can't break things.  Also detailed analysis of the attack on
 transport can be mounted different ways.

so-BGP (Dave Cook) (15 minutes)

 draft-ng-sobgp-bgp-extensions-00.txt
 draft-white-sobgp-extensions-00.txt

 ftp://ftp-eng.cisco.com/sobgp/index.html

Routing Protocols over IPSec (Dave Ward) (20 minutes)

 What do we do with the doc?
  Make it informational ?
  Does it belong in RPSec or IPSec group ?
  Make it more generalized for Routing Protocols ?

 Point from Dave Ward on what is unciear?
  Need decision from Area Directors to be able to use IPSec for Routing
  Protocols.

 Dave comments that the draft is not ready for primetime. IGPs already
 have other mechanism such as MD5 and IPv6

 Q: Alex does not think we need Area Directors decision

 Steve Bellovin clarifies his draft that it is not how to use IPSec with
 BGP but how to do IPSec with any arbitrary RP. BGP was chosen since it
 had the right characteristics to work with.

IRV: Internet Route Verification (John Ionnidis) (10 minutes)

 Source AS is validated as well as the paths.  Complementary approach
 to deploying soBGP.

 BGP hides information. When something goes wrong, can't tell whether
 the problem was malicious or accidental.

 Having a richer channel to communicate what is wrong that BGP is useful.
  IRV - Internet Route Verification:
  Each AS maintains a distributed, replicated database

 Alex Zinin: What about circular dependency between routing and
 database Look-ups?
 JI: Haven't solved it.


Session ended: 17:45.


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