"sd" == Sean Donelan <firstname.lastname@example.org> 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
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
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
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.
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
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
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.