Subject: Draft IETF 77 minutes From: Joel Jaeggli Date: Mon, 12 Apr 2010 19:13:51 -0700 To: "'opsec@ietf.org'" Thanks to the efforts of Joe Abley and the jabber room posters. Appologies for the the delay, the credit for that is all mine. Tue 23 Mar 2010 17:39:47 PDT opsec, IETF 77 note-taker joe abley chairs joel jaeggli, joe abley 0. Agenda 1. achievements since ietf 76 (slides presented by joel jaeggli) 2. document status re: raft-ietf-opsec-ip-security: ron bonica: for draft-ietf-opsec-ip-security, we might want to also ask for review in the ops area. re: draft-ietf-opsec-routing-protocols-crypto-issues: ron bonica: I don't know who the expert reviewer is for draft- ietf-opsec-routing-protocols-crypto-issues ron bonica: BGP/MD5 will be obsolete in a day or two, section 5.2 of the draft talks about BGP/MD5 joel: we should revisit that re: draft-ietf-opsec-igp-crypto-requirements rich graveman: if people are using md5 for security and they have nothing else, and they read this document and turn it off, that's probably bad joel: the document does attempt to call this out ... joel: what to do with this document before last call? ron bonica: I think the section on BGP needs to be re-thought. joe touch: see a handful of documents that are having a rough time in tcpm. is there any coordination going on between the two areas? it seems that things are doing end runs here. specifically icmp-filtering. don't understand why we need another document on that. ron bonica: rationale is that many ISPs block ICMP messages. There are some ISPs that let everything through. Others let some through, e.g. for pMTU discovery, but others they drop. what I wanted was a discussion for each ICMP message to allow an ISP to make informed decisions. joe touch: some decisions are being made on what has been deployed, opinions of some individuals. had this discussion in tcpm. this document shouldn't repeat that discussion; it should refer to the tcpm discussion. second thing, why and whether it's appropriate to check the contents of icmp messages, check checksums, check fields inside. example: check sequence number. routers have no requiremnt to respond to icmp in a timely fashion; this can trip things up. worried about whether we are delaing with this set of issues in completely separate wgs that don't talk to each other. joel: some danger of that. would observe that we have gone back and forth in this wg as to whether a document like this should be prescriptive. consensus of the wg was that it was more important to characterise what you would lose by filtering than whether you should filter. ron bonica: first, agree with joe touch re referencing rather than reiterating. we should reference when we can. second, we should probably send the doc for external review, and send instructions for reviewer. document's goals are to explain what you lose if ou filter, what you risk if you don't filter, let the operator make an informed decision. what we want is for him to make an informed decision. joel: re original charters, pushing security requirements on vendors and by extension their customers tends not to be popular. if driven by application requirement that's great, but simply saying this is the way you should build your equipment and you need this features is not an easy sell. not something that I could have taken back to my then employer, for example. joe touch: is that the intent of most documents here? I can see some of that coming out. ip security document has recommendations splattered all over the place and some of htem are insane. joel: ... joe touch: that document contains things that are insane. this speaks poorly to the competence of the working group. e.g. saying that everybody should always block LSR, that's insane. "a packet you did not expect is not a threat." the end state is that everybody will have to run their protocols over HTTP. joel: firewalls apply policy to unsolicited packets. that's what they do. in the context of icmp filtering, the document characterises the consequences of applying that policy. ron bonica: couple of words about our charter. this is an ops area wg. because we're in the ops area we don't get to change protocols, ever. we don't get to deprecate ip options. what we can discuss is whether an operator... we can talk about threat models, and we can talk about what those features offer than an operator would lose if he filtered them. give oeprators information so they can make informed decisions. joel: in the context of LSR for example, as a strawman, I think it's entirely reasonable to say these are the consequences of carrying them. david borman: co chair for the tcpm wg. on lsr, those options have been an issue from the early days and the main reason is that implementations ignore them. I think the cat's out of the bag on those, that trying to say that you shouldn't block those -- I don't think we can ever resurrect those the way they were intended. in general though, e.g. icmp filtering, it would be great to get it passed through the tcpm wg. glacing through it I noticed a lot of TBDs. joel: yes, the section is not complete yet. difficult for it to make progress when contributions have not yet been incorporated, when the doc is not yet finished. david: some people in the tcpm wg could help fill in some of those TBDs. joel: that would be helpful. david: suggest the doc be sent to the tcpm wg as a working draft and ask for contributions and review. joel: additional authors would be very welcome. joel: you guys have the tcp security assessment being socialised in your wg? david: fernando's tcp document we have that in tcpm wg and tomorrow morning we are having a separate session at 1015-1030 in pacific a to walk through that document to identify those items that we feel are non-controversial. goal is to move that document forward. very much like the format of hte icmp filtering draft. 3. new work draft-dugal-opsec-protect-control-plane-02 (david dugal presenting from slides) rich graveman: have not read the whole doc. don't see you talk about using security technology where we have it, e.g. it doesn't refer to OSPF with SHA1 integrity protection. no DNSSEC. you don't use security! david: in our initial design we wanted to limit the scope to just control plane filters, e.g. lo0 filters in JUNOS. That's not to say there shouldn't be additional recommendations. please mention that on mailing list or by private mail. ron bonica: I think much of that stuff is out of scope for this document. it may be that we want to do another document on the applications we run upon the control plane. but this draft is drawing attention to the firewall beteween the control plana and the data plane. rich graveman: this draft contains no security! chris morrow: no. there is a place for use of crypto in routing protocols, for dns hygeine, but this draft's purpose is controlling who can talk to my router. rich: but using keys, not ip addresses! chris: no [etc] (much animated discussion, following some agreement that this is a conversation that can happen on the mailing list.) brian wise: draft says protect your control plane and gives some some examples, so I don't think BCP. I think it woudl be valuable though if the document contained specific advice for (e.g.) BGP-speaking routers. joel: personal opinion is that to the extent it's possible vendor- specific examples should appear in appendices. david: the more specific we get to a particular network design the less relevant it becomes to other ones. but there are some key roles that might be worth considering. rich graveman: GMPLS, CCAMP, when they say control plane they mean something different. I understand you're talking about the IP router control plane. the phrase "control plane" is a little overloaded. ron bonica: the words "control plane" are applicable. these things are all control planes. rich graveman: correct, was suggesting the scope be reduced. joel: think there's room to iterate on scope. danny mcpherson: this is more about access to the devices, rather than the protocols themselves. but this about route processor handling in network devices, that's the primary motiviation, to protect these things. this is about access to those devices. but also infrastructure ACLs at the network perimeter, etc. perhaps also belongs here, or maybe a separate document. david: we did think about that, but we also wanted to focus this document on protecting the control plane rudiger volk: router control plane might be a better phrase george: haven't read draft. when we implemented these layers of protection in our network we spent time categorising what was hitting the box to start with. this allowed us to characterise the traffic, iterative process of refining. perhaps instead of specific examples, describe a methodology. characterise traffic so you know what you care about. any bcp that talks about protecting the control plane definitely has to talk about that characterisation step. warren kumari: should consider the audience of the document. document describes the architecture of a router, then jumps to "let's make a filter". If it's going to start that basic, it ought to provide more guidance for *how* to derive suitable filters. david: intent was to keep it introductory. concern I had was the routers in the world that are completely unprotected. warren: but unprotected routers are probably run by people who don't know *how* to filter. chris: some of what richard brought up earlier, e.g. optical platforms, GMPLS, etc. nice if we had same protections not just for routers and switches but also for layer-1. Optical vendors have a lack of appreciation for this. it would be nice if whatever came out wasn't completely router-only. nothing there that couldn't be used to support a requirements document for other types of equipment. joel: this doc generated some healthy discussion in the room and on the list. suggests people have read it. makes me want to ask some questions. who in the room has read it? [ten hands or so.] joel: anybody have an opinion on accepting this as a wg document? the list is the final arbiter. wes george: I believe this should be a wg doc. warren: me too rich: me too, 100% joel: we will take this an action item after this meeting to poll the list for adoption. thank you. warren: what about bcp vs. informational? ron: I'm not going to give an opinion, but friendly advice. info is much easier than bcp. bcp is a club for beating other document authors.need to assess whether you need that club. danny: referencing rfc 1812 might be useful. provides some terminology. david: we reference a section of 1812 but we could look at expanding it. 4. any additional agenda items (no other business) joel: that concludes our programme.