Attached are draft opsec working group minutes from IETF64 in Vancouver, in both Word and text formats. Please send any comments asap. Those who spoke (whether as presenter or who made comments) might particularly want to check to see if your words were recorded properly. Thanks, Ross
Attachment:
Draft_OPSEC_Minutes_Nov_2005.doc
Description: MS-Word document
OPSEC Working Group
November 8, 2005 18:50-19:50
Thanks to Bill Fenner for taking minutes.
Pat Cain was unable to be in Vancouver, and thus Ross Callon
chaired the meeting solo.
Agenda
(Ross Callon)
1852-1900: document status (R.Callon)
1900-1910: draft-ietf-opsec-filter-caps-00 (Morrow/Callon)
1910-1920: draft-bonica-opsec-nmasc-00 (R.Bonica)
1920-1930: draft-callon-misc-cap-00.txt (R.Callon)
1930-1940: draft-ietf-bmwg-bench-meth-ebgp-00 and
draft-ietf-bmwg-bench-meth-opsec-00 (S.Poretsky)
1940-1950: draft-zhao-opsec-routing-capabilities-00 (M.Fuyou)
Document Status
(Ross Callon)
Framework <draft-ietf-opsec-framework-01.txt>
- was updated to avoid timeout
- a minor update will be submitted soon after the IETF
Survey of Security Efforts <draft-ietf-opsec-efforts-01.txt>
- is stable, in good shape
- no update since last IETF
Packet Filtering Capabilities <draft-ietf-opsec-filter-caps-00.txt>
- Has been updated
- presentation to follow
Current Practices <draft-ietf-opsec-current-practices-02.txt>
- Has been updated
- Modified threat model section
- Added filtering section
- Added some IPv6 information
- Question for working group
- Should Appendix B (protocol specific attacks) have more
details on individual attacks listed?
- Is more detail on IPv6 required?
- Is anything missing
New Documents
- Three new documents have been brought to the working group
- Presentations on each are to follow
Packet Filtering Capabilities
<draft-ietf-opsec-filter-caps-00.txt>
(Chris Morrow's slides were presented by Ross since Chris was unable to attend)
The Packet Filtering Capabilities document was an individual document for two versions (-00 & -01), is now a working group document -00.
We still need to link the capabilities in this document with Merike's document on current service provider practices.
Question (from Chris Morrow, in the slides): Do we want more relating to packet filtering with MPLS? Ron: We don't want to filter on labels, since they change so dynamically would be hard to configure the filter might want to not accept filters that you haven't advertised. Ross: In principle you might want to look past the MPLS header; but if you assume that there is an IP header and it's not IP after MPLS then you might filter incorrectly.
Network Management Access Security Capabilities
<draft-bonica-opsec-nmasc-00.txt>
(Ron Bonica)
This document covers in-band management capabilities, out-of-band management capabilities, and virtual-out-of-band management capabilities.
In-band: Securing management against paths shared with users.
Out of Band: NM functions never shares paths with users, so can protect via interfaces. More secure. More expensive.
Virtual oob: l3vpn with router interfaces and NMSes inside the VPN
Ron compared and contrasted the approaches (see slides)
- Virtual oob has some aspects of In-band and some of oob. Isolates but
also shares fate.
This document is intended as a starting point. We hope to move it forward as WG document.
Ross: Group: how many people have read it?
- only a handful
(Ross, speaking as an individual): I read it, good start, not done, I have some comments to send.
Ross (speaking as a chair): Looks like there aren't enough people here who read it
Darryl Lewis: concept very reasonable for this doc (haven't read it)
- Have you considered other standards documents that talk about this, ITU 3016? doing access control for mgt plane? Some parallel efforts.
- Another level of oob beyond building another network, such as console access
Ross: Other than that there aren't enough people here who have read the document to say what the *wg* thinks, are there any objections to making it a WG document? No.
Peter Thermos(?): I read it 3 weeks ago; good start; should be synergy with some of the existing standards stuff including ITU; should be distinction from management plane as telcom defines it and maangement for day-to-day tasks.
Miscellaneous Capabilities
<draft-callon-misc-cap-00.txt>
(Ross Callon)
Mostly this document contains material from RFC3871 that don't belong in other documents which are explicitly called out in the WG charter.
Issue: MUST, versus SHOULD, versus MAY. As an example, the NRIC best practices include preparing for ocean storm surges - this not particularly relevant in Alberta, Canada. A particular practice may not necessarily be applicable in every case. In the same sense, these capabilities might have their own importance depending on the environment. Thus I put text in to say that MUST/SHOULD/MAY are to be interpreted within the context of the capability.
Darryl Lewis: I really like this paragraph; in reading the control plane document I found that the benefit of a given capability is under debate; don't want to say you SHOULD use encryption ignoring its downsides, so something like this is appropriate.
The document discusses Route Filtering (as distinct from Packet Filtering, which is covered in another document). This was largely taken from 3871.
The document also contains some discussion of prioritizing control plane tasks (this is extended from the brief text in 3871). There might be some conflicting views on performance and prioritization - a/ you can suffer from not doing this, but b/ we don't know for sure what the state of the art is, which aspect of control plane operation do we prioritize above another one, etc. Therefore I put most of this in as SHOULDs rather than MUSTs.
There is also a section saying "Security Features must not cause operational problems". This is taken directly from 3871. Should we leave this in or take it out? Seems self-evident, although also correct.
We also need to tie this stuff in with Merike's current practices document.
Propose WG doc. Are there additional comments? (no) How many people have read it? Not enough to decide to take it as WG document. As before, other than that there aren't enough people here who have read the document to say what the working group thinks, are there any objections to making it a WG document? No.
Accelerated Stress Benchmarking
<draft-ietf-bmwg-acc-bench-term-07.txt>
<draft-ietf-bmwg-acc-bench-meth-04.txt>
<draft-ietf-bmwg-acc-bench-meth-ebgp-00.txt>
<draft-ietf-bmwg-acc-bench-meth-opsec-00.txt>
(Scott Poretsky)
Although these documents are in the BenchMarking Working Group (bmwg), you'll see how these are directly related with what's going on in opsec.
These documents describe methodologies to ensure that devices are meeting conditions in opsec docs.
- deployed environment:
Instead of testing one feature at once, test under real conditions
- failure conditions:
Do bad things to the router, see how it works.
- routing:
Do bad things to routing
- manageability under stress:
Stress it, does management still work?
- sw bugs:
memory leaks, etc - this kind of testing finds bugs.
- ability to survive DoS attacks:
this testing *is* a DoS attack
The terminology and general methodology documents are close to WG last call in bmwg, so it's time to look at them from here. (and please send comments)
See slide 5, Stress Test Methodology
Ross: Q: (refering to slide 5): Is there normal operation phase between 1 & 2, and then after 3? A: kind of, except startup conditions are typically more than normal operation would provide.
See slide 6, Example Stress Test benchmarks
Ted Seely: I assume this is only for informational purposes - is it wise to say that a box is RFCxxxx-compliant where the requirements are constantly changing?
A: We don't say RFCxxxx-compliant
Ted: But it'll be an RFC! The environment will always be changing!
Ross: The document creates guidelines, not a set of tests
Scott: We shouldn't discuss here whether bmwg should be doing RFCs.
Ted: We're saying what the benchmarks are, then people will claim that they conform to them, and that's a slippery slope.
Ross: That's a topic for bmwg
David: I think you guys agree more than you think. bmwg is somewhat of a slippery slope. It has a carefully worded charter; read it and you'll see the limits to prevent getting too close to the slippery slope.
Peter Thermos: good baseline for survivability - but 1. when we compare 2 devices, why do we need to compare them? 2. looking at amplification and flooding attacks, there's another class of attacks like single-packet attacks - one malformed SIP packet and the service or device blows up - should we add capabilities for this? Perhaps there's a mechanism to identify that addresses this type of thing in the future.
Scott: Malformed packets are an important topic. Methodology is an open question for this but it should be considered.
Ron Bonica: You have a set of interesting parameters; they indicate how vulnerable a system is - are you asking us for more parameters, or saying that more is coming?
Scott: asking you for more! great!
(name not recorded): The methodologies are interesting; Too often we're thinking about steady state and it's nice to see worst case being thought about.
Control Plane Security Capabilies
<draft-zhao-opsec-routing-capabilities-00.txt>
(Miao Fuyou)
- see slides
Ron Bonica: 1. on Authentication - at NANOG, I learned that many operators don't authenticate BGP because of CPU utilization. Someplace under authentication, mention CPU meltdown attack. 2. on filtering capabilities - some of these items are for routes, but TTL / Hop Limit looks like for packets / forwarding plane issue.
(name not recorded): responding to Ron: might make use of the TTL hack e.g. GTSM
(missed one comment)
(name not recorded): There are lots of items in this document that say "you SHOULD do this", where an operator might have its own priorities - maybe these should be capabilities and the imperatives should be relative to capabilities.
Ross: Wearing my document author hat: This document covers a wide area - perhaps include some things that are missing from the miscellaneous capabilities draft - some of this may apply to the packet filtering document - so should we use this document to see if we missed anything from the wg-chartered documents? First we should figure out where all the text goes, and then acknowlege you or make you a contributor or co-author in each document (depending upon how much text we end up using).
Miao: That makes sense.
End of Working Group Meeting