[OPSEC] Draft IETF 77 minutes

[Joel Jaeggli <[e-mail]>]

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.