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 
  - 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

Current Practices 
  - 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 

(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

(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

(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




(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

(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