Subject: [OPSEC] minutes part 1

From: Joel Jaeggli <[email-masked]>
Date: Sun, 07 Dec 2008 17:42:40 -0800

Sorry the minutes were something of a hash so I greatly expanded them
with the assistance of the recording. the downside being they took
longer to produce. this is part one which covers the first two
presentations. part the second is underway

opsec

minutes

introduction

Joel Jaeggli
	agenda bashing rough outline

	status update on working group

	Dublin
		consensus affirmed on working group charter

		ICMP filtering and blackhole filtering update documents
		considered basis of new work

		3 active documents now an improvement over zero

		additional interesting work, but we've gone from no
		longer on it's last last legs
		to having interesting work to do.

		Fernando presenting 2 documents, one accepted in Dublin
		the other new work brought from
		outside.

Fernando Gont

	Security Assessment of the Internet Protocol version 4

	First time this document has be presented at an IETF meeting

	Problem statement
		no single document that presents the security
		implications of the ipv4 protocol in total. considering
		there are no official documents that discusses this
		problem in total with the result that new
		implementations repeat them.

	In 2005 the UK CPNI decided to change this state of affairs by
	starting a project that was a project to study the security
	implications of the ipv4 protocol  implementations.

	one of the goals of this project was to provide a bibliography
	as to what was being done about some of the problems that were
	found.

	analyse the security implications of the ipv4 header fields and
	ipv4 mechanisms.

	 As a result the document produced is ~60 pages with close to
	100 references to specifications and relevant papers

	Published as part of CPNI's process, now we want to take the
	results to the IETF so that these results are part of the
	official documents. been working on this  document for almost
	two years.

	Many vendors involved in review in CPNI

	We think this document is important to the IETF, fills a gap

	Do you think this document should be adopted as a WG item.

Richard Graveman

	It's such a pretty document why do you want to publish an ugly
	text version (slightly in jest)

	Is the IETF going to help make this better?

Fernando

	some time involved, but it's important that the IETF document
	train reflects work in this space.

unknown
	alternative versions are possible

Joel
	XML version can generate text version

Ron Bonica
	Not so much about format, we specified IP, this is where IP
	lives we have a lot of inherited wisdom, but it's really not
	documented in one place we should do it here.

Richard
	Ron I agree with you 100% and format was a jest. the point I'm
	trying make is are we being asked to rubberstamp this report or
	take the wisdom that we have as part of this  community and see
	if we agree and maybe we can improve it.

Fernando
	The reason it was published as an ID was to ask for comments and
	incorporate comments. could differ from CPNI Document.

Chris Lonvick
	This came up in security directorate lunch and there should be
	enough people to review it.

Joel
	Ask for cross area review if we accept it.

	probably valuable input that could be added to it.

Richard
	given those statements I'm fine with it.

Fernando
	In addition to what Joel said the document is is meant to be
	updated from the version that CPNI published.

Ron
	Informational vs BCP? if you're going to ask for cross area
	review then BCP might be the way to go.

Fernando
	could even go for proposed standard but that's a harder hurdle
	for the  document to get over

Ron
	at this point it doesn't make a difference. if you want it to be
	BCP it needs an IETF last call

Fernando
	may not matter what category the document is in. the high order
	bit is that it should be published and  that the high order bit
	is that it should be published and the IETF should provide
	advice

Joel
	thanks, you have another document obviously but presuming we
	have enough people in the room who  have read it we should be
	able to ask if there's  consensus to adopt as a working group
	document.

Ruddinger Volk
	Sorry for being spoil sport, my understanding is that in opsec
	we are concerned with the operational  security. We have boxes
	that might suffer from the problems that you are discussing but
	I am concerned assuming that the people who are adequate for
	discussing the implementation of IP are exactly the same as
	those  working on it's operational security.

Joel
	I think if we were  doing implementation that would be more of a
	problem then if we were attempting to  a get a read of how it
	works today.

	You probably don't want to look at a document that came out of
	here for implementation advice for a Protocol. you might look to
	a document that came from here for guidelines as to how to use
	it. the former is clearly out of scope for this wg. do you agree
	with that reading?

Ruddinger
	I would think so, but not having read the document I cannot
	point out that it's sounds like it is implementation details.

Fernando
	some of the elements cover implementation details but much of
	the stuff covers how you use the protocols for operations.
	sometimes for example you might build an ids signature around it

Joel
	for example this document references rfc 815, in doing so it
	doesn't suppose to tell you how you put together ip datagrams
	but rather tha implications of what you already have. That may
	be a semantic distinction, but if it is it is a fairly big one.

	anyone else have commentary?

	how many people have read it for reference

(about 4 hands).

	I don't think that's enough in this room to ask for consensus to
	take it as a working group document but we can take that but to
	the list. and we can flag these issues as things the we need to
	address in deciding if this is a working group document. my
	personal opinion is that part of the problem we actually face
	here is that no one has actually done a document quite like this
	is that scope is larger than a particular  working group except
	maybe the security area as a whole, so the fact that we have a
	willing victim to produce a document that's this big is
	something that we should take advantage of if it will produce a
	document that actually useful.

	If we do decide to accept this document we should seek input for
	the security area.

	We'll take this question to the list

Fernando
	The next document is the icmp filtering document

	There were a couple of issues that I had written on the mailing
	list a couple of months ago they were mostly about the structure
	of the document.

	right now for each of the icmp messages we have 4 sections.

	message type
	usage
	threats - security implications
	operational impact if blocked.

	It's a big document

	We wanted to get agreement on the structure of the document,
	very little input on the list, but we want agreement before we
	update the document.

	So that in three or four months somebody doesn't request changes
	to the document structure.

	Some discussion of expansion of blocking to cover the scenarios
	of blocking messages from a device to a device or through a
	device.

	We'd like to agree on all these issues before it's to late

richard
	I'll make a suggestion for shortening the document, 4443 my
	comments are all about v6. rfc 4443 specifics some icmpv6
	messages but not all of them. you'll find the iana page
	references 10 other rfcs.

	So if you're trying to filter icmpv6 you're going to find a lot
	of things that this document never consdiers.

	that would be a huge amount of extra work that would delay the
	document quite a bit. on the other hand to the rescue the is
	another working group in this area (v6ops) that wrote an rfc
	called 4890 recomendations for filtering icmpv6 and that's not
	referred.

	So my suggestion would be to rename this document
	recommendations for filtering icmpv4 take all the icmpv6 stuff
	and go match that material  with 4890 and see if 4890 needs to
	be revved (in a separate document)

Fernando
	Right now there are lots of sections that still have to be 	
	populated.

Richard
	It doesn't have a placeholder for these other messages it
	pretends that it has them all.

	I sent you an email 6 months ago and on the list 3 months ago
	mentioning this topic.

	I have strong problems with the icmp6 section because it is
	incomplete.

Fernando

	The document is incomplete because the structure has yet to be
	determined I don't want to get several months down the road and
	decide that the structure needs to be changed.

	I think it was Donald Smith who provided the from to or through
	language.

	So we are not actually arguing about the contents, so I don't
	want to waste a lot of cycles until the high order bit
	(structure) has been set.

Ron Bonnica (as an individual)
	Richard reminded me of something interesting. if you go to that
	same IANA page you'll find a bunch of really goofy icmp messages
	that nobody ever uses. that are defined in some really strange
	drafts.

Joel
	Can we make normative references to the iana assignment pages.

Ron
	They always point you back to some other rfc that noone has ever
	read.

	At least for v4 theres a small additional task to take care
	of...

	For v6 there are two distinct questions

	Have we hit all the message? probably with a little extra work 	
	we could at least put in boilerplate to get all the messages

	The next question is do we have the same level of operational 	
	experience with v6 as we do with v4? with v4 we're ready to
	publish this document as a bcp with an awful lot of authority.
	With v6, maybe informational.

	So that might actually be argument for splitting the documents
	into a v4 bcp and a v6 one informational that needs to be
	socialized in v6ops until enough people have deployed v6
	networks so that we really do understand security issues that
	will appear?

Joel (rhetorically)
	yeah does anyone actually have operational experience with fmip
	v6? that's the most recent addtion to the iana ipv6 messagee
	types.

	I think there are some more icmpv6 message types that are in the
	queue that haven't arrived yet, and speculation as to how
	they're going to be abused once deployed is probably a little
	early.

	There's some interesting feedback here:

	I get the impression that people are not unhappy with the
	existing structure.

Richard
	4890 takes a different approach one would at least want to know
	why one approach was chosen over the other.

	The approach in 4890 is that some messages mush always be
	blocked, messages that should never be blocked, and judgement
	cases. it takes the point of view of the filter, sort of the
	inverse structure

	Talk to the author of the other as to why that tack was taken.

Joel
	One of the lessons to take from ipv4 is that even if you tell
	someone never to block a particular kind of ICMP message they
	will choose to  do that anyway. So, the tone that this document
	takes is that when you shoot yourself in the foot, this is what
	is going to happen. that is a more realistic tack to take in v4
	because we know people are going to filter all of these because
	they do. whereas in v6 we should be  saying, when you do your
	implementation you really shouldn't be filtering these because
	you need them to work.

	10 years from another document will come along that says when
	you shoot yourself in the foot with icmpv6 this is how youo did 	
	it.

Richard
	yeah another reason to separate.

	when I read the document the v4 section is much better.

Joel
	This is good criticism. it produces some actionable exercises. 	
	either the relationship to icmp6 messages in totality needs to
	be clarified. Or perhaps that section needs to be split off. I
	don't think that would produce dramatically more work.

	Philosophically it makes it somewhat incomplete since it doesn't
	deal with the totality of icmp but maybe that becomes a second
	draft.

	I think we can pose that question to the list and see if there
	as strong opinions.

Fernando
	There is is the question  of from to or through.

Joel
	ok

	You're right and putting more meat on the document is dangerous
	without clarifying that

Fernando
	we'd like feedback on the structure before spending more cycles
	on filling in sections.

Joel
	the criticism of whether it is incomplete vs whether v4 and v6
	are treated simultaneously is a fairly high level meta question

Danny Macpherson
	I think it's fine to not specify what to do with some
	messages. I think it's worth having a table to which lists the
	messages we have recomendations for and those which we do not.

	To Rons comment I think It's a terrible idea to say filter these
	things because we don't think anyone uses them.

	In agreement with don smiths distinction between end and
	intermediate systems.

	I would also note that the icmp6 document richard was referring
	to is icmp6 considerations in firewalls. which is a middlebox
	but it is not a router.

Ron
	In my experience most operators filter all icmp messages except
	for the ones that they know they need.

Danny
	In securing the control plane they do but not across the network 	else.

Ruddinger
	I think I can confirm. But default firewall policy tends to 	
	allow only things we know about.

Joel
	That certainly applies to controll plane processors

Danny
	So that's the distinction that's iportant the distinction
	between to the device and through the devices in the network.

Joel
	I think that speaks to the host nature of control plane
	processors, when you have host exposure you apply policy there.
	With control plane processors you have basically every kind of
	resource starvation opportunity imaginable as long as you're not
	filtering.

Melinda Shore
	In terms of filtering the people who are throwing all kinds of
	ICMP messages, the further you go towards the edge of the
	network the more likely you are to see that. certainly you see
	that in enterprise networks

	The thing that concerns me about the recommendation is that it's
	kind of meaningless security practice and I'm not sure we want
	to support that.

Joel
	That's the nature of responding to things, like oh you decided
	to filter path mtu messages, or you decided to rate limit them
	because they were causing to you resource issues. That doesn't
	help it's the same as breaking them completely. I think that's
	the part of the document that works quite well at this point is
	pointing out what happens when you do that.

	I'm not sure that it needs to address that down to the level of
	through vs delivery to a particular system.

	The consequences of filtering it are the same.

Fernando
	So you're basically saying that the document can stay as is?

Joel
	yeah I think so, I mean I think we should probably test the
	mailing list for that. my sense is that we already deal with why
	it is that people were choosing to filter something or what they
	got by not filtering it.

	Is that seen as sufficient?

Danny
	I think so, but Don has a point people do all sorts of things
	in the name of control plane policing but that's perfectly fine
	but it's different than through those middle boxes to end
	systems.

	Maybe have a security considerations section say that people
	operating operating middle-boxes may have different policy or
	employ a more explicit policy than open end-to-end networks.
	I'll take a stab at kicking this topic off or sending a little
	bit of text.

Fernando
	So, you don't think we need different subsections, but rather
	just a statement in the document?

Danny
	I think it's fine to have those considerations in there but it's
	going to vary as to what policy is appropriate for protecting
	the control plane. if you're going to make that distinction it
	going that have different implications on different devices.

Fernando
	ok

Merike Keio
	I agree with Danny. I've read the v6 document and it's makes my
	head spin who to from how what when. Really enumerating what
	they're used for and have some more general statement you know
	be careful of this but not have all the different
	considerations.

Richard
	A lot of the impetous for filtering icmp came from icmp messages
	of inconvenient length turned certain operating systems displays
	blue.

Ron
	When I first though about the statement from to or through I
	though it was overkill until the misunderstanding that danny and 	I
just had. If you are an endpoint the filter that ruddinger
	suggested, filter everything except what I know I need is
	reasonable. if you are a transit router the filtering policy
	danny suggest is reasonable....

Joel
	Right it's good to have that distinction and consider that.
	knowing that you're going to shoot yourself in the foot by
	breaking say path mtu discovery is something that you will
	choose to do in order to protect a resource just as you will 	
	with a firewall. This is the implication of blackholing that
	packet and I'm comfortable with that so I'm going to do it
	anyway.

Ron
	I can think of one you might want to block if you're an endpoint
	but let through if you're a router.

Danny
	Even if you filter things to you, as part of control plane
	policing. That doesn't mean you'll break path mtu discovery
	though the box.

Joel
	Right my control plane processor is only talking to things that
	are explicitly configured. So, I decide that I'm throwing out
	all sorts of icmp messages, because my default policy is deny
	and I only open it for things I need to connect to.

Danny
	Yeah I understand your point.

Fernando
	that's it

Joel
	So, this is already a working group document, I have notes on
	things we need to take back to this list so I think we should
	move on to our next speaker.
_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec