Network Security Requirements draft

Mailman List Mirror (Read Only)
1

We (UUNET) have an internal document that we've been using for a few
years as the basis for tests of security features of equipment to be
connected to our backbone. We're interested in making it public so
that it can be improved and so that others can use it. You can view
the current draft at:

  http://www.port111.com/docs/draft-jones-netsec-reqs-00.html (HTML)

  or

  http://www.port111.com/docs/draft-jones-netsec-reqs-00.txt (text)

the overall goal is an improvement in the security features of devices
implementing IP. The means that this document tries to provide is a
clear definition of security requirements that consumers/operators of
networking gear can point to (in RFPs) to say "see, we want security
and this is what it means".

The current list of requirements is skewed to the needs of large
networks (consider the source), but it does provide a means of
defining "profiles" for specifying subsets of requirements for
different classes of devices (core, edge, ... toasters.).

Most of the requirements specify features that are generally
implemented today (logging, aaa), though some of the requirements
specify highly desirable features that are not implemented in current
products (stealthing, monitoring, sampling, etc.)

What we're requesting here is feedback network operators and vendors
on how to make this document useful in achieving actual improvements
in security. Specifically, we're requesting feedback/discussion on:

  * The requirements listed
  * Important requirements that are missing
  * Document structure
  * How to make it useful.

The next step will likely be submission of an Internet draft-
c.a. July 2. Input prior to that date stands a much better chance of
being included :slight_smile:

Feel free to reply to me <george@uu.net> or reply to the list.

Thanks,
---George Jones

2

Its a nice draft. One issue, not with the draft, but in general on
network security is the lack of a transit network security architecture
description. The issue of how to deal with IP source routing in this
draft is what reminded me of this.

Most network security architectures are based on the internal, perimeter,
external network model. Bad traffic is blocked by the permiter network
and never allowed to pass into the internal network. But in a public
service provider network traffic is separated along the data, control,
management model. Maintaining the separation between data, control and
management under all conditions is the challenge. Data is just data,
until something starts to use it to make decisions. Purists might argue
you are just creating a huge perimeter network through your entire
transit network.

Rather than disabling IP Source Route as a global setting, I think you
want to scrutinize traffic passing between data and control or management
layers. Such as to a routing process or management interface. A source
routed packet in the data layer just takes an unusual path through the
network, but becomes a security risk if it hops into the control or
management layer. It would be nice to enable/block source routing (and
strip other IP options) on a per interface basis and drop packets with
unexpected options at any control or management interface.

3

We (UUNET) have an internal document that we've been using for a few
years as the basis for tests of security features of equipment to be
connected to our backbone. We're interested in making it public so
that it can be improved and so that others can use it. You can view
the current draft at:

Its a nice draft. One issue, not with the draft, but in general on
network security is the lack of a transit network security architecture
description. The issue of how to deal with IP source routing in this
draft is what reminded me of this.

Rather than disabling IP Source Route as a global setting, I think you
want to scrutinize traffic passing between data and control or management
layers. Such as to a routing process or management interface. A source
routed packet in the data layer just takes an unusual path through the
network, but becomes a security risk if it hops into the control or
management layer. It would be nice to enable/block source routing (and
strip other IP options) on a per interface basis and drop packets with
unexpected options at any control or management interface.

The document lists requirements that a device must satisfy in order to
be considered for deployment into the public network. It doesn't talk
about the required config of that device.

The ability to examine and evaluate IP options at line rate is
something that we're lacking at the moment. Given the hardware to do
this, policy decisions such as the one you mention could then be made.

The doc currently states "This option MUST be available on a
per-interface basis." Perhaps going one step further, and requiring
per-interface application of ACLs that are checked against the
purported source address would be useful.

There are two docs that are companions to this one, an implementation
document that hasn't been written yet, and a policy document that is
not of general use beyond our network. Hopefully, this requirements
document will remain applicable for quite a while, with the
implementation document tracking the current state of the art.

I'm not going to open the control plane separation can'o'worms, nor am
I going to step into the "LSR as a legitimately useful IP option"
discussion. Given the tools that we're asking for in the doc, you can
take whatever position that you and your company feel appropriate.

ericb

4

We may just be debating words, but per-interface basis doesn't really
capture what I'm looking for. I really want to apply controls on a
per-application basis in the router. For example, apply controls on what
kind of packets reach the NTP or BGP application process additionally
identified by the interface. Packets just passing through an interface
may not be of interest. If someone sends an IP Source Routed NTP packet
to my router, I probablly want to drop it. If someone sends someone else
an IP source routed NTP packet through my router, I may forward it
without further throught. If I add another logical or physical interface
on a router, the application controls would still be applied even if
the change control process missed setting an ACL on the new interface.

I can understand the argument that applications all listen on ports
on interfaces. So by implementing the controls on a per-interface basis
you can achieve the same affect. A clever engineer can figure out
which packets are passing through an interface, and which packets are
destined for a port on an interface. If we're just trying to specify how
to make new routers behave like the ciscos we're all used to, I can
understand the limitations we're operating under.

In Cisco-speak it could be yet another extension of the extended ACL.

access-list 100 deny ip any any option lsrr
access-list 100 permit ip host 172.16.10.10 any
access-list 100 deny ip any any log

Then you could filter packets with unwanted options (lsrr, rr, etc) where
ever ACLs are used, including per-interface, per-protocol, per-vty, etc.

Otherwise, what I'm afraid will happen is the requirement to do this on
a per-interface basis will be interpreted by router vendors as

interface ethernet 0
no ip source-route

5

Has anyone tried to apply/follow the ITU work on network security
for telecommunications carriers? Some folks have suggested using them
for Internet service providers.

[COM17-D19] Lucent Technologies (Q10/17): Towards the model for network
security framework
http://www.itu.int/itudoc/itu-t/com17/dcontr/01-04/dc-feb02/19.html

[COM17-D20] Japan (Q10/17): Requirements of Information Security
Management for Telecommunication Carriers
http://www.itu.int/itudoc/itu-t/com17/dcontr/01-04/dc-feb02/20.html

6

"sd" == Sean Donelan <sean@donelan.com> writes:

We (UUNET) have an internal document that we've been using for a few
years as the basis for tests of security features of equipment to be
connected to our backbone. We're interested in making it public so
that it can be improved and so that others can use it. You can view
the current draft at:

Its a nice draft. One issue, not with the draft, but in general on
network security is the lack of a transit network security architecture
description. The issue of how to deal with IP source routing in this
draft is what reminded me of this.

Most network security architectures are based on the internal, perimeter,
external network model. Bad traffic is blocked by the permiter network
and never allowed to pass into the internal network. But in a public
service provider network traffic is separated along the data, control,
management model. Maintaining the separation between data, control and
management under all conditions is the challenge.

Right. Thanks. That helps clarify the actual requirement. I was
headed there

2.1.2 Enforce Use Of Management Interfaces

Requirement It MUST be possible to configure the device such that all
management may only be done via specific management interfaces. This
requirement SHALL NOT be satisfied using a filtering mechanism on
non-management interfaces alone, since filters do not guarantee
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
separation of management and non-management traffic
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

but had not formulated it that cleanly. The actual requirement is
separation of data flow and management. OOB is just one way of
achieving that (that we happen to use). I'll think it over and
reword.

Rather than disabling IP Source Route as a global setting, I think you
want to scrutinize traffic passing between data and control or management
layers. Such as to a routing process or management interface. A source
routed packet in the data layer just takes an unusual path through the
network, but becomes a security risk if it hops into the control or
management layer. It would be nice to enable/block source routing (and
strip other IP options) on a per interface basis and drop packets with
unexpected options at any control or management interface.

I think the general requirement here is ability to accept/reject
options per/interface. Once that's in place people can decide
for themselves if they want source routing (or other options).
I will work on rewording.

Since I announced the document here, I've added:

  2.3.4 Ability To Control Service Bindings
  
  Requirement
  
  The device MUST provide a means that allows the user to specify the
  bindings used for all listening services. It MUST support binding to a
  list of net-blocks and SHOULD support configuration of binding services
  to particular interfaces.
  
  Justification
  
  This greatly reduces the need for complex filters. It reduces the
  number of ports listening, and thus the number of potential avenues of
  attack. It insures that only traffic arriving from legitimate
  addresses and/or on designated interfaces can access services on the
  device.
  
  Implementation
  
  The default configuration as displayed by Display All Configuration
  Settings should list all interfaces and all potential services along
  with the ports they listen to, the addresses they listen to and the
  interfaces they bind to. These should all be made
  configurable.
  
  Warnings
  
  None

This would allow, for instance, SSH to be bound *only* to a loopback
interface. Combine this with the ability to disable options and do
filtering the loopback and I think we're getting close to an
acceptable way to do device management, even in-band.

Thanks,