[OPSEC] minutes part 2

[Joel Jaeggli <[e-mail]>]

This is the transcript from the second two presentations and the wrap-up

joel jaeggli
	Gaurava Agarwal will speak to manav's documents. There's two of
	them, I believe that both of these documents originated in rpsec
	and come looking for a home. It was pretty clear from the
	outset, that the spec crypt issues deals with a straight
	architectural problem. We got consensus on the list to accept
	that one on 10/10 with little or no opposition. The second
	document dealt with requirements  so there is some opposition to
	the doucment in it's current form. feedback on the list was
	favorible to the document but only as a set of recomentations or
	a bcp rather than as a set of requirements for protocol
	implmentors.

	Both of these documents need feedback I'll let him speak to
	them.

Guarav Agarwal
	The first document I'm going to speak to is issues with existing
	cryptographic methods in routing protocols

	I'm going to give an overview of routing protocol security and
	what is missing.

	...


	There is some issues with how we use authentication currently in
	routing protocols. document is supposed to list those concerns.
	covers ospf isis and rip.

	OSPF cryptographic sequence number spoofing or replay

	Need to move from md5 to stronger crypto.	

	Keys shared across the broadcost domain, need to move to a
	stronger key identifier

	For ospfv3 relies on ipsec, because manual key sequence number,
	replay protection cannot be used.

	It's not the authentication header that's the problem it's due
	to  the multicast nature.

	ISIS, md5 but no sequence number not notion of keyid for pdu key
	must be validated.


	Need to update from md5

	ripv2, no authetication of ip or udp headers . can change source
	address and reciver will still think it's a valid neighbor.

	Comments?

Bill Atwood
	You can add pim sm to the list.

	We need a distributed keyserver and the ospf guys need it even
	more than we do.

	gathering together a group of people to identify the needs and
	go and beat on msec.

Jeff haas
	This document is a nice problem statement of a number of
	protocols...

	Any intentions in this working group  to go beyond this?

Gaurav
	Just to list the problems in current  crypto algorithms.

Jeff
	the reason i ask this question is being the co-chair of another
	group that is affected by this (bfd). Manav and Vishwas have be
	bringing these to each working group, but a place that collects
	all these things is good the problem is this doucment tries to
	be everything by gathering them all in one spot, the contents of
	this document are a manifest of work that needs to be done at a
	per working group level. It may make more sense to have them be
	individual doucments instead of thrashing the docuemnt everytime
	more work is added.

Rich Graveman
	I agree with the previous comment. after I read it "I just read
	a guide to hacking cryptographically protected routing
	protocols" I think we need to move for what's wrong to the fix
	side, I will also echo previous comment, the multiparty key
	distribution problem is one of the less tractable problems. we
	can fix the hashed md5 problem.

	It's not routing protocols alone but the rsvp people are
	tackling the same thing, well similar enough.

joel jaeggli (as participant)
	I think one of the issues with this document is that the
	solution space is out of scope for this particular working
	group. we not going to go out and do implementations for these
	problems, on the other hand we have problems with the protocols
	that we use, and that component bring it here as opposed to say
	in rpsec. you're not going to solve the key distribution problem
	here. I think it's effective to bundle these up and survey the
	space. The divdie and conquer approach may still be required
	because you can't solve all these problems in one place. we can
	do this part of the work, and maybe we can help with some of
	these problems.

Sheela Rowles
	We are exploring fullfilling the need for rsvp but in the early
	stage of exploring the options (and this is happening in msec)

Gaurav
	Second draft, minimum cryptograhic requirements. the fact is
	cryptographic algorithms continue to be attacked. we need to
	keep track of this. the idea of this document is to keep
	modifying it but to track the minimum requirements for
	interoperability.

	Requirements  involve should- must- may+ carry values for future
	inclusion or removal.

	Tomorrow if a new scheme is introduced we'll need to rev this
	document.

	md5 must-,  you need it, in the future it won't be a must
	requirement other requirements will take precident.

Ron Bonnica
	In the last slide did I see a must minus. as an implementer how 	
	should I interpret this?

Gaurav
	As a requirement now but may not be in the future.

Melinda Shore
	I understand the intent I'm deeply uncomfortable with it, I
	understand when you see the must minus you should really thing
	about implementing the should+ but I think it leads to a less
	clear definition and it think it might tend to undermine
	interoperability becasue of it.  because people are going to be
	less likely to implement musdt minuses if they think they're 	
	going to be removed in the future.

	Still what I think what you're trying to accomplish can be
	achieved with weasel word s in the text. this is a must implment
	with the understanding that it may be superseded in the future.
	trying to get several documents published recently is that they
	want algorithm agility in the cryptospecfications.

Joel
	I think one of things I took away from the discussion on the
	list and my initial reading was that it required substantial
	changes in tone and language to, well there's a reason why
	they're looking to do it here rather than in rpsec. but alos
	that even in our evironment the way that this is setup is not
	going to fly and this disccusion is extremely valuable and needs
	to go into the document for it to go anywahere.

Ron
	I tend to agree with melissa, this is alikely to get hung up in
	the IESG later on.

joel
	I really like the word deprecated, you still have something you
	you have to implment because it's a must, but

jeff haas
	For me a protocol specification says what you must do right now.
	projections as to what you might do in the future belongs in the
	non-normative text that surrounds it.

Joel
	The issue for opsec on the question is the extent to which
	providing guidance to implementers is appropriate at all. When
	we come to this as an operator it's mostly a question of
	interoperability  in the protocols I need to run my network.

Chris Lonnvick
	Jeff Schiller's list of crytpo algorithms used the should- most+
	(rfc 4307) language

Joel
	Some level of referntiality might make this more clear.

Gaurav
	Scheme for ospf  crypto authentication is a must.

	Alogrithms selection is similar for isis, a more advanced
	algorithm should be implmentation

	Password authentication becomes a should not.

Rich
	This is pretty much on target, I agree with the chair, that
	there are a number of little things we can comment on. I would
	suggest that the word authentication get up in the title because
	it just says cryptographic protection,  becuase it only deals
	with authentication integrity. there are comments in some of
	these protocols about the need (or lack) of need for
	confidentiality that I reject out of hand because the need for
	it is a function of the operational enviroment not the
	implmentors view of the protocol. if you look in the ospf v3
	spec it says hey, we recomend you do confidentiality because
	it's easy, whereas in these other specs it isn't so we don't. I
	reject that chain of logic.

Joel
	I'll take back the mike, as we have 5 minutes.


	We got a second iteration of the draft kumari urpf document  out
	it incorporates feedback from the list. original version didn't
	make it out in time for dublin so we didn't get commentary on it
	at the previous meeting. we are looking for consensus to accept
	it as a working group document. just to cruise through the
	changes associated with it.

	We have ietf tools we can get all the differences

	(the version number incremented)

	Text altered as a product of feedback no dramatic changes.

	Expansion of the practices documented in rfc 3882

	It's pretty simple, as far as we can tell it reflects reality in
	terms of what operators do today with blackhole communities

	We think this is a good documentation exercise. we will ask from
	consensus to accept as a working group document and hopefuly
	last call it shortly thereafter.

	There's not really much to it.

	Appart from that. other documents that have been discussed or
	might be on the radar

	Michael bheringer's bgpsec requirements draft got discussed on
	the list a little bit, it was presented in Ireland. I think
	there is some opposition to taking on that work under our
	existing charter, I think his goals are sort of incompatible
	with this working group. if there are dramatic differences of
	opinion we can reconsider that .

	With warren we've been discussing the issue of a standardized
	blackhole community which would be a follow-on to the update to
	3882.

	I asked peka about the backbone attacks draft presented in
	Dublin, the working group seemed receptive to at least hosting
	the document. From peka's perspective additional authoris to
	contribute to that doucment would be helpful but I din't think
	that a new iteration is immediately forthcoming.

	That's our current work in opsec.

	It may seem somewhat quiet on this lst but since the last
	meeting we've picked up two working group items and it looks
	like we should be asking for consensus on two more. that is kind
	of a full plate. we have something to show for our work.

	We're about done.

	Thanks!
_______________________________________________
OPSEC mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/opsec