draft-ietf-opsec-framework-02.txt   draft-ietf-opsec-framework-03.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
OPSEC Working Group G. Jones OPSEC Working Group G. Jones
Internet-Draft The MITRE Corporation Internet-Draft The MITRE Corporation
Expires: September 2, 2006 R. Callon Expires: September 2, 2006 R. Callon
Juniper Networks Juniper Networks
M. Kaeo M. Kaeo
Double Shot Security Double Shot Security
March 1, 2006 March 1, 2006
Framework for Operational Security Capabilities for IP Network Framework for Operational Security Capabilities for IP Network
Infrastructure Infrastructure
draft-ietf-opsec-framework-02 draft-ietf-opsec-framework-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 48 skipping to change at page 3, line 39
1.8. Applicability . . . . . . . . . . . . . . . . . . . . . . 11 1.8. Applicability . . . . . . . . . . . . . . . . . . . . . . 11
1.9. Intended Use . . . . . . . . . . . . . . . . . . . . . . . 11 1.9. Intended Use . . . . . . . . . . . . . . . . . . . . . . . 11
1.10. Definitions . . . . . . . . . . . . . . . . . . . . . . . 11 1.10. Definitions . . . . . . . . . . . . . . . . . . . . . . . 11
2. Documents . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2. Documents . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1. Framework Document . . . . . . . . . . . . . . . . . . . . 17 2.1. Framework Document . . . . . . . . . . . . . . . . . . . . 17
2.2. Operator Practices Survey . . . . . . . . . . . . . . . . 17 2.2. Operator Practices Survey . . . . . . . . . . . . . . . . 17
2.3. Standards Survey . . . . . . . . . . . . . . . . . . . . . 17 2.3. Standards Survey . . . . . . . . . . . . . . . . . . . . . 17
2.4. Capabilities Documents . . . . . . . . . . . . . . . . . . 17 2.4. Capabilities Documents . . . . . . . . . . . . . . . . . . 17
2.5. Profile Documents . . . . . . . . . . . . . . . . . . . . 18 2.5. Profile Documents . . . . . . . . . . . . . . . . . . . . 18
3. Security Considerations . . . . . . . . . . . . . . . . . . . 19 3. Security Considerations . . . . . . . . . . . . . . . . . . . 19
4. Normative References . . . . . . . . . . . . . . . . . . . . . 19 4. Non-Normative References . . . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Appendix B. Sample Capability Description . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22 B.1. Filtering TO the Device . . . . . . . . . . . . . . . . . 21
B.1.1. Ability to Filter Traffic on All Interfaces TO the
Device . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
1. Introduction 1. Introduction
1.1. Goals 1.1. Goals
The goal of the Operational Security Working Group is to codify The goal of the Operational Security Working Group is to codify
knowledge gained through operational experience about feature sets knowledge gained through operational experience about feature sets
that are needed to securely deploy and operate managed network that are needed to securely deploy and operate managed network
elements providing transit services at the data link and IP layers. elements providing transit services at the data link and IP layers.
skipping to change at page 10, line 20 skipping to change at page 10, line 20
1.7. Format and Definition of Capabilities 1.7. Format and Definition of Capabilities
A separate document will be created for specific categories of A separate document will be created for specific categories of
capabilities. Each individual capability will have the following capabilities. Each individual capability will have the following
elements: elements:
Capability (what) Capability (what)
The capability describes a policy to be supported by the device. The capability describes a policy to be supported by the device.
Capabilities are described in terms of "The device is able to...".
Capability descriptions do not use [RFC2119] keywords, e.g. they
are not phrased as "The device MUST...".
Capabilities should not refer to specific technologies. It is Capabilities should not refer to specific technologies. It is
expected that desired capability will change little over time. expected that desired capability will change little over time.
Supported Practices (why) Supported Practices (why)
The Supported Practice section cites practices described in The Supported Practice section cites practices described in
[I-D.ietf-opsec-current-practices] that are supported by this [I-D.ietf-opsec-current-practices] that are supported by this
capability. The need to support the cited practices provides the capability. The need to support the cited practices provides the
justification for the feature. justification for the feature.
skipping to change at page 12, line 4 skipping to change at page 12, line 4
o to assist operators in clearly communicating their security o to assist operators in clearly communicating their security
requirements, requirements,
o as high level guidance for the creation of detailed test plans. o as high level guidance for the creation of detailed test plans.
o as guidance for vendors to make appropriate decisions for o as guidance for vendors to make appropriate decisions for
engineering feature roadmaps. engineering feature roadmaps.
1.10. Definitions 1.10. Definitions
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].
NOTE: The following definitions are take from RFC3871. Unless NOTE: The following definitions are take from RFC3871. Unless
otherwise stated, the working group documents will use these terms as otherwise stated, the working group documents will use these terms as
defined below. defined below.
Bogon. Bogon.
A "Bogon" (plural: "bogons") is a packet with an IP source address A "Bogon" (plural: "bogons") is a packet with an IP source address
in an address block not yet allocated by IANA or the Regional in an address block not yet allocated by IANA or the Regional
Internet Registries (ARIN, RIPE, APNIC...) as well as all Internet Registries (ARIN, RIPE, APNIC...) as well as all
addresses reserved for private or special use by RFCs. See addresses reserved for private or special use by RFCs. See
skipping to change at page 19, line 9 skipping to change at page 19, line 9
Profile documents list capabilities appropriate to different Profile documents list capabilities appropriate to different
operating environments such as large Network Service Provider operating environments such as large Network Service Provider
(NSP) core or edge devices or enterprise networks. These profiles (NSP) core or edge devices or enterprise networks. These profiles
MAY provide a good starting point for organizations to generate MAY provide a good starting point for organizations to generate
their own list of requirements. their own list of requirements.
3. Security Considerations 3. Security Considerations
Security is the entire focus of this document. Security is the entire focus of this document.
4. Normative References 4. Non-Normative References
[I-D.ietf-opsec-current-practices] [I-D.ietf-opsec-current-practices]
Kaeo, M., "Operational Security Current Practices", Kaeo, M., "Operational Security Current Practices",
draft-ietf-opsec-current-practices-02 (work in progress), draft-ietf-opsec-current-practices-04 (work in progress),
October 2005. June 2006.
[RFC1208] Jacobsen, O. and D. Lynch, "Glossary of networking terms", [RFC1208] Jacobsen, O. and D. Lynch, "Glossary of networking terms",
RFC 1208, March 1991. RFC 1208, March 1991.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
skipping to change at page 20, line 9 skipping to change at page 20, line 9
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[RFC3871] Jones, G., "Operational Security Requirements for Large [RFC3871] Jones, G., "Operational Security Requirements for Large
Internet Service Provider (ISP) IP Network Internet Service Provider (ISP) IP Network
Infrastructure", RFC 3871, September 2004. Infrastructure", RFC 3871, September 2004.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors gratefully acknowledge the contributions of: The authors gratefully acknowledge the contributions of:
o Acknowledgments to be determined.
o The MITRE Corporation for supporting development of this document. o The MITRE Corporation for supporting development of this document.
NOTE: The author's affiliation with The MITRE Corporation is NOTE: The author's affiliation with The MITRE Corporation is
provided for identification purposes only, and is not intended to provided for identification purposes only, and is not intended to
convey or imply MITRE's concurrence with, or support for, the convey or imply MITRE's concurrence with, or support for, the
positions, opinions or viewpoints expressed by the author. positions, opinions or viewpoints expressed by the author.
o This listing is intended to acknowledge contributions, not to Appendix B. Sample Capability Description
imply that the individual or organizations approve the content of
this document.
o Apologies to those who commented on/contributed to the document This appendix provides a sample capability description. Note the
and were not listed. lack of the use of "MUST", etc in the description of the capability.
Also note that in the supported practices section it refers both to
the current practices document [I-D.ietf-opsec-current-practices] and
to sections of the same document (xxx.1, xxx.2) that describe
practices that were not covered in the current practices document.
B.1. Filtering TO the Device
B.1.1. Ability to Filter Traffic on All Interfaces TO the Device
Capability.
The device provides a means to filter IP packets on any interface
implementing IP that are non-transit packets.
Supported Practices.
* Profile Current Traffic (Section xxx.1)
* Block Malicious Packets (Section xxx.2 )
* Limit Sources of Management ([I-D.ietf-opsec-current-
practices], Section 2.8.2)
Current Implementations.
Many devices currently implement access control lists or filters
that allow filtering based on protocol and/or source/destination
address and or source/destination port and allow these filters to
be applied to interfaces.
Considerations.
None.
Authors' Addresses Authors' Addresses
George M. Jones George M. Jones
The MITRE Corporation The MITRE Corporation
7515 Colshire Drive, M/S WEST 7515 Colshire Drive, M/S WEST
McLean, Virginia 22102-7508 McLean, Virginia 22102-7508
U.S.A. U.S.A.
Phone: +1 703 488 9740 Phone: +1 703 488 9740
skipping to change at page 21, line 27 skipping to change at page 22, line 27
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
U.S.A. U.S.A.
Phone: +1 978 692 6724 Phone: +1 978 692 6724
Email: rcallon@juniper.net Email: rcallon@juniper.net
Merike Kaeo Merike Kaeo
Double Shot Security Double Shot Security
520 Washington Blvd. #363 3518 Fremont Avenue North #363
Marina Del Rey, CA 90292 Seattle, WA 98103
U.S.A. U.S.A.
Phone: +1 310 866 0165 Phone: +1 310 866 0165
Email: kaeo@merike.com Email: merike@doubleshotsecurity.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 12 change blocks. 
23 lines changed or deleted 53 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/