Subject: [OPSEC] Review of draft-ietf-karp-threats-reqs-00

From: Joel Jaeggli <[email-masked]>
Date: Sun, 08 Aug 2010 14:35:42 -0700

Reviews of this document were requested during the IETF 78 karp working
group meeting. since I raised my hand, I've undertaken to provide a
review of this document.

I think this is a pretty good document, It  could do with a bit of
re-organization which I'll deal with in the criticism. One piece of
feedback I think I heard loud and clear in the opsec working group
discussion of karp activities was that operators are no sold on the idea
of a Key Manangement Protocol as a requirement. KM as activity is
currently handled as part of configuration and while being able to rekey
or change protocols without interuption or synchronized coordination is
particularly desirable, there's not groundswell of support around for
example making an ldap query everytime you fire-up a bgp session.

criticism:

page 5 last paragraph...

Effectively the the unicast layer 3 or above routing protocol being
discussed here is BGP. The fact of the matter OSPF RIP ISIS  are part of
the reason we don't have a general purpose solution.

page 6 paragraph 2

While I'm not sure that I characterize rfc 2385 protection as part of
bgp, it's certainly part of running bgp today. likewise in the is-is
case tlv 10 is an existing protection mechanism.

page 6 scope of roadmap work

should likley just make an informative reference to the appropiate
document (framework)

page 7 1.4 goal 2

goal 2 is a section unto itself, as a principle it should be one or two
sentences at most. it's possible that the balance of the contents of
goal 2 bleongs in a subsection of 1.3 since it provides guidance on scope.

goal 3

deployability is one word even if your dictionary disagrees

I'm not sure that 3 and 4 are actually sufficiently differentiated. goal
3 is for the benefit of the robots and goal 4 is for the humans, but the
human practices in (4) currently are the product of number (3)

goal 4 again part of this goal belongs in the scope, not in the goal itelf.

page 10 1.5 non-goals

	it's "validity" I think not security that we're not addressing,
	and that is the SIDR goal, that security is the product of
	protecting the validity of routing data.

page 11 threats in scope...

	reflecting for a moment on the neature of outsiders, I think
	the concept of terminated employees is necessarily specific.
	The property that terminated employees share with some other
	potential outsiders is that (at one time) the came by the
	information used to launch the attack legitimately, they share
	this property with for example former peers, shared route 	
	reflectors at some exchange points, routeviews/ris, customers
	(possibly the largest set) upstream isps etc. I would focus on
	the property on not on the individual case. the goal in all
	cases is the rekey quickly enough to prevent legitimate
	credientials from being resused for illegitimate purposes. 	
	problem today, appart from the fact that rekeying is painful is
	that we re-use the same credentials over and over again

	becasue of the nature of (multihop) bgp and the prevalance of
	l3 or l2 vpn, what constitutes onpath is itself somewhat
	nebulous, an attacker sitting inside your l2vpn provider might
	well alter the LSP to better facilitate onpath injection or to
	seperate the endpoints without superficially altering any other
	link characteristics.

	I'm reasonably certain that devices which has legitimate
	credentials but no longer should are not rendered out of scope
	as byzantine sources.

page 13

	DoS attacks on transport sub-systems

		does no end in a complete sentence.

	Brute Foce Attacks Against Password/Keys

		generating per session keys is another widely used
		method for reducing the value of brute force attacks
		that's somewhat more specfic than simply frequently
		rekeying.

3 requirements for phase 1

	regarding 13 - I'm reasonable certain that there are operators
	that would not consider the lack of inclusion of a
	key-management protocol a blocker. I could imagine work on a
	protocol where the developers might declare victory and go home
	before including hooks for a KMP. I'd probaly therefore use
	SHOULD in this context.

	15 - if what is being asked for is a minimal increase in the
	number of messages passed, that should simply be stated in
	lieue of the convergence time requirement..

	19 - yes include in 3.6

	21.1-4 are actually subsidiary to 20

	like wise items in 23 are really under 22

	no item 26