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. 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! These were the items I took away from or found in the previous two sections of the minutes please everyone, but especially Ruddinger Richard and Fernando please comment on anything I might have missed that we need to pose and answer on the list. deadline for submission of the minutes is the 19th so we have a couple days still. * draft-gont-opsec-ip-security-01 Test consensus on list for accepting as a working group document Preference for desired outcome, informational or BCP? Venues for cross area review, where should we socialize it Are there specifica areas that should get special attention? * draft-gont-opsec-icmp-filtering-00 Are we concluded that feedback on structure provided during the wg meeting was sufficient to proceed? Seperate v6 document or not * draft-ietf-opsec-routing-protocols-crypto-issues-00 Does this document need to address pim-sm or rsvp Other substantive comments? Is it ready for last call after another rev? * draft-bhatia-manral-igp-crypto-requirements-03 Accept as a working group document? Issue about language must- should+ etc (proposed change has circulated already) change of title (to include authentication) * draft-kumari-blackhole-urpf-02 Accept as a working group document?