Subject: [OPSEC] charter skeleton rev5

From: Joel Jaeggli <[email-masked]>
Date: Wed, 09 Jan 2008 15:47:02 -0800

This version incorporates comments from:

Ron Bonica
Danny McPherson
Dan Romascanu
George Jones

----

Goals:

The OPSEC WG will document best current practices with regard to network
security. In particular an effort will be made to clarify the rational
supporting current operational practice, address gaps in currently
understood best practices for forwarding, control plane, and management
plane security and make clear the liabilities inherent in security
practices where they exist.

Scope:

The scope of the OPSEC WG is intended to include the protection and
secure operation of the forwarding, control and management planes.

Documentation of best common practices, revision of existing operational
security practices documents and proposals for new approaches to
operational challenges are in scope.

Method:

It is expected that the work product of the working group will
fall into the category of best current practices documents. Taxonomy or
problem statement documents may provide a basis for best current
practices documents.

Best Current Practices Document

For each topic addressed, a document will be produced that attempts to
capture current practices related to secure operation. This will be
primarily based on operational experience. Each entry will list:

* threats addressed,

* current practices for addressing the threat,

* protocols, tools and technologies extant at the time of 	
writing that are used to address the threat,

* the possibility that a solution does not exist within existing tools
or technologies.

Taxonomy and Problem Statement Documents

A document which attempts to describe the scope of particular
operational security challenge or problem space without necessarily
coming to a conclusion or proposing a solution. Such a document might be
a precursor to a  best common practices document.

While the principal input of the Working Group are operational
experience and needs, the output should be directed both to provide
guidance to the operators community as well as to Working Groups that
develop protocols or the community of protocol developers at large, as
well as to the implementers of these protocols.

Non-Goals:

The Operations security working group is not the place to do new
protocols or requirements documents.

New protocol development or requirements work should be addressed in a
working group chartered in the appropriate area or as individual
submissions. The OPSEC WG may take on documents related to
the practices of using such work.

_______________________________________________
OPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/opsec

---

From: George M Jones <[email-masked]>
Date: Thu, 10 Jan 2008 06:16:05 -0500

rev5 looks good.

Now I think we need to try to flesh it out with 3-4 proposed documents 
to see if it works.

---George Jones

---

From: Ron Bonica <[email-masked]>
Date: Thu, 10 Jan 2008 09:43:26 -0500

I agree. Once we have done that, I will take it to the IESG.

                           Ron

---

From: Joe Abley <[email-masked]>
Date: Thu, 10 Jan 2008 11:39:11 -0500

> I agree. Once we have done that, I will take it to the IESG.

Apologies for my extensive silence on this thread. Sick children,  
vacation detox, etc.

Rüdiger Volk and I have been talking for some time about writing up a  
way for customers to signal their desire to send blackhole routes to  
their ISPs (long-prefix routes with particular community string  
attributes which cause traffic with destinations covered by the route  
to be null-routed upstream of the customer). The mechanism that Rüdi  
devised used RPSL/RPSS. If the wg (with more details) found such a  
thing to be relevant to this charter, we could probably pick that up  
here.

There was some earlier talk about writing up some best practices  
relating to ICMP filtering, I believe?

Joe

---

From: George M Jones <[email-masked]>
Date: Thu, 10 Jan 2008 12:25:02 -0500

> relating to ICMP filtering, I believe?
I took a stab at starting something

    http://www3.tools.ietf.org/wg/opsec/trac/wiki/ICMP%20Filtering

It's a wiki.   Other people are welcome/encouraged to contribute.

I am going to poke a few people who have done some writing on the
subject to see if anyone wants to be the "editor" (e.g. filter what
everyone does to the Wiki).

---George

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 10 Jan 2008 09:51:50 -0800

Joe Abley wrote:
> attributes which cause traffic with destinations covered by the route to
> be null-routed upstream of the customer). The mechanism that Rüdi
> devised used RPSL/RPSS. If the wg (with more details) found such a thing
> to be relevant to this charter, we could probably pick that up here.
> 

There is also tina bird's effort to produce a taxonomy of events that
should be logged. I don't think all of it is in scope for this working
group (end systems) but some of it likely is.

---

From: John Kristoff <[email-masked]>
Date: Thu, 10 Jan 2008 12:31:34 -0600

On Thu, 10 Jan 2008 12:25:02 -0500

> It's a wiki.   Other people are welcome/encouraged to contribute.

My standard advice is to by default allow a subset of ICMP types (all
codes), local rate limit policies CAN be used, but should not be set
by default:

  icmp type 0 (echo reply)
  icmp type 3 (destination unreachable)
  icmp type 8 (echo)
  icmp type 11 (time exceeded)
  icmp type 12 (parameter problem)

On hosts and some networks I've configured, I've filtered all others,
but that may not be a good universal default.  Perhaps for certain end
hosts or certain types of devices it may be.  I've also implemented
rate limits for allowed ICMP types.  I've had good luck in not running
into trouble doing that, but again it probably shouldn't be the default.
I tended to set a global ingress subnet of approximately /24 maximum
hosts to about 2% of the max router interface bit rate for all ICMP.

John

---

From: George M Jones <[email-masked]>
Date: Thu, 10 Jan 2008 13:42:47 -0500

John Kristoff wrote:
> My standard advice
Go edit the wiki !

Maybe add this to an "experiences" section ?
>
> is to by default allow a subset of ICMP types (all
Add a section/advice on rate limiting ?

---George

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 Jan 2008 15:42:11 -0200

>everyone does to the Wiki).

I'd be glad to volunteer. I have authored the "ICMP attacks against 
TCP" (draft-ietf-tcpm-icmp-attacks) and "TCP's reaction to soft 
errors" (draft-ietf-tcp-soft-errors) of the TCPM WG, and have 
co-authored a (yet unpublished) "ICMP roadmap" IETF draft. Have also 
helped with NISCC VU#532967.

Kind regards,

--
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 Jan 2008 15:48:34 -0200

>>   icmp type 12 (parameter problem)

It might make sense sense to include some recommendations for 
stateful firewalls. (e.g., any ICMP message meant for a TCP 
connection should have an entry in the state-table of the firewall). 
IIRC, some firewalls (e.g., OpenBSD's PF) even check the embedded TCP 
sequence number and let the ICMP error through only if it's within 
the receive window.

Kind regards,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 Jan 2008 16:12:44 -0200

>Add a section/advice on rate limiting ?

BTW, this might be of interest: 
http://www.gont.com.ar/papers/filtering-of-icmp-error-messages.pdf . 
It describes ingress- and egress-filtering of ICMP error messages.

Kind regards,

---

From: "Smith, Donald" <[email-masked]>
Date: Thu, 10 Jan 2008 14:08:49 -0700

If I understood it correctly this groups charter it is for network
operations aka ISPs or SPs.

In general network operators do not run statefull firewalls in front of
their network elements.
If this is going to be applied to enterprise networks then I would
agree. 

Security through obscurity WORKS against some worms and other tools:)
[email-masked] giac

> -----Original Message-----
> From: Fernando Gont [mailto:[email-masked]] 
> Sent: Thursday, January 10, 2008 10:49 AM
> To: opsec wg mailing list
> Subject: Re: ICMP filtering (was Re: [OPSEC] charter skeleton rev5)
> 

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 Jan 2008 18:18:26 -0200

>operations aka ISPs or SPs.

Didn't check the charter... just thinking out loud. But given that 
there's no other RFC on ICMP filtering, it might be worthwhile 
considering adding some text on the subject. (It's up to the group, though).

>Security through obscurity WORKS against some worms and other tools:)

?

Kind regards,

---

From: "Smith, Donald" <[email-masked]>
Date: Fri, 11 Jan 2008 14:36:21 -0700

I thought at one point this charter included scoping that addressed type
of network specifically ISP vs enterprise.

SP networks tend to be more complex, larger and carry more protocols
then an enterprise network.

I think there are major differences between the two especially from a
security pov.

01100101000010|10011010111101?
Hint 7 bit ascii
[email-masked] giac 

> From: Joel Jaeggli [mailto:[email-masked]] 
> Sent: Wednesday, January 09, 2008 4:47 PM
> To: [email-masked]
> Subject: [OPSEC] charter skeleton rev5 
>

---

From: Joe Abley <[email-masked]>
Date: Fri, 11 Jan 2008 16:57:20 -0500

> then an enterprise network.

Amusingly, this is precisely the reverse of what I have always thought.

In past lives I have had to wrangle enterprise networks in which SNA,  
SMB, IPX/SIX and IP traffic had to coexist, all at high (for the time)  
speeds, through a mixture of ethernet and token ring with  
corresponding MTU hilarity. By comparison the ISP/carrier networks I  
dealt with at the same time were all much lower speed, mono-protocol  
affairs which were much easier to debug and manage.

I've not had a reason to meddle in the fairs of an enterprise network  
for about 10 years, so it certainly wouldn't surprise me to find out  
that the situation today is reversed. But I still find it amusing. :-)

Joe

---

From: "Smith, Donald" <[email-masked]>
Date: Fri, 11 Jan 2008 15:38:36 -0700

I too worked on some complex enterprise networks so I will concede that
some enterprise networks are very complex:)

Most enterprises can block protocols that they don't need especially at
the network edges while most ISP can not block any of the 256 ip
protocols.

ISPs tend to run more routing protocols.
ISPs don't usually have stateful firewalls protecting them from the
internet.

There are of course exceptions to all of the above statements.

Regardless, this question remains. Is this work expected to address both
enterprise and ISP type networks?

> From: Joe Abley [mailto:[email-masked]] 
> Sent: Friday, January 11, 2008 2:57 PM
> Subject: Re: [OPSEC] charter skeleton rev5 
> 
> 
> > I thought at one point this charter included scoping that 
> addressed  
> > type

---

From: Joe Abley <[email-masked]>
Date: Fri, 11 Jan 2008 17:41:33 -0500

> enterprise and ISP type networks?

I think our target market consists mainly of ISPs.

I say "mainly" because I'm quite sure that there are enterprises whose  
networks look very much like those of service providers, and vice versa.

I don't know to define what a "service provider network" is, and I'm  
not sure that we want to bother.

Joe

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 13 Jan 2008 13:31:04 -0800

> enterprise and ISP type networks?

There are some issues with enterprise networks that are probably pretty
clearly out of scope for this working group. How people deploy network
access controls or what you dpi/ips sensor should be looking for
example. The protection of network infrastructure is clearly relevant to
the needs of enterprise network operators however.

---

From: George M Jones <[email-masked]>
Date: Mon, 14 Jan 2008 12:59:09 -0500

> not sure that we want to bother.

We spent a lot of time on this.

I think we came down on the side of limiting scope to devices providing 
transit services.

You need at least some rule of thumb to allow you to make semi-objective
calls on what's in and what's out of scope.

Are web proxies that provide anti-virus scanning out of scope ?  Why ?
It's a "best" current security practice related to internet security.

---George Jones

---

From: Fernando Gont <[email-masked]>
Date: Wed, 16 Jan 2008 05:54:45 -0200

>everyone does to the Wiki).

Would it make sense if I prepare and publsh a draft on the subject. 
(Much of the work is already done for other drafts I have work on on 
several issues about ICMP).

Kind regards,

---

From: George M Jones <[email-masked]>
Date: Wed, 16 Jan 2008 09:05:44 -0500

> several issues about ICMP).

Yes.

---George Jones

---

From: Fernando Gont <[email-masked]>
Date: Wed, 16 Jan 2008 14:43:36 -0200

>>several issues about ICMP).

Okay. Will do.

Kind regards,

---

From: Merike Kaeo <[email-masked]>
Date: Sat, 19 Jan 2008 14:06:15 -0800

I just re-read all discussion from charter skeleton 3 onwards and  
here is some input from me:

- regarding work with other wg's.   Can we have a paragraph in the  
charter that says something like (and I take some wording from Dan  
Roascanu's comment as well as IPPM wg (where I remember this came up  
when I was co-chair there):

" The principal input of the Working Group are operational experience  
and needs.  The intended output of the wg is to provide guidance to  
the operators community as well as to Working Groups that develop  
protocols or the community of protocol developers at large to promote  
consistent approaches for supporting existing operational security  
practices and to promote new approaches where operationally desired.   
Within the IETF process, OPsec security practice documents will be  
subject to as rigorous a scrutiny for usefulness, clarity, and  
accuracy as other protocol standards. The OPsec WG will interact with  
other areas of IETF activity whose scope intersect with the  
requirement of these specific practices. These include working groups  
such as BMWG, v6ops, and <insert others?>".

- in v6ops there's discussion on draft-ietf-v6ops-rfc3330-for- 
ipv6-04.txt .......specific to which prefixes should get  
filtered.......we probably want to support/comment on that work?!?

- Some work items I see as relevant:

  -- IPv6 specific operational security concerns (despite common  
'it's no different than v4' comments) I think there's things like RA  
advertisement suppression and some similar things that may need some  
consideration.

-- logging document...definitely needs to be included somehow....is  
Tina signed up for the work?  [I totally am in sync with George's  
comment a few weeks ago that getting operator input was  
tough.......especially as doc editors.........it is important to get  
people signed up for the writing part....and no, I'm not volunteering  
right now.......]

-- AAA related things...how devices get authenticated to and how  
activities get logged/audited

One thing that I see in practice is that things that are a 'duh - of  
course you would do that'  is not something that's second nature to  
all operators, especially the ones with less experience.  And make  
that ditto for new equipment vendors.  I have a story where I had to  
explain a year ago why NTP was important for timestamping of  
logs :)    Anyhow.....just some thoughts.....sorry for late  
contribution........

- merike

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 20 Jan 2008 19:02:32 -0800

Merike Kaeo wrote:
> I just re-read all discussion from charter skeleton 3 onwards and here
> is some input from me:
> 
> and needs.  The intended output of the wg is to provide guidance to the
> operators community as well as to Working Groups that develop protocols
> or the community of protocol developers at large to promote consistent
> approaches for supporting existing operational security practices and to
> promote new approaches where operationally desired.  Within the IETF
> process, OPsec security practice documents will be subject to as
> rigorous a scrutiny for usefulness, clarity, and accuracy as other
> protocol standards. The OPsec WG will interact with other areas of IETF
> activity whose scope intersect with the requirement of these specific
> practices. These include working groups such as BMWG, v6ops, and <insert
> others?>".

I like the tenor of this, but I am also in favor of compactness, and  I
think rev 5 is quite attractive in the extent to which it is pared back
to a minimalist core.

would you consider it incomplete without this sentiment?

> - in v6ops there's discussion on
> draft-ietf-v6ops-rfc3330-for-ipv6-04.txt .......specific to which
> prefixes should get filtered.......we probably want to support/comment
> on that work?!?

One of the concerns I have with enterprise networks in general but also
with forwarding and control plane protection is the congruence of policy
between ipv4 and ipv6 configuration. So I would agree and if possible
amplify that sentiment.

>  -- IPv6 specific operational security concerns (despite common 'it's no
> different than v4' comments) I think there's things like RA

Indeed... Operationally it's easy enough to respond to and mitigate
sources of rogue's RA's but can you suppress them a priori without
features that may/probably do not exist in your switch platform?
Practice wise there's something be said for not relying on RA's when
your devices are going to be statically configured.

> -- logging document...definitely needs to be included somehow....is Tina
> signed up for the work?  [I totally am in sync with George's comment a
> few weeks ago that getting operator input was tough.......especially as
> doc editors.........it is important to get people signed up for the
> writing part....and no, I'm not volunteering right now.......]

Tina has expressed interest I know she's busy so I have avoided
hasseling her.

> course you would do that'  is not something that's second nature to all
> operators, especially the ones with less experience.  And make that
> ditto for new equipment vendors.  I have a story where I had to explain
> a year ago why NTP was important for timestamping of logs :)   
> Anyhow.....just some thoughts.....sorry for late contribution........
> 
> - merike
>

---

From: Merike Kaeo <[email-masked]>
Date: Sun, 20 Jan 2008 21:17:16 -0800

> would you consider it incomplete without this sentiment?

no - it was simply a suggestion........I have no attachment to the  
suggestion :)

>> 'it's no

Only reason I ask is that the work has been 'in progress' for a few  
years.....I totally understand
busy but if someone else could be recruited to co-author that may be  
something to consider to
help get the writing going?!?!?     It is very important for this wg  
to get authors of documents......while
input from operators is critical, so is the task of actually writing  
the documents.  That was the challenge
in the past few years for opsec.

- merike

---

From: Danny McPherson <[email-masked]>
Date: Tue, 29 Jan 2008 20:31:18 -0700

> Okay. Will do.

I'd be happy to help with this, and if we can't find it a
home here I'm certain we can find it a home elsewhere.

-danny

---

From: George M Jones <[email-masked]>
Date: Wed, 30 Jan 2008 05:39:45 -0500

> home here I'm certain we can find it a home elsewhere.

I think there's consensus that the work belongs here.

Go forth and draft.

---George

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 30 Jan 2008 09:36:08 -0700

I too would like to work on the ICMP filtering.
We should include rate limiting of icmp msgs FROM the router too.

RM=for(1)
{manage_risk(identify_risk(product[i++]))}
[email-masked] giac 

> From: Danny McPherson [mailto:[email-masked]] 
> Sent: Tuesday, January 29, 2008 8:31 PM

---

From: John Kristoff <[email-masked]>
Date: Wed, 30 Jan 2008 13:30:38 -0600

On Wed, 30 Jan 2008 09:36:08 -0700

> We should include rate limiting of icmp msgs FROM the router too.

I believe RFC 1812 Section 4.3.2.8 is widely implemented in routers
for ICMP generation already.  Are you seeing something different or
did you have something else in mind?  Perhaps a reference or update
to that RFC with stronger language is desired?

John

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 30 Jan 2008 12:53:12 -0700

Thanks John, I it has been a while since I looked at that rfc.
The reference you make is a good one especially for what a router is
expected to be able to filter.
They don't really reference very many ICMP types/codes that you may wish
to limit the generation of on the router itself.

Specific examples I was thinking of include:
Generation of unreachables on routers that are doing destination based
blackhole filtering.
While that could be seen as a violation of 4.3.3.1 I would argue that
you have a route/path it just happens to be towards the bit bucket. 

Another would be TTL expiration. I have seen what appeared to be
reflective attacks that used low ttl's and spoofed the victims source IP
address.

I think we could include those types of operational recommendations
without generating new requirements for the router vendors based on this
statement:
" A router SHOULD also be able to limit the rate at which it sends other
sorts
of ICMP error messages (Destination Unreachable, Redirect, Time
Exceeded, Parameter Problem).  The rate limit parameters SHOULD be
settable as part of the configuration of the router.  How the limits
are applied (e.g., per router or per interface) is left to the
implementor's discretion."

RM=for(1)

> From: John Kristoff [mailto:[email-masked]] 
> Sent: Wednesday, January 30, 2008 12:31 PM

---

From: "Barry Greene (bgreene)" <[email-masked]>
Date: Wed, 30 Jan 2008 20:01:48 -0800

I would say that a router that strictly codes to RFC 1812 is a router
which can be attacked and used to attack others. As Don mentioned,
routers today need a lot more capabilities and reset of expectations.

Consideration - a total relook at RFC 1812 - updating it so that all
routers behave the same way - in a way that it is safe from attack
and cannot be used to attack others. 

> From: Smith, Donald [mailto:[email-masked]] 
> Sent: Wednesday, January 30, 2008 11:53 AM
> Subject: RE: ICMP filtering (was Re: [OPSEC] charter skeleton rev5)
> 
> The reference you make is a good one especially for what a 
> router is expected to be able to filter.
> They don't really reference very many ICMP types/codes that 
> you may wish to limit the generation of on the router itself.
> 
> Generation of unreachables on routers that are doing 
> destination based blackhole filtering.
> While that could be seen as a violation of 4.3.3.1 I would 
> argue that you have a route/path it just happens to be 
> towards the bit bucket. 
> 
> Another would be TTL expiration. I have seen what appeared to 
> be reflective attacks that used low ttl's and spoofed the 
> victims source IP address.
> 
> I think we could include those types of operational 
> recommendations without generating new requirements for the 
> router vendors based on this
> statement:
> " A router SHOULD also be able to limit the rate at which it 
> sends other sorts of ICMP error messages (Destination 
> Unreachable, Redirect, Time Exceeded, Parameter Problem).  
> The rate limit parameters SHOULD be settable as part of the 
> configuration of the router.  How the limits are applied 
> (e.g., per router or per interface) is left to the 
> > I believe RFC 1812 Section 4.3.2.8 is widely implemented in
> > routers  for ICMP generation already.  Are you seeing something
> > different or  did you have something else in mind?  Perhaps a
> > reference 
> or update to 
> > that RFC with stronger language is desired?
> > 
> > John
> > 
> This communication is the property of Qwest and may contain 
> confidential or privileged information. Unauthorized use of 
> this communication is strictly prohibited and may be 
> unlawful.  If you have received this communication in error, 
> please immediately notify the sender by reply e-mail and 
> destroy all copies of the communication and any attachments.
>

---

From: John Kristoff <[email-masked]>
Date: Wed, 30 Jan 2008 22:40:48 -0600

On Wed, 30 Jan 2008 12:53:12 -0700

> to limit the generation of on the router itself.

As I understand it, implementations use these guidelines for any
ICMP response they generate.  And I'm not certain, but I thought it
applies the rate limit to the router ICMP response rate as a whole
and not on a per flow basis (which may be a DoS in itself if someone
is willing to flood the router with ICMP messages.

Perhaps if those who are writing documents could put that on a todo
list to find out and perhaps make note of it in what they end up
writing.

John

---

From: Fernando Gont <[email-masked]>
Date: Fri, 01 Feb 2008 02:26:16 -0200

>and cannot be used to attack others.

The same thing applies to most RFCs, including RFC 1122 (host 
requirements), the core TCP and IP specifications, and so on. What's 
really bad is is that people seem to feel happy about it.

I doubt whether we would ever be able to get consensus to rewrite RFC 
1122 or RFC 1812. The older the RFC, the more controversial it turns out to be.

Think about any of the most well known network attacks we have faced 
in the past (Smurf, SYN-flood, netkill, or whatever), and try to find 
a reference to them in any IETF RFC. Only since a couple of years ago 
we have had IDs or RFCs on a few of these issues (ICMP attacks, 
TCP-based attacks, SYN-floods)... but most of these efforts ended up 
in Informational RFCs (rather than Standards track)...

Kind regards,

_______________________________________________
OPSEC mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/opsec