draft-ietf-mile-template-01.txt   draft-ietf-mile-template-02.txt 
mile Working Group B. Trammell mile Working Group B. Trammell
Internet-Draft ETH Zurich Internet-Draft ETH Zurich
Intended status: BCP February 16, 2012 Intended status: BCP February 17, 2012
Expires: August 19, 2012 Expires: August 20, 2012
Guidelines for Extensions to IODEF for Managed Incident Lightweight Guidelines for Defining Extensions to IODEF
Exchange draft-ietf-mile-template-02.txt
draft-ietf-mile-template-01.txt
Abstract Abstract
This document provides guidelines for extensions to IODEF [RFC5070] This document provides guidelines for extensions to IODEF [RFC5070]
for exchange of incident management data, and contains a template for for exchange of incident management data, and contains a template for
Internet-Drafts describing those extensions, in order to ease the Internet-Drafts describing those extensions, in order to ease the
work and improve the quality of extension descriptions. It also work and improve the quality of extension descriptions. It also
specifies additional Expert Review of XML Schemas used to describe specifies additional Expert Review of XML Schemas used to describe
these extensions. these extensions.
skipping to change at page 1, line 36 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 19, 2012. This Internet-Draft will expire on August 20, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability of Extensions to IODEF . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Selecting a Mechanism for IODEF Extension . . . . . . . . . . 4 3. Applicability of Extensions to IODEF . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. Selecting a Mechanism for IODEF Extension . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. Document Template . . . . . . . . . . . . . . . . . . 7 Appendix A. Document Template . . . . . . . . . . . . . . . . . . 7
A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 7 A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 7
A.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 A.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8
A.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 8 A.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 8
A.4. Extension Definition . . . . . . . . . . . . . . . . . . . 8 A.4. Extension Definition . . . . . . . . . . . . . . . . . . . 8
A.4.1. IODEF Data Types . . . . . . . . . . . . . . . . . . . 9 A.4.1. IODEF Data Types . . . . . . . . . . . . . . . . . . . 9
A.5. Security Considerations . . . . . . . . . . . . . . . . . 10 A.5. Security Considerations . . . . . . . . . . . . . . . . . 10
A.6. IANA Considerations . . . . . . . . . . . . . . . . . . . 10 A.6. IANA Considerations . . . . . . . . . . . . . . . . . . . 10
A.7. Appendix A: XML Schema Definition for Extension . . . . . 11 A.7. Appendix A: XML Schema Definition for Extension . . . . . 11
A.8. Appendix B: Examples . . . . . . . . . . . . . . . . . . . 11 A.8. Appendix B: Examples . . . . . . . . . . . . . . . . . . . 11
Appendix B. Example Enumerated Type Extension Definition: Appendix B. Example Enumerated Type Extension Definition:
E.164 Address . . . . . . . . . . . . . . . . . . . . 11 E.164 Address . . . . . . . . . . . . . . . . . . . . 12
Appendix C. Example Element Definition: Test . . . . . . . . . . 12 Appendix C. Example Element Definition: Test . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
In the five years since the specification of IODEF [RFC5070], the In the five years since the specification of IODEF [RFC5070], the
threat environment has evolved, as has the practice of cooperative threat environment has evolved, as has the practice of cooperative
network defense. These trends, along with experience gained through network defense. These trends, along with experience gained through
implementation and deployment, have indicated the need to extend implementation and deployment, have indicated the need to extend
IODEF. This document provides guidelines for defining these IODEF. This document provides guidelines for defining these
skipping to change at page 3, line 28 skipping to change at page 3, line 28
Additionally, IODEF extensions through AdditionalData and RecordItem Additionally, IODEF extensions through AdditionalData and RecordItem
elements, as per section 5.2 of [RFC5070], generally register their elements, as per section 5.2 of [RFC5070], generally register their
namespaces and schemas with the IANA XML Namespace registry at namespaces and schemas with the IANA XML Namespace registry at
http://www.iana.org/assignments/xml-registry/ns.html and the IANA XML http://www.iana.org/assignments/xml-registry/ns.html and the IANA XML
Schema registry at Schema registry at
http://www.iana.org/assignments/xml-registry/schema.html, http://www.iana.org/assignments/xml-registry/schema.html,
respectively [RFC3688]. In addition to schema reviews required by respectively [RFC3688]. In addition to schema reviews required by
IANA, these registry requests should be accompanied by a review by IANA, these registry requests should be accompanied by a review by
IODEF experts to ensure the specified AdditionalData and/or IODEF experts to ensure the specified AdditionalData and/or
RecordItem contents are compatible with IODEF and with other existing RecordItem contents are compatible with IODEF and with other existing
IODEF extensions. This document specifies that review in Section 5. IODEF extensions. This document specifies that review in Section 6.
2. Applicability of Extensions to IODEF 2. Terminology
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].
3. Applicability of Extensions to IODEF
Before deciding to extend IODEF, the first step is to determine Before deciding to extend IODEF, the first step is to determine
whether an IODEF extension is a good fit for a given problem. There whether an IODEF extension is a good fit for a given problem. There
are two sides to this question: are two sides to this question:
1. Does the problem involve the reporting or sharing of information 1. Does the problem involve the reporting or sharing of information
about an incident? "Incident" is not defined in the terminology about an incident? "Incident" is not defined in the terminology
for IODEF, but for purposes of IODEF can be loosely described as for IODEF, but for purposes of IODEF can be loosely described as
"something that happened that has some impact on the information "something that happened that has some impact on the information
security situation of an entity", with quite a bit of leeway for security situation of an entity", with quite a bit of leeway for
skipping to change at page 4, line 18 skipping to change at page 4, line 26
o Allowing the description of new types of entities (e.g., related o Allowing the description of new types of entities (e.g., related
actors) or new types of characteristics of entities (e.g., actors) or new types of characteristics of entities (e.g.,
information related to financial services) involved in an IODEF information related to financial services) involved in an IODEF
incident report incident report
o Allowing additional semantic or metadata labeling of IODEF o Allowing additional semantic or metadata labeling of IODEF
Documents (e.g., for handling or disposition instructions, or Documents (e.g., for handling or disposition instructions, or
compliance with data protection and data retention regulations) compliance with data protection and data retention regulations)
3. Selecting a Mechanism for IODEF Extension 4. Selecting a Mechanism for IODEF Extension
IODEF was designed to be extended through any combination of: IODEF was designed to be extended through any combination of:
1. extending the enumerated values of Attributes, as per section 5.1 1. extending the enumerated values of Attributes, as per section 5.1
of [RFC5070]; of [RFC5070];
2. class extension through AdditionalData and RecordItem elements, 2. class extension through AdditionalData and RecordItem elements,
as per section 5.2 of [RFC5070]; and/or as per section 5.2 of [RFC5070]; and/or
3. containment of the IODEF-Document element within an external XML 3. containment of the IODEF-Document element within an external XML
skipping to change at page 6, line 5 skipping to change at page 6, line 10
extensions MUST set the "dtype" attribute of the containing element extensions MUST set the "dtype" attribute of the containing element
to the data type to reference one of the IODEF data types as to the data type to reference one of the IODEF data types as
enumerated in Appendix A.4.1, and SHOULD define the use the "meaning" enumerated in Appendix A.4.1, and SHOULD define the use the "meaning"
and "formatid" attributes to explain the content of the element. and "formatid" attributes to explain the content of the element.
XML extensions within an AdditionalData or RecordItem element use a XML extensions within an AdditionalData or RecordItem element use a
dtype of "xml", and SHOULD define a schema for the root element dtype of "xml", and SHOULD define a schema for the root element
within the AdditionalData or RecordItem attribute. An example within the AdditionalData or RecordItem attribute. An example
definition of an element definition is given in Appendix C. definition of an element definition is given in Appendix C.
4. Security Considerations 5. Security Considerations
This document defines a template for extensions to IODEF; the This document defines a template for extensions to IODEF; the
security considerations for IODEF [RFC5070] apply. security considerations for IODEF [RFC5070] apply.
5. IANA Considerations 6. IANA Considerations
Changes to the XML Schema registry for schema names beginning with Changes to the XML Schema registry for schema names beginning with
"urn:ietf:params:xml:schema:iodef" are subject to an additional IODEF "urn:ietf:params:xml:schema:iodef" are subject to an additional IODEF
Expert Review [RFC5226]. The IODEF expert(s) for these reviews will Expert Review [RFC5226]. The IODEF expert(s) for these reviews will
be designated by the IETF Security Area Directors. be designated by the IETF Security Area Directors.
[IANA NOTE: The authors request that IANA include a note at the top [IANA NOTE: The authors request that IANA include a note at the top
of http://www.iana.org/assignments/xml-registry/schema.html, stating of http://www.iana.org/assignments/xml-registry/schema.html, stating
"Changes to the XML Schema registry for schema names beginning with "Changes to the XML Schema registry for schema names beginning with
'urn:ietf:params:xml:schema:iodef' are subject to an additional IODEF 'urn:ietf:params:xml:schema:iodef' are subject to an additional IODEF
Expert Review [RFC5226]," and naming the designated expert.] Expert Review [RFC5226]," and naming the designated expert.]
6. Acknowledgments 7. Acknowledgments
Thanks to David Black, Takeshi Takahashi, Tom Millar, and Kathleen Thanks to David Black, Takeshi Takahashi, Tom Millar, and Kathleen
Moriarty for their comments. This work is materially supported by Moriarty for their comments. This work is materially supported by
the European Union Seventh Framework Program under grant agreement the European Union Seventh Framework Program under grant agreement
257315 (DEMONS). 257315 (DEMONS).
7. References 8. References
7.1. Normative References 8.1. Normative References
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
Object Description Exchange Format", RFC 5070, Object Description Exchange Format", RFC 5070,
December 2007. December 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)", [I-D.ietf-mile-rfc6045-bis]
RFC 6045, November 2010. Moriarty, K., "Real-time Inter-network Defense (RID)",
draft-ietf-mile-rfc6045-bis-11 (work in progress),
January 2012.
7.2. Informative References 8.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998. Architecture", RFC 4291, February 2006.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, Resource Identifier (URI): Generic Syntax", STD 66,
August 1998. RFC 3986, January 2005.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
April 2001. October 2008.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002. Internet: Timestamps", RFC 3339, July 2002.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
July 2003. July 2003.
[RFC4519] Sciberras, A., "Lightweight Directory Access Protocol [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol
(LDAP): Schema for User Applications", RFC 4519, (LDAP): Schema for User Applications", RFC 4519,
skipping to change at page 7, line 50 skipping to change at page 8, line 8
A.1. Introduction A.1. Introduction
The introduction section introduces the problem being solved by the The introduction section introduces the problem being solved by the
extension, and motivates the development and deployment of the extension, and motivates the development and deployment of the
extension. extension.
A.2. Terminology A.2. Terminology
The terminology section introduces and defines terms specific to the The terminology section introduces and defines terms specific to the
document. Terminology from [RFC5070] or [RFC6045] should be document. Terminology from [RFC5070] or [I-D.ietf-mile-rfc6045-bis]
referenced in this section, but not redefined or copied. If should be referenced in this section, but not redefined or copied.
If [RFC2119] terms are used in the document, this should be noted in
[RFC2119] terms are used in the document, this should be noted in the the terminology section.
terminology section.
A.3. Applicability A.3. Applicability
The applicability section defines the use cases to which the The applicability section defines the use cases to which the
extension is applicable, and details any requirements analysis done extension is applicable, and details any requirements analysis done
during the development of the extension. The primary goal of this during the development of the extension. The primary goal of this
section is to allow readers to see if an extension is indeed intended section is to allow readers to see if an extension is indeed intended
to solve a particular problem. This should also the scope of the to solve a particular problem. This should also the scope of the
extension, as appropriate, by pointing out any non-obvious situations extension, as appropriate, by pointing out any non-obvious situations
to which it is not intended to apply. to which it is not intended to apply.
skipping to change at page 9, line 46 skipping to change at page 10, line 12
o POSTAL for postal addresses as defined in section 2.23 of o POSTAL for postal addresses as defined in section 2.23 of
[RFC4519]. [RFC4519].
o NAME for names of natural or legal persons as defined in section o NAME for names of natural or legal persons as defined in section
2.3 of [RFC4519]. 2.3 of [RFC4519].
o PHONE for telephone numbers as defined in section 2.35 of o PHONE for telephone numbers as defined in section 2.35 of
[RFC4519]. [RFC4519].
o EMAIL for email addresses as defined in section 3.4.1. of o EMAIL for email addresses as defined in section 3.4.1. of
[RFC2822]. [RFC5322].
o URL for URLs as in [RFC2396]. o URL for URLs as in [RFC3986].
In addition to these simple data types, IODEF provides a compound In addition to these simple data types, IODEF provides a compound
data type for representing network address information. Addresses data type for representing network address information. Addresses
included within an extension element should be represented by included within an extension element should be represented by
containing an IODEF:Address element, which supports IPv4 and containing an IODEF:Address element, which supports IPv4 and
[RFC2373] IPv6 addresses, as well as MAC, ATM, and BGP autonomous [RFC4291] IPv6 addresses, as well as MAC, ATM, and BGP autonomous
system numbers. Application-layer addresses should be represented system numbers. Application-layer addresses should be represented
with the URL simple attribute type, instead. with the URL simple attribute type, instead.
A.5. Security Considerations A.5. Security Considerations
[SECDIR and RFC-EDITOR NOTE: Despite the title, this section is NOT a [SECDIR and RFC-EDITOR NOTE: Despite the title, this section is NOT a
Security Considerations section, rather a template Security Security Considerations section, rather a template Security
Considerations section for future extension documents to be built Considerations section for future extension documents to be built
from this template. See Section 4 for Security Considerations for from this template. See Section 5 for Security Considerations for
this document.] this document.]
Any security considerations [RFC3552] raised by this extension or its Any security considerations [RFC3552] raised by this extension or its
deployment should be detailed in this section. Guidance should focus deployment should be detailed in this section. Guidance should focus
on ensuring the users of this extension do so in a secure fashion, on ensuring the users of this extension do so in a secure fashion,
with special attention to non-obvious implications of the with special attention to non-obvious implications of the
transmission of the information represented by an extension. transmission of the information represented by an extension.
It should also be noted in this section that the security It should also be noted in this section that the security
considerations for IODEF [RFC5070] apply to the extension as well. considerations for IODEF [RFC5070] apply to the extension as well.
A.6. IANA Considerations A.6. IANA Considerations
[IANA and RFC-EDITOR NOTE: Despite the title, this section is NOT an [IANA and RFC-EDITOR NOTE: Despite the title, this section is NOT an
IANA Considerations section, rather a template IANA Considerations IANA Considerations section, rather a template IANA Considerations
section for future extension documents to be built from this section for future extension documents to be built from this
template. See Section 5 for IANA Considerations for this document.] template. See Section 6 for IANA Considerations for this document.]
Any IANA considerations [RFC5226] for the document should be detailed Any IANA considerations [RFC5226] for the document should be detailed
in this section; if none, the section should exist and contain the in this section; if none, the section should exist and contain the
text "this document has no actions for IANA". text "this document has no actions for IANA".
IODEF Extensions which represent an enumeration should reference an IODEF Extensions which represent an enumeration should reference an
existing IANA registry or subregistry for the values of that existing IANA registry or subregistry for the values of that
enumeration. If no such registry exists, this section should define enumeration. If no such registry exists, this section should define
a new registry to hold the enumeration's values, and define the a new registry to hold the enumeration's values, and define the
policies by which additions may be made to the registry. policies by which additions may be made to the registry.
 End of changes. 25 change blocks. 
44 lines changed or deleted 51 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/