Subject: Last Call: draft-jones-opsec "Operational Security Requirements for IP Network Infrastructure"

From: Alex Zinin <[email-masked]>
Date: Thu, 22 Jan 2004 14:43:25 -0800

This document puts requirements on the routers. Please
review carefully, as it's likely to show up in RFPs...

-- 
Alex
http://www.psg.com/~zinin/

This is a forwarded message
From: Alex Zinin <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Thursday, January 22, 2004, 2:24:53 PM
Subject: Last Call: draft-jones-opsec "Operational Security Requirements for IP Network Infrastructure"

===8<==============Original message text===============

Folks-

 The IESG received a request to publish draft-jones-opsec as a BCP
 RFC. To ensure wide community review, we are soliciting comments on
 this document from the routing community. Please send your comments
 by February 5th, 2004.

 From the abstract:

   This document defines a list of operational security requirements for
   the infrastructure of large IP networks (routers and switches) which
   are considered to be best current practice (BCP). A framework is
   defined for specifying "profiles", which are collections of
   requirements applicable to certain network topology contexts (all,
   core-only, edge-only...). The goal is to provide network operators a
   clear, concise way of communicating their security requirements to
   vendors. Comments to: "[email-masked]".

 When commenting, please use the Routing Area mailing list
 ([email-masked]).

Alex Zinin
IETF Routing Area Co-Director

===8<===========End of original message text===========

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 23 Jan 2004 10:26:55 -0500

Presuming you comments to go here rather than routing-discussion.
I'll repost there if that's not the case.

I like this document in general and would make a few minor suggestions:

Requiring the origin of the stack or the OS, while nice in theory, is
unlikely to happen.  While it may be common knowledge as to what 
certain vendors have based their products upon, that knowledge seems
to be to the detriment of the vendor in many cases.  "That vendor based
their routing engine on Linux instead of FreeBSD" for example.  While
the origin may indeed affect the security implications it doesn't take
into account internal security audits or modifications to the original.

Similarly, separate resources for the management plane while a nice
idea in theory seem unlikely to happen for lower-end boxes.  Separate
resources perhaps suggests a higher chip count to a box.  It also 
potentially suggests an increase in complexity of the box and
complexity is one of the banes of securing a system.

I would suggest that it would be a Good Thing to make recommendations
that the console interface support some common data transfer protocol,
e.g. XMODEM.  This seems partially addressed in the section that covers
"support software installation", however that section seems to deal more with
non-console mechanisms.

With regards to the "slow link" issue, I would suggest that it would be
a Good Thing to provide some form of text filtering mechanism in order
to allow large queries of some form to return relevant data quickly.
An example is the Cisco-style |include or |exclude.  Grep is your
friend over slow links.

For the console fallback scenario, I would suggest that it is critical
to log failed login attempts locally, preferably in some non-volatile
storage to prevent attacks where the device is isolated from it's 
authentication interfaces and attacked at the console.

-- 
Jeff Haas 
NextHop Technologies

---

From: David Meyer <[email-masked]>
Date: Fri, 23 Jan 2004 07:58:30 -0800

>> into account internal security audits or modifications to the original.

	I agree with this. It seems to be a "punative-like"
	measure (or at least could be interpreted/used in that
	way). 

>> complexity is one of the banes of securing a system.

	ditto.

>> "support software installation", however that section seems to
>> deal more with  non-console mechanisms.

	I had though of that, but that would seem to violate
	"secure channel" requirement. Or does it?

	Dave

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 23 Jan 2004 15:12:16 -0500

> 	"secure channel" requirement. Or does it?

Did the document require a secure channel at the console?  The 
profile is obviously different.  I believe one of the requirements
(without looking again) was that we be able to use it in plain text mode.  

Also, the presence of encryption would take a low-bandwidth medium
and make it even lower bandwidth in many cases and more prone to
issues due to line noise.

-- 
Jeff Haas 
NextHop Technologies

---

From: Alex Zinin <[email-masked]>
Date: Thu, 5 Feb 2004 13:35:40 -0800

I just forwarded the comments to George.
Will wait for his responses.

---

From: George M Jones <[email-masked]>
Date: 06 Feb 2004 07:27:40 -0500

> Will wait for his responses.

Any objections if I cc the public opsec list with replies ?

---George

---

From: Alex Zinin <[email-masked]>
Date: Fri, 6 Feb 2004 12:34:48 -0800

George,

  Should be fine.

---

From: George Jones <[email-masked]>
Date: Wed, 17 Mar 2004 05:29:23 -0800 (PST)

On Tue, 16 Mar 2004, Alex Zinin wrote:

> not sure if you saw this

Nope.  As noted, I was not on rtg-dir and was not copied.  Thanks for
forwarding.

> From: Jeffrey Haas
> To: Alex Zinin
> Cc: [email-masked]
> Date: Friday, January 23, 2004, 7:26:55 AM

A couple of thoughts here.

First, these are now "SHOULD"s (possibly "should"s) in a draft aiming
at coming out as INFO (consensus of the BoF was that it should come
out as INFO soon, not BCP).  This requirement will not be usable as a
hammer.

Second, it's here to enable "trust but verify" testing.  "OK, you say
your high-end router is based on NT4 (:-)) and you've patched
everything...I've (customer testing person) got a bag of 'sploits
here that are widely available to kiddies....I just want to be sure
that they will not be able to knock down my core.  It allows
more focused use of time in the test cycle.

Third, lack of this knowledge may be to the detrement of the operator
and network users.   There two sides to the coin.

> idea in theory seem unlikely to happen for lower-end boxes.

This one has already been removed due to other input
(But note the scope. This is not talking about low end boxes.)

> "support software installation", however that section seems to deal more with

The req IS intended to deal with console (non-IP) mechanisms for
loading new software.

At the risk of making the req too complex, I've added:

04> 2.4.5 Support Software Installation
04>
04> Requirement
04>
04>      The installation procedures SHOULD support mechanisms to
04>      ensure reliability and integrity of data transfers.
04>
04>Justification
04>
04>
04>	System images may be corrupted in transit (from vendor to customer, or
04>	during the loading process) or in storage (bit rot, defective media,
04>	etc.)  Failure to reliably load a new image, for example after a
04>	hacker deletes or corrupts the installed image, could result in
04>	extended loss of availability.
04>
04>
04>Examples
04>
04>      Simple mechanisms currently in use to protect the integrity of
04>      system images and data transfer include image checksums and
04>      simple serial file transfer protocols such as XMODEM and Kermit.

Does that do it ?

> An example is the Cisco-style |include or |exclude.  Grep is your

Added the following to examples:

04>      One mechanism that supports operation over slow links is the
04>      ability to apply filters to the output of CLI commands which
04>      have potentially large output.  This may be implemented with
04>      something similar to the UNIX pipe facility and "grep" command.
04>
04>      For example,
04>
04>        cat largefile.txt | grep interesting-string
04>
04>      Another is the ablity to "page" through large command output, a
04>      la the UNIX "more" command:
04>
04>      For example,
04>
04>        cat largefile.txt | more

> authentication interfaces and attacked at the console.

How's this (updated):

04> 2.11.4 Ability to Log Locally
04>
04>    Requirement.
04>
04>       It SHOULD be possible to log locally on the device itself. Local
04>       logging SHOULD be written to non-volatile storage.
04>
04>    Justification.
04>
04>       Local logging of failed authentication attempts to non-volatile
04>       storage is critical.  It provides a means of detecting attacks
04>       where the device is isolated from it's authentication interfaces
04>       and attacked at the console.
.
.
.

Please CC replies to [email-masked].   I'll approve bounces if you
don't want to become a list memeber.

Thanks,
---George Jones

---

From: George Jones <[email-masked]>
Date: Wed, 17 Mar 2004 06:38:38 -0800 (PST)

On Tue, 16 Mar 2004, Alex Zinin wrote:

> To: David Meyer
> Cc: Alex Zinin <[email-masked]>, [email-masked]
> Date: Friday, January 23, 2004, 12:12:16 PM

See if this clears it up:

04> 2.3 Out-of-Band (OoB) Management Requirements
04>
04>    See Section 2.2 for a discussion of the advantages and
04>    disadvantages of In-band vs. Out-of-Band management.
04>
04>    These requirements assume two different possible Out-of-Band
04>    topologies:
04>
04>    o  Serial line (or equivalent) console connections using a CLI.
04>
04>    o  Network interfaces connected to a separate network dedicated to
04>       management.
04>
04>    In both cases the security of in-band communications beyond the management
04>    interface (e.g. console port, management network interface) is
04>    assumed. It is assumed, for instance, that there are physical
04>    security measures in place and that there is no need for encryption
04>    of communication on a serial connection between a terminal server
04>    and a device's console port.  It is assumed that the out-of-band
04>    management network is secure.  There is no requirement that
04>    management traffic on a secure management network be encrypted,
04>    though it would be wise, as an application of defense-in-depth, to
04>    apply the in-band requirements (e.g. encryption) to out-of-band
04>    interfaces.

Thanks,
---George Jones