|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Network Security Requirements draft
>>>>> "sd" == Sean Donelan <[email protected]> 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. [email protected] | +1 703 886 6038 | - Jeremy S. Anderson Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E
|