Re: [OPSEC] Draft IETF 77 minutes

since there are been no corrections to the minutes I will submit them as
final.

Thanks
joel

On 04/12/2010 07:13 PM, Joel Jaeggli wrote:
> 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.
> 
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec
> 