Network Security Requirements draft

Eric Brandwine ericb at UU.NET
Mon Jul 1 20:26:10 UTC 2002


>>>>> "sd" == Sean Donelan <sean at 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:

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

sd> Rather than disabling IP Source Route as a global setting, I think you
sd> want to scrutinize traffic passing between data and control or management
sd> layers.  Such as to a routing process or management interface.  A source
sd> routed packet in the data layer just takes an unusual path through the
sd> network, but becomes a security risk if it hops into the control or
sd> management layer.  It would be nice to enable/block source routing (and
sd> strip other IP options) on a per interface basis and drop packets with
sd> 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
-- 
Eric Brandwine     |  There are two major products that come out of Berkeley:
UUNetwork Security |  LSD and BSD. We don't believe this to be a coincidence.
ericb at uu.net       |
+1 703 886 6038    |      - Jeremy S. Anderson
Key fingerprint = 3A39 2C2F D5A0 FC7C  5F60 4118 A84A BD5D  59D7 4E3E



More information about the NANOG mailing list