[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on nmasc draft, general comments on capabilitiy doc structure
See my comments prefixed by "gmj>" below.
OPSEC R. Bonica
Internet-Draft Juniper Networks
Expires: August 7, 2006 S. Ahmed
Booz Allen Hamilton
February 3, 2006
Network Management Access Security Capabilities
draft-ietf-opsec-nmasc-00
...
1. Introduction
The Framework for Operational Security Capabilities [4] outlines the
proposed effort of the IETF OPSEC working group. This includes
producing a series of drafts to codify knowledge gained through
operational experience about feature sets that are needed to securely
deploy and operate managed network elements providing transit
services at the data link and IP layers. Current plans include
separate capabilities documents for Packet Filtering; Event Logging;
In-Band and Out-of-Band Management; Configuration and Management
Interfaces; AAA; and Documentation and Assurance.
gmj> does this doc need to repeat material from the framework ?
3.1. Vulnerabilities
gmj> Vulnerabilities should probably be listed along with the
gmj> descriptoin of the current practice that the capability
gmj> is intended to support. See comments on 5.1.2 below.
3.2. Required Security Capabilities
gmj> 3.2. These need to be citable, for use in profiles.
gmj> Also, see section 1.7 of the framework for the anticipated format
gmj> of requirements:
gmj>
gmj> Capability (what)
gmj> Supported Practices (why)
gmj> Current Implementations (how)
gmj> Considerations
gmj>
gmj> See
gmj>
gmj> draft-morrow-filter-caps-00 (expired :-()
gmj>
gmj> for an example.
4. Out-of-Band Access
RFC 3871 assumes the following regarding out-of-band management:
- The out-of-band management network is secure
- There is no need for encryption of communication on out-of-band
management interfaces
gmj> ??? "RFC 3871 assumes...There is no need for encryption of communication"
- Security measures are in place to prevent unauthorized physical
access
4.1. Vulnerabilities
Although RFC 3871 does not explicitly identify this as a
vulnerability, if a router maintains only one dedicated management
interface, that interface constitutes a single point of failure. If
the dedicated management interface fails, the router will become
unmanageable (although it will continue to forward traffic).
gmj> It will become unmanagable if there is no inband management.
4.2. Required Security Capabilities
RFC 3871 states that routers must not forward traffic between
dedicated management interfaces and non-management interfaces.
gmj> That's a simplification.
gmj> Again, these need to be citable requirements.
The
router must never forward a datagram received from a non-management
interface through the dedicated management interface. Likewise, the
router must never forward a datagram received from the dedicated
management interface through a non-management interface.
Operators should refrain from activating dynamic routing protocols on
the dedicated management interface. Alternatively, they should rely
upon direct or static routes. If static routes are configured, they
should be as specific as possible.
gmj> This is good, but it is not a requirement. It is configuration
gmj> advice. Possibly in the considerations section.
5.1.2. Required Security Capabilities
gmj> Is there an accepted definitoin of VPNs that could be cited here ?
In order to provide a secure management mechanism, the virtual out-
of-band management network must effectively separate the management
VPN from all user VPNs. Traffic must never cross from the management
VPN to a user VPN or vice versa.
gmj> I would phrase capabilities more like
gmj>
gmj> 5.1.2.1 Support use of VPNs to seperate managment traffic
gmj>
gmj> Capability.
gmj>
gmj> It must be possible to configure VPNs such that management
gmj> traffic is effectively separated from all other traffic.
gmj> If so configured, traffic must never cross from the management
gmj> VPN to other VPNs or vice versa.
gmj>
gmj>
gmj> Supported Practices.
gmj>
gmj> This sectoin (per framework) is supposed to cite practices
gmj> listed in the current practices draft, so here, I would begin
gmj> by citing section 2.2 (Device In-Band Management). Given that
gmj> the current practices docuemnt does not mention VPNs, you might
gmj> want to ask Merike to either add it to 2.2 or add a new section,
gmj> possibly with much of the material you wrote describing the
gmj> use of VPNs. Then you just cite it. Per the framework, if
gmj> a practices that you want to cite for justification for a
gmj> capability is not listed in the practices document, then
gmj> you should create a seprate list of additional practices
gmj> in your doucment, probably formatted similarly to Merikes
gmj> list, cite it.
gmj>
gmj> The short of it is, your "supported practices" section will
gmj> probably be just a citation and possably a sentance or two.
gmj>
gmj> Current Implementations.
gmj>
gmj> Examples go here. Describe/cite a few examples of currrent
gmj> implementatoins of features that support your capability.
gmj>
gmj> Considerations.
gmj>
gmj> Operational and resource constraints, limitations of current
gmj> implementations, tradeoffs, preformance issues go here.
There. That's probably enough for now. This doc is a good start.
We need to discuss structuring things per the frameork (or not).
This goes for all capabilities docs.
Thanks,
---George Jones
George M. Jones | We [MULTICS] never came up with the idea that security
| was a side effect of copyright enforcement.
|
| Earl Boebert
gmj@pobox.com