[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments on misc caps draft, general comments for caps drafts
Network Working Group R. Callon
Internet-Draft Juniper Networks
Expires: August 6, 2006 G. Jones
The Mitre Corporation
February 2, 2006
Miscellaneous Capabilities for IP Network Infrastructure
draft-ietf-opsec-misc-cap-00.txt
...
Abstract
The Framework for Operational Security Capabilities [11] outlines the
gmj> Use symbolic references, e.g. [RFC3871] instead of [14]. Much
gmj> easier to follow. You can do it in xml2rfc with
gmj>
gmj> <?rfc symrefs="yes" ?>
gmj> <?rfc sortrefs="yes"?>
gmj>
gmj> at the start. We should be consistent and do this in all docs.
gmj>
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;
Callon & Jones Expires August 6, 2006 [Page 1]
Internet-Draft Miscellaneous Capabilities February 2006
In-Band and Out-of-Band Management; Configuration and Management
Interfaces; AAA; and Documentation and Assurance. This document
describes some additional miscellaneous capabilities which do not fit
into any of these specific catagories, and whose descriptions are
brief enough that it does not seem appropriate to create a separate
document for each.
Operational Security Current Practices [12] lists current operator
practices related to securing networks. This document lists
miscellaneous capabilities needed to support those practices.
Capabilities are defined without reference to specific technologies.
This is done to leave room for deployment of new technologies that
implement the capability. Each capability cites the practices it
supports. Current implementations that support the capability may be
cited. Special considerations are discussed as appropriate listing
operational and resource constraints, limitations of current
implementations, tradeoffs, etc.
gmj> abstract is a bit long, but other than that, good.
Callon & Jones Expires August 6, 2006 [Page 2]
Internet-Draft Miscellaneous Capabilities February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Threat model . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Capabilities versus Requirements . . . . . . . . . . . . . 4
1.3. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Terms Used in this Document . . . . . . . . . . . . . . . 5
1.5. RFC 2119 Keywords . . . . . . . . . . . . . . . . . . . . 6
2. IP Stack Capabilities . . . . . . . . . . . . . . . . . . . . 7
2.1. Ability to Identify All Listening Services . . . . . . . . 7
2.2. Ability to Disable Any and All Services . . . . . . . . . 8
2.3. Ability to Control Service Bindings for Listening
Services . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Ability to Control Service Source Addresses . . . . . . . 9
2.5. Support Automatic Anti-Spoofing for Single-Homed
Networks . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6. Support Automatic Discarding of Bogons and Martians . . . 11
2.7. Support Counters for Dropped Packets . . . . . . . . . . . 12
3. Performance and Prioritization . . . . . . . . . . . . . . . . 12
3.1. Security Features Should Have Minimal Performance
Impact . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Prioritization of Management Functions . . . . . . . . . . 14
3.3. Prioritization of Routing Functions . . . . . . . . . . . 15
3.4. Resources used by IP Multicast . . . . . . . . . . . . . . 16
gmj> See Chris's draft (filtering). I think all these drafts should have
gmj> a section "Additional Operational Practices" at the end, at least
gmj> in stub form. That way, if there is a practice not included in
gmj> Merike's draft it can be added here and cited internally. It could
gmj> also be moved back to Merike's document.
4. Security Features Must Not Cause Operational Problems . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . . 18
7.2. Informational References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21
Callon & Jones Expires August 6, 2006 [Page 3]
Internet-Draft Miscellaneous Capabilities February 2006
1. Introduction
This document is defined in the context of [11] and [12].
The Framework for Operational Security Capabilities [11] outlines the
proposed effort of the IETF OPSEC working group. This includes
producing a series of drafts to codify knowledge gained through
gmj> for final draft, this should say something like "...outlines
gmj> a series of documents..."
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
gmj> Again, this is written from the current perspective. When
gmj> published, it should not talk about our plans, or possibly even the WG,
gmj> just the docs.
...
EDITORS NOTE: This is an early draft. Additional work will be needed
to further refine the listed practices, to respond to comments, and
to further align the supported practices with the practices listed in
[12]. Editor's notes listed in this document are intended to be
removed prior to final publication.
gmj> General comment. I think as we get the other drafts done,
gmj> some supported practices will flow back into Merike's draft.
1.1. Threat model
The capabities listed in this document are intended to aid in
preventing or mitigating the threats outlined in [11] and [12].
1.2. Capabilities versus Requirements
Capabilities may or may not be requirements. That is a local
determination that must be made by each operator with reference to
the policies that they must support. It is hoped that this document,
together with [12] will assist operators in identifying their
security capability requirements and communicating them clearly to
vendors.
gmj> text taken from filtering draft ? Good. Let's use the same titles.
gmj> (fitering draft says "capabilities OR requirements ?"). vs. is better.
The Capability section describes a feature to be supported by the
device. The Supported Practice section cites practices described in
[CurPrc] that are supported by this capability. The Current
gmj> use the xml2rfc citations.
Implementation section is intended to give examples of
implementations of the capability, citing technology and standards
current at the time of writing. See rfc3631 [13]. It is expected
that the choice of features to implement the capabilities will change
over time. The Considerations section lists operational and resource
constraints, limitations of current implementations, tradeoffs, etc.
gmj> I'm thinking we need boilerplate for each of the caps documents.
gmj> The boilerplate will contain all the front matter that is needed
gmj> to make the documents readable standalone, as well as overall
gmj> structure...e.g. standard sectoins for capabilities, other supported
gmj> practices, etc.
gmj>
gmj> The filtering draft would be a good start for the boilerplate.
gmj> I'll hack one unless someone else is motivated.
1.4. Terms Used in this Document
The following terms are used in this document. These definitions are
taken from rfc3871 [14].
Bogon
A "Bogon" (plural: "bogons") is a packet with an IP source address
in an address block not yet allocated by IANA or the Regional
Internet Registries (ARIN, RIPE, APNIC...) as well as all
addresses reserved for private or special use by RFCs. See
rfc3330 [9] and rfc1918 [3].
gmj> I think we can cite by reference. We don't need to repete defs
gmj> here unless they change or are additions.
1.5. RFC 2119 Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in rfc2119 [4].
The use of the RFC 2119 keywords is an attempt, by the authors, to
assign the correct requirement levels ("MUST", "SHOULD", "MAY"...).
It must be noted that different organizations, operational
environments, policies and legal environments will generate different
requirement levels.
NOTE: This document defines capabilities. This document does not
define requirements, and there is no requirement that any particular
capability be implemented or deployed. The use of the terms MUST,
SHOULD, and so on are in the context of each capability in the sense
that if you conform to any particular capability then you MUST or
SHOULD do what is specified for that capability, but there is no
requirement that you actually do conform to any particular
capability.
gmj> These last two paragraphs should go. Section 1.2 provides
gmj> enough caveats. If I recall correctly, these are going
gmj> to be INFO documents. We are not going to be specifying
gmj> MUSTs in the sense of normative, standards track protocol
gmj> docs. We will (?) be providing suggested profiles.
gmj> Each organization will evaluate their own needs and
gmj> determine the MUST/MAY/SHOULD for their own situation
gmj> which they can then communicate to their vendors, user community...
gmj>
gmj> That said, the text below (taken from 3871 I presume) is all
gmj> phrased in terms of MUST, SHOULD, etc.
gmj>
gmj> Rather than say "The device MUST do FOO..", say "The device FOOs"
gmj> or "The device is capable of FOOing.
gmj>
gmj> This goes for all caps docs.
Callon & Jones Expires August 6, 2006 [Page 6]
Internet-Draft Miscellaneous Capabilities February 2006
EDITOR'S NOTE: An earlier contribution towards this document
(draft-callon-misc-caps-00.txt) included a section on route
filtering. This section has been removed since it seems likely that
there may be a new document proposed giving significant more text
which includes this topic. It is intended and expected that some
opsec document will contain a description of route filtering
capabilities. details are tbd.
2. IP Stack Capabilities
EDITOR'S NOTE: This is taken from section 2.5 of RFC3871.
2.1. Ability to Identify All Listening Services
Capability.
The vendor MUST:
gmj> s/The vendor MUST/The device has the following capabilities:/
* Provide a means to display all services that are listening for
network traffic directed at the device from any external source.
* Display the addresses to which each service is bound.
* Display the addresses assigned to each interface.
* Display any and all port(s) on which the service is listing.
* Include both open standard and vendor proprietary services.
Supported Practices.
This information is necessary to enable a thorough assessment of
the security risks associated with the operation of the device
(e.g., "does this protocol allow complete management of the device
without also requiring authentication, authorization, or
accounting?"). The information also assists in determining what
steps should be taken to mitigate risk (e.g., "should I turn this
service off?")
gmj> Each of these should cite a setion in the practices document
gmj> or give forward reference to a set of practices listed in a
gmj> a subsequent section of this document.
Current Implementations.
tbd.
gmj> Linux: "lsof -i". JunOS ? IOS ?
...
2.5. Support Automatic Anti-Spoofing for Single-Homed Networks
See section 3 of rfc1918 [3], sections 5.3.7 and 5.3.8 of rfc1812
[2], and rfc2827 [6].
gmj> Use the force, Luke. Use xml2rfc's citation ability. You may need
gmj> to pull down the BIBXML tarballs for RFCs and drafts from xlm.resource.org
...
3.1. Security Features Should Have Minimal Performance Impact
Capability.
Security features specified by the requirements in this document
and related OPSEC documents SHOULD be implemented with minimal
impact on performance. Other sections of this document or other
OPSEC capabilities documents may specify different performance
requirements (e.g., "MUST"s).
gmj> I'd simplify the wording..."Router does not fall down and go 'boom'
gmj> when security features are enabled" :-). Thats the idea.
gmj> It has to be worded better than that. And, again, the parameters
gmj> for what is acceptable performance degradation are a local
gmj> determination.
gmj>
gmj> See the considerations section of 2.1.3 in the filtering draft.
gmj>
gmj> This may be an area where there is overlap with the Benchmark Methodlogy
gmj> WG (e.g. it would be very useful if they would measure the impact
gmj> of filtering, logging, etc. on throughput). I've talke to them
gmj> some at previous meetings.
3.4. Resources used by IP Multicast
gmj> This seems to be one special case singled out.
4. Security Features Must Not Cause Operational Problems
gmj> This needs rewording. Isn't this a general case of 3.1 ?
Callon & Jones Expires August 6, 2006 [Page 20]
Internet-Draft Miscellaneous Capabilities February 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Callon & Jones Expires August 6, 2006 [Page 21]