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.
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
1940-1950: draft-zhao-opsec-routing-capabilities-00 (M.Fuyou)
- was updated to avoid timeout
- a minor update will be submitted soon after the IETF
Survey of Security Efforts
- is stable, in good shape
- no update since last IETF
Packet Filtering Capabilities
- Has been updated
- presentation to follow
- 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
- Three new documents have been brought to the working group
- Presentations on each are to follow
Packet Filtering Capabilities
(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
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
This document covers in-band management capabilities,
out-of-band management capabilities, and virtual-out-of-band
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
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
- 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.
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
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
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
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
- failure conditions:
Do bad things to the router, see how it works.
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
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
Ross: The document creates guidelines, not a set of tests
Scott: We shouldn't discuss here whether bmwg should be
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
Scott: Malformed packets are an important topic.
Methodology is an open question for this but it should
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
- 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
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