draft-ietf-mile-rfc6045-bis-09.txt   draft-ietf-mile-rfc6045-bis-10.txt 
MILE Working Group K. Moriarty MILE Working Group K. Moriarty
Internet-Draft EMC Internet-Draft EMC
Obsoletes: 6045 (if approved) January 25, 2012 Obsoletes: 6045 (if approved) January 27, 2012
Intended status: Standards Track Intended status: Standards Track
Expires: July 28, 2012 Expires: July 30, 2012
Real-time Inter-network Defense (RID) Real-time Inter-network Defense (RID)
draft-ietf-mile-rfc6045-bis-09.txt draft-ietf-mile-rfc6045-bis-10.txt
Abstract Abstract
Security incidents, such as system compromises, worms, viruses, Security incidents, such as system compromises, worms, viruses,
phishing incidents, and denial of service, typically result in the phishing incidents, and denial of service, typically result in the
loss of service, data, and resources both human and system. Service loss of service, data, and resources both human and system. Service
providers and Computer Security Incident Response Teams need to be providers and Computer Security Incident Response Teams need to be
equipped and ready to assist in communicating and tracing security equipped and ready to assist in communicating and tracing security
incidents with tools and procedures in place before the occurrence of incidents with tools and procedures in place before the occurrence of
an attack. Real-time Inter-network Defense (RID) outlines a an attack. Real-time Inter-network Defense (RID) outlines a
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 July 28, 2012. This Internet-Draft will expire on July 30, 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
skipping to change at page 3, line 23 skipping to change at page 3, line 23
9.2. Message Transport . . . . . . . . . . . . . . . . . . . . 67 9.2. Message Transport . . . . . . . . . . . . . . . . . . . . 67
9.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 68 9.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 68
9.3.1. Authentication . . . . . . . . . . . . . . . . . . . . 69 9.3.1. Authentication . . . . . . . . . . . . . . . . . . . . 69
9.3.2. Multi-Hop Request Authentication . . . . . . . . . . . 70 9.3.2. Multi-Hop Request Authentication . . . . . . . . . . . 70
9.4. Consortiums and Public Key Infrastructures . . . . . . . . 71 9.4. Consortiums and Public Key Infrastructures . . . . . . . . 71
9.5. Privacy Concerns and System Use Guidelines . . . . . . . . 72 9.5. Privacy Concerns and System Use Guidelines . . . . . . . . 72
9.6. Sharing Profiles and Policies . . . . . . . . . . . . . . 77 9.6. Sharing Profiles and Policies . . . . . . . . . . . . . . 77
10. Security Considerations . . . . . . . . . . . . . . . . . . . 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 77
11. Internationalization Issues . . . . . . . . . . . . . . . . . 78 11. Internationalization Issues . . . . . . . . . . . . . . . . . 78
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79
13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81
14.1. Normative References . . . . . . . . . . . . . . . . . . . 81 14.1. Normative References . . . . . . . . . . . . . . . . . . . 81
14.2. Informative References . . . . . . . . . . . . . . . . . . 83 14.2. Informative References . . . . . . . . . . . . . . . . . . 83
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 84
1. Introduction 1. Introduction
Organizations require help from other parties to identify incidents, Organizations require help from other parties to identify incidents,
mitigate malicious activity targeting their computing resources, and mitigate malicious activity targeting their computing resources, and
to gain insight into potential threats through the sharing of to gain insight into potential threats through the sharing of
skipping to change at page 23, line 15 skipping to change at page 23, line 15
'InvestigationRequest', the source of the incident. In the 'InvestigationRequest', the source of the incident. In the
case of an InvestigationRequest, the RID system that can help case of an InvestigationRequest, the RID system that can help
stop or mitigate the traffic may not be known, and the message stop or mitigate the traffic may not be known, and the message
may have to traverse RID messaging systems by following the may have to traverse RID messaging systems by following the
routing path to the RID system closest to the source of the routing path to the RID system closest to the source of the
attack traffic. The Node element lists either the RID system attack traffic. The Node element lists either the RID system
or the IP address of the source, and the meaning of the value or the IP address of the source, and the meaning of the value
in the Node element is determined by the MsgDestination in the Node element is determined by the MsgDestination
element. element.
1. RIDSystem. The address listed in the Node element of the 1. RIDSystem. The IP address of the next upstream system
RIDPolicy class is the next upstream RID system that will accepting RID communications is REQUIRED and is listed in
receive the RID message. If NodeName element of the Node the Node element of the RIDPolicy class. If NodeName
class is used, it contains a DNS domain name. The element of the Node class is used, it contains a DNS domain
originating RID system is required to check that this name. The originating RID system is required to check that
domain name resolves to the IP address to which the RID this domain name resolves to the IP address to which the
message is sent. This check may be performed in advance of RID message is sent. This check may be performed in
sending the message and the result saved for future use advance of sending the message and the result saved for
with additional RID messages. future use with additional RID messages.
2. SourceOfIncident. The Address element of the Node element 2. SourceOfIncident. The Address element of the Node element
contains the IP address of the incident source, and the contains the IP address of the incident source, and the
NodeName element of the Node class is not used. The IP NodeName element of the Node class is not used. The IP
address is REQUIRED when this option is selected. The IP
address is used to determine the path of systems accepting address is used to determine the path of systems accepting
RID communications that will be used to find the closest RID communications that will be used to find the closest
RID system to the source of an attack in which the IP RID system to the source of an attack in which the IP
address used by the source is believed to be valid and a address used by the source is believed to be valid and a
Request message with MsgDst set to InvestigationRequest is Request message with MsgDst set to InvestigationRequest is
used. This is not to be confused with the IncidentSource used. This is not to be confused with the IncidentSource
class, as the defined value here is from an initial trace class, as the defined value here is from an initial trace
or investigation Request, not the source used in a Result or investigation Request, not the source used in a Result
message. message.
3. ext-value. An escape value used to extend this attribute. 3. ext-value. An escape value used to extend this attribute.
All extensions shall specify the contents and meaning of All extensions shall specify the contents and meaning of
the Node element of RIDPolicy. If the NodeName element of the Node element of RIDPolicy. See IODEF [RFC5070],
Node is used by an extension, NodeName may contain an Section 5.1 on extensibility. If the NodeName element of
Internationalized Domain Name (IDN) and that IDN is the Node class is used by an extension, NodeName may
required to satisfy the requirements in [RFC5890]. It is contain an Internationalized Domain Name (IDN); see Section
strongly recommended that RID Systems satisfy those IDN 11 for applicable requirements. All extensions SHOULD use
requirements via appropriate use of the DNS as opposed to an IP address in the Address element of the Node class as
implementing their own checks for these requirements. For the primary means of Node identification.
example, an extension could use both a NodeName and an IP
address to which the NodeName resolves. See IODEF
[RFC5070], Section 5.1 on extensibility.
MsgType-ext MsgType-ext
OPTIONAL. STRING. A means by which to extend the MsgType OPTIONAL. STRING. A means by which to extend the MsgType
attribute. See IODEF [RFC5070], Section 5.1. attribute. See IODEF [RFC5070], Section 5.1.
MsgDestination-ext MsgDestination-ext
OPTIONAL. STRING. A means by which to extend the OPTIONAL. STRING. A means by which to extend the
MsgDestination attribute. See IODEF [RFC5070], Section 5.1 MsgDestination attribute. See IODEF [RFC5070], Section 5.1
5.1.1. ReportSchema 5.1.1. ReportSchema
skipping to change at page 28, line 48 skipping to change at page 28, line 48
identified. If the source was identified, it is listed in the identified. If the source was identified, it is listed in the
Node element of this class. Node element of this class.
True. Source of incident was identified. True. Source of incident was identified.
False. Source of incident was not identified. False. Source of incident was not identified.
Node Node
Zero or many. The Node class is used to identify a system Zero or many. The Node class is used to identify a system
identified as part of an incident. The Address element of the identified as part of an incident. If this element is used,
Node element contains the IP address of the system. If the the Address element of the Node element MUST contain the IP
NodeName element of the Node class is used, it contains a DNS address of the system. If the NodeName element of the Node
domain name that has been checked to ensure that it resolved to class is used, it contains a DNS domain name that has been
that IP address when the check was performed. The base checked to ensure that it resolved to that IP address when the
check was performed. See Section 11 of this document for
internationalization considerations for NodeName. The base
definition of this class from the IODEF [RFC5070] can be definition of this class from the IODEF [RFC5070] can be
expanded to include other identifiers, Section 3.16. expanded to include other identifiers, Section 3.16.
The IncidentSource class has one attribute: The IncidentSource class has one attribute:
restriction restriction
OPTIONAL. ENUM. This attribute indicates the disclosure OPTIONAL. ENUM. This attribute indicates the disclosure
guidelines to which the sender expects the recipient to adhere. guidelines to which the sender expects the recipient to adhere.
This guideline provides no real security since it is the choice This guideline provides no real security since it is the choice
skipping to change at page 78, line 46 skipping to change at page 78, line 46
The Node class identifies a host or network device. This document The Node class identifies a host or network device. This document
re-uses the definition of Node from the IODEF specification re-uses the definition of Node from the IODEF specification
[RFC5070], Section 3.16. However, that document did not clearly [RFC5070], Section 3.16. However, that document did not clearly
specify whether a NodeName could be an Internationalized Domain Name specify whether a NodeName could be an Internationalized Domain Name
(IDN). RID systems MUST treat the NodeName class as a domain name (IDN). RID systems MUST treat the NodeName class as a domain name
slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName
class; if they do so, the UTF-8 representation of the domain name class; if they do so, the UTF-8 representation of the domain name
MUST be used, i.e., all of the domain name's labels MUST be U-labels MUST be used, i.e., all of the domain name's labels MUST be U-labels
expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be
used. A RID system can convert between A-labels and U-labels by used. An application communicating via RID can convert between
using the Punycode encoding [RFC3492] for A-labels as described in A-labels and U-labels by using the Punycode encoding [RFC3492] for
the protocol specification for Internationalized Domain Names in A-labels as described in the protocol specification for
Applications [RFC5891]. Internationalized Domain Names in Applications [RFC5891]. RID
systems are expected to obtain an IDN meeting these requirements by
asking a DNS resolver to return an IDN that does not contain A-labels
(even if the RID system's input to the DNS resolver contains
A-labels).
12. IANA Considerations 12. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas This document uses URNs to describe XML namespaces and XML schemas
[XMLschema] conforming to a registry mechanism described in [XMLschema] conforming to a registry mechanism described in
[RFC3688]. [RFC3688].
Registration request for the iodef-rid namespace: Registration request for the iodef-rid namespace:
URI: urn:ietf:params:xml:ns:iodef-rid-2.0 URI: urn:ietf:params:xml:ns:iodef-rid-2.0
skipping to change at page 84, line 28 skipping to change at page 84, line 34
Acknowledgements Acknowledgements
Many thanks to colleagues and the Internet community for reviewing Many thanks to colleagues and the Internet community for reviewing
and commenting on the document as well as providing recommendations and commenting on the document as well as providing recommendations
to improve, simplify, and secure the protocol: Steve Bellovin, David to improve, simplify, and secure the protocol: Steve Bellovin, David
Black, Harold Booth, Paul Cichonski, Robert K. Cunningham, Roman Black, Harold Booth, Paul Cichonski, Robert K. Cunningham, Roman
Danyliw, Yuri Demchenko, Sandra G. Dykes, Stephen Farrell, Katherine Danyliw, Yuri Demchenko, Sandra G. Dykes, Stephen Farrell, Katherine
Goodier, Cynthia D. McLain, Thomas Millar, Jean-Francois Morfin, Goodier, Cynthia D. McLain, Thomas Millar, Jean-Francois Morfin,
Stephen Northcutt, William Streilein, Damir Rajnovic, Tony Rutkowski, Stephen Northcutt, William Streilein, Damir Rajnovic, Tony Rutkowski,
Peter Saint-Andre Jeffrey Schiller, Robert Sparks, Richard Struse, Peter Saint-Andre, Jeffrey Schiller, Robert Sparks, Richard Struse,
Tony Tauber, Brian Trammell, Sean Turner, Iljitsch van Beijnum, and Tony Tauber, Brian Trammell, Sean Turner, Iljitsch van Beijnum, and
David Waltermire. David Waltermire.
Author's Address Author's Address
Kathleen M. Moriarty Kathleen M. Moriarty
EMC Corporation EMC Corporation
176 South Street 176 South Street
Hopkinton, MA Hopkinton, MA
United States United States
 End of changes. 12 change blocks. 
35 lines changed or deleted 38 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/