Network Security Requirements draft

Sean Donelan sean at donelan.com
Sun Jun 30 07:59:35 UTC 2002


On 18 Jun 2002, George Jones wrote:
> 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.  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.





More information about the NANOG mailing list