|
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: sd> 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: 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> Most network security architectures are based on the internal, perimeter, sd> external network model. Bad traffic is blocked by the permiter network sd> and never allowed to pass into the internal network. But in a public sd> service provider network traffic is separated along the data, control, sd> management model. Maintaining the separation between data, control and sd> management under all conditions is the challenge. Right. Thanks. That helps clarify the actual requirement. I was headed there > 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 reword. 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. 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 Requirement 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. Justification 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 device. Implementation 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 configurable. Warnings None 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. Thanks, -- George M. Jones | Most important ideas are uninteresting. Most interesting CISSP,CCNA,JAPH | ideas are unimportant. Not every problem has a good UUNET | solutions. Every solution have side effects. Network Security | Quoted from Dan Geer [email protected], 2002 PGP = AB33 0916 F91E E58C B023 C768 351C 57E5 271E 69DC
|