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 :-) Feel free to reply to me <george@uu.net> or reply to the list. Thanks, ---George Jones
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.
"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:
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@uu.net | +1 703 886 6038 | - Jeremy S. Anderson Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E
On 1 Jul 2002, Eric Brandwine wrote:
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.
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
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
participants (3)
-
Eric Brandwine -
George Jones -
Sean Donelan