idnits 2.17.1 draft-ietf-mile-rfc6045-bis-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 20 instances of too long lines in the document, the longest one being 13 characters in excess of 72. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 31, 2012) is 4462 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4051 (Obsoleted by RFC 6931) ** Obsolete normative reference: RFC 5070 (Obsoleted by RFC 7970) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6046 (Obsoleted by RFC 6546) -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLCanon' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLencrypt' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLPath' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLschema' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLsig' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLSigBP' -- Obsolete informational reference (is this intentional?): RFC 5735 (Obsoleted by RFC 6890) -- Obsolete informational reference (is this intentional?): RFC 6045 (Obsoleted by RFC 6545) Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MILE Working Group K. Moriarty 2 Internet-Draft EMC 3 Obsoletes: 6045 (if approved) January 31, 2012 4 Intended status: Standards Track 5 Expires: August 3, 2012 7 Real-time Inter-network Defense (RID) 8 draft-ietf-mile-rfc6045-bis-11.txt 10 Abstract 12 Security incidents, such as system compromises, worms, viruses, 13 phishing incidents, and denial of service, typically result in the 14 loss of service, data, and resources both human and system. Service 15 providers and Computer Security Incident Response Teams need to be 16 equipped and ready to assist in communicating and tracing security 17 incidents with tools and procedures in place before the occurrence of 18 an attack. Real-time Inter-network Defense (RID) outlines a 19 proactive inter-network communication method to facilitate sharing 20 incident handling data while integrating existing detection, tracing, 21 source identification, and mitigation mechanisms for a complete 22 incident handling solution. Combining these capabilities in a 23 communication system provides a way to achieve higher security levels 24 on networks. Policy guidelines for handling incidents are 25 recommended and can be agreed upon by a consortium using the security 26 recommendations and considerations. This document obsoletes RFC6045. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 3, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.1. Changes from RFC6045 . . . . . . . . . . . . . . . . . . . 5 64 1.2. Normative and Informative . . . . . . . . . . . . . . . . 7 65 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 66 2. Characteristics of Incidents . . . . . . . . . . . . . . . . . 7 67 3. Communication between CSIRTs and Service Providers . . . . . . 9 68 3.1. Inter-service Provider RID Messaging . . . . . . . . . . . 11 69 3.2. RID Communication Topology . . . . . . . . . . . . . . . . 13 70 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 14 71 4.1. RID Data Types . . . . . . . . . . . . . . . . . . . . . . 14 72 4.1.1. Boolean . . . . . . . . . . . . . . . . . . . . . . . 14 73 4.2. RID Message Types . . . . . . . . . . . . . . . . . . . . 14 74 5. IODEF-RID Schema . . . . . . . . . . . . . . . . . . . . . . . 15 75 5.1. RIDPolicy Class . . . . . . . . . . . . . . . . . . . . . 17 76 5.1.1. ReportSchema . . . . . . . . . . . . . . . . . . . . . 24 77 5.2. RequestStatus . . . . . . . . . . . . . . . . . . . . . . 26 78 5.3. IncidentSource . . . . . . . . . . . . . . . . . . . . . . 28 79 5.4. RID Name Spaces . . . . . . . . . . . . . . . . . . . . . 29 80 5.5. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 29 81 5.6. Including IODEF or other XML Documents . . . . . . . . . . 30 82 5.6.1. Including XML Documents in RID . . . . . . . . . . . . 31 83 6. RID Messages . . . . . . . . . . . . . . . . . . . . . . . . . 31 84 6.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 32 85 6.2. Acknowledgement . . . . . . . . . . . . . . . . . . . . . 34 86 6.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . . 35 87 6.4. Report . . . . . . . . . . . . . . . . . . . . . . . . . . 37 88 6.5. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 38 89 7. RID Communication Exchanges . . . . . . . . . . . . . . . . . 39 90 7.1. Upstream Trace Communication Flow . . . . . . . . . . . . 41 91 7.1.1. RID TraceRequest Example . . . . . . . . . . . . . . . 43 92 7.1.2. Acknowledgement Message Example . . . . . . . . . . . 47 93 7.1.3. Result Message Example . . . . . . . . . . . . . . . . 48 94 7.2. Investigation Request Communication Flow . . . . . . . . . 51 95 7.2.1. Investigation Request Example . . . . . . . . . . . . 52 96 7.2.2. Acknowledgement Message Example . . . . . . . . . . . 54 97 7.3. Report Communication Flow . . . . . . . . . . . . . . . . 55 98 7.3.1. Report Example . . . . . . . . . . . . . . . . . . . . 55 99 7.4. Query Communication Flow . . . . . . . . . . . . . . . . . 57 100 7.4.1. Query Example . . . . . . . . . . . . . . . . . . . . 58 101 8. RID Schema Definition . . . . . . . . . . . . . . . . . . . . 59 102 9. Security Requirements . . . . . . . . . . . . . . . . . . . . 63 103 9.1. XML Digital Signatures and Encryption . . . . . . . . . . 63 104 9.2. Message Transport . . . . . . . . . . . . . . . . . . . . 67 105 9.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 68 106 9.3.1. Authentication . . . . . . . . . . . . . . . . . . . . 69 107 9.3.2. Multi-Hop Request Authentication . . . . . . . . . . . 70 108 9.4. Consortiums and Public Key Infrastructures . . . . . . . . 71 109 9.5. Privacy Concerns and System Use Guidelines . . . . . . . . 72 110 9.6. Sharing Profiles and Policies . . . . . . . . . . . . . . 77 111 10. Security Considerations . . . . . . . . . . . . . . . . . . . 77 112 11. Internationalization Issues . . . . . . . . . . . . . . . . . 78 113 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79 114 13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 115 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81 116 14.1. Normative References . . . . . . . . . . . . . . . . . . . 81 117 14.2. Informative References . . . . . . . . . . . . . . . . . . 83 118 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 84 120 1. Introduction 122 Organizations require help from other parties to identify incidents, 123 mitigate malicious activity targeting their computing resources, and 124 to gain insight into potential threats through the sharing of 125 information. This coordination might entail working with a service 126 provider (SP) to filter attack traffic, working with a SP to resolve 127 a configuration issue unintentionally causing problems, contacting a 128 remote site to take down a bot- network, or sharing watch-lists of 129 known malicious IP addresses in a consortium. The term SP is to be 130 interpreted as any type of service provider or CSIRT that may be 131 involved in RID communications. 133 Incident handling involves the detection, reporting, identification, 134 and mitigation of an incident, whether it be a benign configuration 135 issue, IT incident, an infraction to a service level agreement (SLA), 136 system compromise, socially engineered phishing attack, or a denial- 137 of-service (DoS) attack, etc.. When an incident is detected, the 138 response may include simply filing a report, notification to the 139 source of the incident, a request to a SP for resolution/mitigation, 140 or a request to locate the source. One of the more difficult cases 141 is that in which the source of an attack is unknown, requiring the 142 ability to trace the attack traffic iteratively upstream through the 143 network for the possibility of any further actions to take place. In 144 cases when accurate records of an active session between the target 145 or victim system and the source or attacking system are available, 146 the source is easy to identify. 148 Real-time inter-network defense (RID) outlines a proactive inter- 149 network communication method to facilitate sharing incident handling 150 data while integrating existing detection, tracing, source 151 identification, and mitigation mechanisms for a complete incident 152 handling solution. RID provides a secure method to communicate 153 incident information, enabling the exchange of incident object 154 description and exchange format (IODEF) [RFC5070] extensible markup 155 language (XML) documents. RID considers security, policy, and 156 privacy issues related to the exchange of potentially sensitive 157 information, enabling service providers or organizations the options 158 to make appropriate decisions according to their policies. RID 159 includes provisions for confidentiality, integrity, and 160 authentication. 162 The data in RID messages is represented in an XML [XML1.0] document 163 using the IODEF and RID. By following this model, integration with 164 other aspects for incident handling is simplified. Methods are 165 incorporated into the communication system to indicate what actions 166 need to be taken closest to the source in order to halt or mitigate 167 the effects of the incident or attack at hand. RID is intended to 168 provide a method to communicate the relevant information between 169 computer security incident response teams (CSIRTs) while being 170 compatible with a variety of existing and possible future detection 171 tracing and response approaches. Incidents may be extended to 172 include Information Technology (IT) incidents, where RID enables the 173 communication between or within providers for non-security IT 174 incidents. 176 Security and privacy considerations are of high concern since 177 potentially sensitive information may be passed through RID messages. 178 RID messaging takes advantage of XML security, privacy, and policy 179 information set in the RID schema. The RID schema defines 180 communication specific metadata to support the communication of IODEF 181 documents for exchanging or tracing information regarding incidents. 182 RID messages are encapsulated for transport, which is defined in a 183 separate document [RFC6046-bis]. The authentication, integrity, and 184 authorization features RID and RID transport offer are used to 185 achieve a necessary level of security. 187 Coordinating with other CSIRTs is not strictly a technical problem. 188 There are numerous procedural, trust, and legal considerations that 189 might prevent an organization from sharing information. RID provides 190 information and options that can be used by organizations who must 191 then apply their own policies for sharing information. Organizations 192 must develop policies and procedures for the use of the RID protocol 193 and IODEF. 195 1.1. Changes from RFC6045 197 This document contains the following changes with respect to its 198 predecessor [RFC6045]: 200 o This document is on standards track while [RFC6045] was 201 informational, but now it is historic. 203 o This document, when published, obsoletes [RFC6045] and moves it to 204 Historic status. 206 o This document refers to the updated RID transport specification 207 [RFC6046-bis], where appropriate. 209 o Edits reflected in this updated version of RID are primarily 210 improvements to the informational descriptions. The descriptions 211 have been updated to clarify the use of IODEF and RID extend for 212 all types of incidents and are not limited to network security 213 incidents. The language has been updated to reduce a focus on 214 attacks and instead on incidents where appropriate. The term 215 network provider has been replaced with the more generic term of 216 service provider. Several introductory informational sections 217 have been removed as they are not necessary for the implementation 218 of the protocol. The sections include: 220 * 1.3. Attack Types and RID Messaging, 222 * 2. RID Integration with Network Provider Technologies, 224 * 3.1. Integrating Trace Approaches, and 226 * 3.2. Superset of Packet Information for Traces. 228 o An option for a star topology has been included in an 229 informational section to meet current use case requirements of 230 those who provide reports on incident information. 232 o The schema version was incremented. The schema has changed to 233 include IODEF [RFC5070] enveloped in RID in the RIDPolicy class 234 using the new ReportSchema class, to include reported errata, to 235 include additional enumerations in the Justification attribute, to 236 remove the AcrossNationalBoundaries region enumeration, to add the 237 DataWithHandlingRequirements enumeration in TrafficTypes, and to 238 change the name of the RequestAuthorization MsgType to 239 Acknowledgement. Additional text has been provided to clarify 240 definitions of enumerated values for some attributes. The 241 RequestAuthorization name was replaced with Acknowledgement to 242 more accurately represent the function of that message type. Text 243 was clarified to note the possible use of this message in response 244 to Query and Report messages. The attributes were fixed in the 245 schema to add 'lang' at the RID class level for language support. 247 o The TraceRequest and Investigation messages have been collapsed 248 into a single message with the requirement to set the MsgType 249 according to the functionality required for automation. The 250 message descriptions were identical with with exception of the 251 MsgType, which remains an exception depending on the desired 252 function. Since both of the enumerations for MsgType are each a 253 Request, 'Investigation' is now 'InvestigationRequest'. Content 254 may vary within the IODEF document for the type of Request 255 specified. 257 o The IncidentQuery message description name and MsgType enumeration 258 value in the schema has been changed to the more generic name of 259 'Query'. 261 o Guidance has improved to ensure consistent implementations and use 262 of XML encryption to provide confidentiality based on data 263 markers, specifically the iodef:restriction attribute in the IODEF 264 and IODEF-RID schemas. The attribute may also be present in IODEF 265 extension schemas, where the guidance also applies. Additional 266 guidance and restrictions have been added for XML requirements. 268 o All of the normative text from the Security Considerations Section 269 has been moved to a new Section, Security Requirements. 271 o The order in which the RID Schema is presented in Section 5 has 272 been changed to match the order in the IODEF-RID schema. 274 o Additional text has been provided to explain the content and 275 interactions between entities in the examples. 277 o Additional references have been provided to improve 278 interoperability with stricter guidance on the use of XML digital 279 signatures and encryption. 281 1.2. Normative and Informative 283 Section 1, 2, 3, and 12 provide helpful background information and 284 considerations. RID systems participating in a consortium are 285 REQUIRED to fully implement sections 4, 5, 6, 7, 8, 9, 10, and 11 to 286 prevent interoperability concerns. 288 1.3. Terminology 290 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 291 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 292 document are to be interpreted as described in [RFC2119]. 294 2. Characteristics of Incidents 296 An incident may be defined as a benign configuration issue, IT 297 incident, an infraction to a service level agreement (SLA), system 298 compromise, a worm or Trojan infection, or a single- or multiple- 299 source denial-of-service attack. The goal of tracing a security 300 incident may be to identify the source or to find a point on the 301 network as close to the origin of the incident as possible. Incident 302 tracing can be used to identify the source(s) of an attack in order 303 to halt or mitigate the undesired behavior or to correct an 304 identified issue. RID messages can be communicated between entities 305 to report or investigate any type of incident and allows for actions 306 to be taken when the source of the incident or a point closer to the 307 source is known or has been identified. Methods to accomplish 308 mitigation may include remediation of a configuration issue, 309 filtering or rate-limiting the traffic close to the source, or taking 310 the host or network offline. Care must also be taken to ensure that 311 the systems involved in the RID communications are not abused and to 312 use proper analysis in determining if attack traffic is, in fact, 313 attack traffic at each SP involved in the investigation. 315 Investigating security incidents can be a difficult task since 316 attackers go to great lengths to obscure their identity. In the case 317 of a security incident, the true source might be identified through 318 an existing established connection to the attacker's point of origin. 319 However, the attacker may not connect to the compromised system for a 320 long period of time after the initial compromise or may access the 321 system through a series of compromised hosts spread across the 322 network. Other methods of obscuring the source may include targeting 323 the host with the same attack from multiple sources using both valid 324 and spoofed source addresses. This tactic can be used to compromise 325 a machine and leave the difficult task of locating the true origin 326 for the administrators. Attackers use many techniques which can vary 327 between individuals or even organized groups of attackers. Through 328 analysis, the techniques may be grouped into indicators of compromise 329 to be shared via IODEF and RID, further assisting with the 330 improvement of detection capabilities. Security incidents, including 331 DDoS attacks, can be difficult or nearly impossible to trace because 332 of the nature of the attack. Some of the difficulties in 333 investigating attacks include the following: 335 o the incident or attack originates from multiple sources; 337 o the incident may leverage social engineering techniques or other 338 methods to gain access to resources and intellectual property 339 using what appears to be legitimate access methods such as 340 outbound web sessions from user systems; 342 o the attack may include various types of traffic meant to consume 343 server resources, such as a SYN flood attack without a significant 344 increase in bandwidth utilization; 346 o the type of traffic could include valid destination services, 347 which cannot be blocked since they are essential services to 348 business, such as DNS servers at an SP or HTTP requests sent to an 349 organization connected to the Internet; 351 o the attack may utilize varying types of packets including TCP, 352 UDP, ICMP, or other IP protocols; 354 o the attack may be from "zombies" or large "botnets", which then 355 require additional searches to locate a controlling server as the 356 true origin of the attack; 358 o the attack may use a very small number of packets from any 359 particular source, thus making a trace after the fact nearly 360 impossible; 362 o the indicators of a compromise may be difficult to detect. 364 If the source(s) of an incident cannot be determined from IP address 365 information it may be possible to trace the traffic based on 366 characteristics of the incident such as tracing the increased 367 bandwidth utilization or the type of packets seen by the client. In 368 the case of packets with spoofed source addresses, it is not a 369 trivial task to identify the source of an attack. 371 IODEF, any extensions to IODEF, and RID can be used to detail an 372 incident, characteristics of the incident (as it evolves), the 373 incident history, and communications of the incident to facilitate 374 the resolution and reporting of the incident. 376 3. Communication between CSIRTs and Service Providers 378 Expediting the communication between CSIRTs and SPs is essential when 379 responding to a security-related incident, which may cross network 380 access points between service providers. As a result of the urgency 381 involved in this inter-service provider security incident 382 communication, there must be an effective system in place to 383 facilitate the interaction. This communication policy or method 384 should involve multiple means of communication to avoid a single 385 point of failure. Email is one way to transfer information about the 386 incident, packet traces, etc. However, email may not be received in 387 a timely fashion or be acted upon with the same urgency as a phone 388 call or other communication mechanism like RID. 390 A technical solution to trace traffic across a single SP may include 391 homegrown or commercial systems for which RID messaging must 392 accommodate the input requirements. The incident handling system 393 used on the SP's backbone by the CSIRT to coordinate the trace across 394 the single network requires a method to accept, process, and relay 395 RID messages to the system, as well as to wait for responses from the 396 system to continue the RID request process as appropriate. In this 397 scenario, each service provider maintains its own system capable of 398 communicating via RID and integrates with a management station used 399 for monitoring and analysis. An alternative for providers lacking 400 sufficient resources may be to have a neutral third party with access 401 to the provider's network resources who could be used to perform the 402 incident handling functions. This could be a function of a central 403 organization operating as a CSIRT for countries as a whole or within 404 a consortium that may be able to provide centralized resources. 406 Consortiums could consist of a group of service providers, CSIRTs, or 407 other federation that agrees to participate in the RID communication 408 protocol with an agreed-upon policy and communication protocol 409 facilitating the secure transport of IODEF/RID XML documents. 410 Transport for RID messages is specified in [RFC6046-bis]. 412 One goal of RID is to prevent the need to permit access to other 413 networks' equipment. RID provides a standard messaging mechanism to 414 enable the communication of incident handling information to other 415 providers in a consortium or in neighboring networks. The third 416 party mentioned above may be used in this technical solution to 417 assist in facilitating incident handling and possibly traceback 418 through smaller providers. The RID messaging mechanism may be a 419 logical or physical out-of-band network to ensure that the 420 communication is secure and unaffected by the state of the network 421 under attack. The two management methods would accommodate the needs 422 of larger providers to maintain full management of their network, and 423 the third-party option could be available to smaller providers who 424 lack the necessary human resources to perform incident handling 425 operations. The first method enables the individual providers to 426 involve their network operations staff to authorize the continuance 427 of a trace or other necessary response to a RID communication request 428 through their network via a notification and alerting system. 430 The network used for the communication should consist of out-of-band 431 or protected channels (direct communication links) or encrypted 432 channels dedicated to the transport of RID messages. The 433 communication links would be direct connections (virtual or physical) 434 between peers who have agreed-upon use and abuse policies through a 435 consortium. Consortiums might be linked through policy comparisons 436 and additional agreements to form a larger web or iterative network 437 of peers that correlates to the traffic paths available over the 438 larger web of networks or based on regions and logical groups. 439 Contact information, IP addresses of RID systems, and other 440 information must be coordinated between bilateral peers by a 441 consortium and may use existing databases, such as the routing 442 arbiter. The security, configuration, and confidence rating schemes 443 of the RID messaging peers must be negotiated by peers and must meet 444 certain overall requirements of the fully connected network 445 (Internet, government, education, etc.) through the peering and/or a 446 consortium-based agreement. 448 RID messaging established with clients of an provider may be 449 negotiated in a contract as part of a value-added service or through 450 a service level agreement (SLA). Further discussion is beyond the 451 scope of this document and may be more appropriately handled in 452 peering or service level agreements. 454 Procedures for incident handling need to be established and well 455 known by anyone that may be involved in incident response. The 456 procedures should also contain contact information for internal 457 escalation procedures, as well as for external assistance groups such 458 as a CSIRT, CERT Coordination Center (CERT/CC), Global Information 459 Assurance Certification (GIAC), and the U.S. Federal Bureau of 460 Investigations (FBI) or other assisting government organization in 461 the country of the investigation. 463 3.1. Inter-service Provider RID Messaging 465 RID provides a protocol and format that ensures interoperability 466 between vendors for the implementation of an incident messaging 467 mechanism. The messages should meet several requirements in order to 468 be meaningful as they traverse multiple networks. RID provides the 469 framework necessary for communication between networks involved in 470 the incident handling, possible traceback, and mitigation of a 471 security incident. Several message types described in Section 4.2 472 are necessary to facilitate the handling of a security incident. The 473 message types include the Report, Query, Request, Acknowledgement, 474 and Result message. 476 The Report message is used when an incident is to be filed on a RID 477 system or associated database, where no further action is required. 478 A Query message is used to request information on a particular 479 incident. A Request message with options set for a TraceRequest is 480 used when the source of the traffic may have been spoofed. In that 481 case, each SP in the upstream path who receives this Request will 482 issue a trace across the network to determine the upstream source of 483 the traffic. The Acknowledgement and Result messages are used to 484 communicate the status and result of a Request. The Request message 485 with options set for an InvestigationRequest may be sent to any party 486 assisting in an incident investigation. The investigation Request 487 message leverages the bilateral relationships or a consortium's 488 interconnections to mitigate or stop problematic traffic close to the 489 source. Routes could determine the fastest path to a known source IP 490 address in the case of an investigation Request. A Request message 491 (TraceRequest or an InvestigationRequest) sent between RID systems to 492 stop traffic at the source through a bordering network requires the 493 information enumerated below: 495 1. Enough information to enable the network administrators to make a 496 decision about the importance of continuing the trace. 498 2. The incident or IP packet information needed to carry out the 499 trace or investigation. 501 3. Contact information of the origin of the RID communication. The 502 contact information could be provided through the Autonomous 503 System Number (ASN) [RFC1930] or Network Information Center (NIC) 504 handle information listed in the Registry for Internet Numbers or 505 other Internet databases. 507 4. Network path information to help prevent any routing loops 508 through the network from perpetuating a trace. If a RID system 509 receives a Request with the TraceRequest option set that contains 510 its own information in the path, the trace must cease and the RID 511 system should generate an alert to inform the network operations 512 staff that a tracing loop exists. 514 5. A unique identifier for a single attack. This identifier should 515 be used to correlate traces to multiple sources in a DDoS attack. 517 Use of the communication network and the RID protocol must be for 518 pre-approved, authorized purposes only. It is the responsibility of 519 each participating party to adhere to guidelines set forth in both a 520 global use policy established through the peering agreements for each 521 bilateral peer or agreed-upon consortium guidelines. The purpose of 522 such policies is to avoid abuse of the system; the policies shall be 523 developed by a consortium or participating entities. The global 524 policy may be dependent on the domain it operates under; for example, 525 a government network or a commercial network such as the Internet 526 would adhere to different guidelines to address the individual 527 concerns. Privacy issues must be considered in public networks such 528 as the Internet. Privacy issues are discussed in the Security 529 Requirements section, along with other requirements that must be 530 agreed upon by participating entities. 532 RID requests must be legitimate incidents and not used for purposes 533 such as sabotage or censorship. An example of such abuse of the 534 system includes a request to rate-limit legitimate traffic to prevent 535 information from being shared between users on the Internet 536 (restricting access to online versions of papers) or restricting 537 access from a competitor's product in order to sabotage a business. 539 The RID system should be configurable to either require user input or 540 automatically continue traces. This feature enables a network 541 manager to assess the available resources before continuing an 542 investigation or trace Request. If the Confidence rating (provided 543 in IODEF) is low, it may not be in the provider's best interest to 544 continue the investigation or trace Request. The Confidence ratings 545 must adhere to the specifications for selecting the percentage used 546 to avoid abuse of the system. Requests must be issued by authorized 547 individuals from the initiating CSIRT, set forth in policy guidelines 548 established through peering or a SLA. 550 3.2. RID Communication Topology 552 The most basic topology for communicating RID systems is a direct 553 connection or a bilateral relationship as illustrated below. 555 ___________ __________ 556 | | | | 557 | RID |__________-------------___________| RID | 558 |_________| | SP Border | |________| 559 ------------- 561 Figure 1: Direct Peer Topology 563 Within the consortium model, several topologies might be agreed upon 564 and used. One would leverage bilateral network peering relationships 565 of the members of the consortium. The peers for RID would match that 566 of routing peers, and the logical network borders would be used. 567 This approach may be necessary for an iterative trace where the 568 source is unknown. The model looks like the above diagram; however, 569 there may be an extensive number of interconnections of bilateral 570 relationships formed. Also within a consortium model, it may be 571 useful to establish an integrated mesh of networks to pass RID 572 messages. This may be beneficial when the source address is known, 573 and an interconnection may provide a faster route to reach the 574 closest upstream peer to the source of the attack traffic if direct 575 communication between SPs is not possible. An example is illustrated 576 below. 578 _______ _______ _______ 579 | | | | | | 580 __| RID |____-------------____| RID |____-------------____| RID |__ 581 |_____| | SP Border | |_____| | SP Border | |_____| 582 | ------------- ------------- | 583 |_______________________________________________________| 585 Direct connection to network that is not an immediate network peer 587 Figure 2: Mesh Peer Topology 589 By using a fully meshed model in a consortium, broadcasting RID 590 requests would be possible, but not advisable. By broadcasting a 591 request, RID peers that may not have carried the attack traffic on 592 their network would be asked to perform a trace for the potential of 593 decreasing the time in which the true source was identified. As a 594 result, many networks would have utilized unnecessary resources for a 595 Request that may have also been unnecessary. 597 A star topology may be desirable in instances where a peer may be a 598 provider of incident information. This requires trust relationships 599 to be established between the provider of information and each of the 600 consumers of that information. Examples may include country level 601 CSIRTs or service providers distributing incident information to 602 organizations. 604 4. Message Formats 606 4.1. RID Data Types 608 RID is derived from the IODEF data model and inherits all of the data 609 types defined in the IODEF model. One data type is added by RID: 610 BOOLEAN. 612 4.1.1. Boolean 614 A boolean value is represented by the BOOLEAN data type. 616 The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in 617 the schema. Note that there are two lexical representations for 618 boolean in [XMLschema]: '1' or 'true' for TRUE and '0' or 'false' or 619 FALSE. 621 4.2. RID Message Types 623 The five RID message types described below MUST be implemented. RID 624 messages uses both the IODEF [RFC5070] and RID document, which MUST 625 be encapsulated for transport as specified in [RFC6046-bis]. The 626 messages are generated and received on designated systems for RID 627 communications. Each RID message type, along with an example, is 628 described in the following sections. The IODEF-RID schema is 629 introduced in Section 5 to support the described RID message types. 631 1. Request. This message type is used for an investigation or trace 632 Request is needed. The purpose of the investigation Request 633 message is to leverage the existing peer relationships in order 634 to notify the SP closest to the source of the valid traffic of a 635 security-related incident for any necessary actions to be taken. 636 The Request for a trace request is used when the traffic has to 637 be traced iteratively through networks to find the source by 638 setting the MsgType to 'TraceRequest'. The 639 'InvestigationRequest' MsgType is used for all other Request 640 messages. 642 2. Acknowledgement. This message is sent to the initiating RID 643 system from each of the upstream providers' RID systems to 644 provide information on the status of a Request. The 645 Acknowledgement is also used to provide a reason why a Request, 646 Report, or Query was not accepted. 648 3. Result. The Result message is used to provide a final report and 649 the notification of actions taken for a Request. This message is 650 sent to the initiating CSIRT through the network of RID systems 651 in the path of the trace as notification that the source of the 652 attack was located. 654 4. Report. This message is used to report a security incident, for 655 which no action is requested. This may be used for the purpose 656 of correlating attack information by CSIRTs, sharing incident 657 information, statistics and trending information, etc. 659 5. Query. This message is used to request information about an 660 incident or incident type from a trusted system communicating via 661 RID. The response is provided through the Report message. 663 When an application receives a RID message, it must be able to 664 determine the type of message and parse it accordingly. The message 665 type is specified in the RIDPolicy class. The RIDPolicy class may 666 also be used by the transport protocol to facilitate the 667 communication of security incident data to trace, investigate, query, 668 or report information regarding security incidents. 670 5. IODEF-RID Schema 672 There are three classes included in the RID extension required to 673 facilitate RID communications. The RequestStatus class is used to 674 indicate the approval status of a Request message; the IncidentSource 675 class is used to report whether or not a source was found and to 676 identify the source host(s) or network(s); and the RIDPolicy class 677 provides information on the agreed-upon policies and specifies the 678 type of communication message being used. 680 The RID schema defines communication specific metadata to support the 681 exchange of incident information in an IODEF document. The intent in 682 maintaining a separate schema and not using the AdditionalData 683 extension of IODEF is the flexibility of sending messages between RID 684 hosts. Since RID is a separate schema and RID messages include both 685 the RID and IODEF documents, the RID message acts as an envelope in 686 that policy and security defined at the RID message layer are applied 687 to both documents. One reason for maintaining separate schemas is 688 for flexibility, where the RIDPolicy class can be easily extracted 689 for use in the RID message and by the transport protocol. 691 The security requirements of sending incident information between 692 entities include the use of encryption. The RIDPolicy information is 693 not required to be encrypted, so separating out this data from the 694 IODEF XML document removes the need for decrypting and parsing the 695 IODEF document to determine how it should be handled at each RID 696 host. 698 The purpose of the RIDPolicy class is to specify the message type for 699 the receiving host, facilitate the policy needs of RID, and provide 700 routing information in the form of an IP address of the destination 701 RID system. 703 The security requirements and policy guidelines are discussed in 704 Section 9. The policy is defined between RID peers and within or 705 between consortiums. RIDPolicy is meant to be a tool to facilitate 706 the defined policies. This MUST be used in accordance with policy 707 set between clients, peers, consortiums, and/or regions. Security, 708 privacy, and confidentiality MUST be considered as specified in this 709 document. 711 The RID schema is defined as follows: 713 +------------------+ 714 | RID | 715 +------------------+ 716 | | 717 | ENUM lang |<>---{0..1}----[ RIDPolicy ] 718 | | 719 | |<>---{0..1}----[ RequestStatus ] 720 | | 721 | |<>---{0..1}----[ IncidentSource ] 722 +------------------+ 724 Figure 3: The RID Schema 726 The aggregate classes that constitute the RID schema in the iodef-rid 727 namespace are as follows: 729 RIDPolicy 731 Zero or One. The RIDPolicy class is used by all message types to 732 facilitate policy agreements between peers, consortiums, or 733 federations, as well as to properly route messages. 735 RequestStatus 737 Zero or One. The RequestStatus class is used only in 738 Acknowledgement messages. The message reports back to the CSIRT 739 or SP in the Acknowledgement message to provide status on a 740 Request or if an error or problem occurs with the receipt or 741 processing of a Report, Query, or Result message. 743 IncidentSource 745 Zero or One. The IncidentSource class is used in the Result 746 message only. The IncidentSource provides the information on the 747 identified source host or network of an attack trace or 748 investigation. 750 Each of the three listed classes may be the only class included in 751 the RID class, hence the option for zero or one. In some cases, 752 RIDPolicy MAY be the only class in the RID definition when used by 753 the transport protocol [RFC6046-bis], as that information should be 754 as small as possible and may not be encrypted. The RequestStatus 755 message MUST be able to stand alone without the need for an IODEF 756 document to facilitate the communication, limiting the data 757 transported to the required elements per [RFC6046-bis]. 759 The RID class has one attribute: 761 lang 763 One. REQUIRED. ENUM. A valid language code per [RFC5646] 764 constrained by the definition of "xs:language" inherited from 765 [XML1.0]. 767 5.1. RIDPolicy Class 769 The RIDPolicy class facilitates the delivery of RID messages and is 770 also referenced for transport in the transport document [RFC6046- 771 bis]. The RIDPolicy Class includes the ability to embed an IODEF or 772 other XML documents that conform to schemas other than IODEF in the 773 ReportSchema element. 775 +------------------------+ 776 | RIDPolicy | 777 +------------------------+ 778 | | 779 | ENUM restriction |<>-------------[ Node ] 780 | ENUM MsgType | 781 | ENUM MsgDestination |<>---{0..1}----[ IncidentID ] 782 | ENUM ext-MsgType | 783 | ENUM ext-MsgDestination|<>---{1..*}----[ PolicyRegion ] 784 | | 785 | |<>---{1..*}----[ TrafficType ] 786 | | 787 | |<>---{0..1}----[ ReportSchema ] 788 +------------------------+ 790 Figure 4: The RIDPolicy Class 792 The aggregate elements that constitute the RIDPolicy class are as 793 follows: 795 Node 797 One. The Node class is used to identify a host or network device, 798 in this case to identify the system communicating RID messages and 799 the usage is determined by the MsgDestination attribute. The base 800 definition of this class is reused from the IODEF specification 801 [RFC5070], Section 3.16. See Section 11 of this document for 802 Internationalization considerations. 804 IncidentID 806 Zero or one. Global reference pointing back to the IncidentID 807 defined in the IODEF data model. The IncidentID includes the name 808 of the CSIRT, an incident number, and an instance of that 809 incident. The instance number is appended with a dash separating 810 the values and is used in cases for which it may be desirable to 811 group incidents. Examples of incidents that may be grouped 812 include botnets, polymorphic attacks, DDoS attacks, multiple hops 813 of compromised systems found during an investigation, etc. 815 PolicyRegion 817 One or many. REQUIRED. The values for the attribute "region" are 818 used to determine what policy area may require consideration 819 before a trace can be approved. The PolicyRegion may include 820 multiple selections from the attribute list in order to fit all 821 possible policy considerations when crossing regions, consortiums, 822 or networks. 824 region 826 One or many. REQUIRED. ENUM. The attribute region is used to 827 identify the expected sharing range of the incident information. 828 The region may be within a region or defined by existing 829 relationships such as those of a consortium or client to service 830 provider. 832 1. ClientToSP. A client initiated the request to their service 833 provider (SP). A client may be an individual, enterprise, or 834 other type of entity (government, commercial, education, 835 etc.). An SP may be a network, telecommunications, 836 infrastructure, or other type of SP where a client to vendor 837 relationship has been established. The client to vendor 838 relationship will typically have established contracts or 839 agreements to define expectations and trust relationships. 841 2. SPToClient. A service provider (SP) initiated a RID request 842 or report to a client. A client may be an individual, 843 enterprise, or other type of entity (government, commercial, 844 education, etc.). An SP may be a network, telecommunications, 845 infrastructure, or other type of SP where a client to vendor 846 relationship has been established. The client to vendor 847 relationship will typically have established contracts or 848 agreements to define expectations and trust relationships. 850 3. IntraConsortium. Incident information that should have no 851 restrictions within the boundaries of a consortium with the 852 agreed-upon use and abuse guidelines. A consortium is a well 853 defined group with established members and trust relationships 854 specific to sharing within that group. A consortium would 855 typically define the types of data that can be shared in 856 advance, expectations on protecting that data, as well as 857 having established contractual agreements. Examples of 858 consortiums may include industry focused sharing communities 859 (financial, government, research and education, etc.) or cross 860 industry sharing communities (for instance, organizations 861 within local proximity that form a sharing group). 863 4. PeerToPeer. Incident information that should have no 864 restrictions between two peers but may require further 865 evaluation before continuance beyond that point with the 866 agreed-upon use and abuse guidelines. PeerToPeer 867 communications may involve any two individuals or entities 868 that decide to share information directly with each other. 870 5. BetweenConsortiums. Incident information that should have no 871 restrictions between consortiums that have established agreed- 872 upon use and abuse guidelines. BetweenConsortiums is used 873 when two consortiums (as defined in IntraConsortium above) 874 share data. The types of data that can be shared 875 BetweenConsortiums should be identified in their agreements 876 and contracts along with expectations on how that data should 877 be handled and protected. 879 6. ext-value. An escape value used to extend this attribute. 880 See IODEF [RFC5070], Section 5.1. 882 TrafficType 884 One or many. REQUIRED. The values for the attribute "type" are 885 meant to assist in determining if a trace is appropriate for the 886 SP receiving the request to continue the trace. Multiple values 887 may be selected for this element; however, where possible, it 888 should be restricted to one value that most accurately describes 889 the traffic type. 891 type 893 One or many. REQUIRED. ENUM. The attribute type is used to 894 identify the type of information included in the RID message or 895 the type of incident. 897 1. Attack. This option SHOULD only be selected if the traffic is 898 related to a information security incident or attack. The 899 type of attack MUST also be listed in more detail in the IODEF 900 Method and Impact classes for further clarification to assist 901 in determining if the trace can be continued ([RFC5070], 902 Sections 3.9 and 3.10.1). 904 2. Network. This option MUST only be selected when the trace is 905 related to network traffic or routing issues. 907 3. Content. This category MUST be used only in the case in which 908 the request is related to the content and regional 909 restrictions on accessing that type of content exist. This is 910 not malicious traffic but may include determining what sources 911 or destinations accessed certain materials available on the 912 Internet, including, but not limited to, news, technology, or 913 inappropriate content. 915 4. DataWithHandlingRequirements. This option is used when data 916 shared may have additional restrictions for handling, 917 protection, and processing based on the type of data and where 918 it resides. Regulatory or legal restrictions may be imposed 919 on specific types of data that could vary based on the 920 location, region or nation, of the data or where it 921 originated. The IODEF document included, as well as any 922 extensions, with the RID message should indicate the specific 923 restrictions to be considered. The use of this enumeration 924 flag is not legally binding. 926 5. AudienceRestriction. This option is used to indicate the 927 message contains data that should be viewed by a restricted 928 audience. This setting should not be used for normal 929 incidents or reporting as it could slow response times. The 930 content may be a business relevant notification or request. 931 This option MAY be used by a business partner to report or 932 request assistance if an incident has effected a supply chain. 933 This option may also be used if the content is relevant to a 934 regulatory obligations, legal (eDiscovery), or other use cases 935 that require management attention. 937 6. Other. If this option is selected, a description of the 938 traffic type MUST be provided so that policy decisions can be 939 made to continue or stop the investigation. The information 940 should be provided in the IODEF message in the Expectation 941 class or in the History class using a HistoryItem log. This 942 may also be used for incident types other than information 943 security related incidents. 945 7. ext-value. An escape value used to extend this attribute. 946 See IODEF [RFC5070], Section 5.1. 948 ReportSchema 950 Zero or One. The ReportSchema class is used by the message 951 types that require the full IODEF schema to be included in the 952 RID envelope. Alternate schemas may be included if approved by 953 the Designated Reviewer and registered by IANA for use with 954 RID. 956 The RIDPolicy class has five attributes: 958 restriction 960 OPTIONAL. ENUM. This attribute indicates the disclosure 961 guidelines to which the sender expects the recipient to adhere. 962 This guideline provides no real security since it is the choice 963 of the recipient of the document to honor it. This attribute 964 follows the same guidelines as "restriction" used in IODEF. 966 MsgType 968 One. REQUIRED. ENUM. The type of RID message sent. The five 969 types of messages are described in Section 4.2 and can be noted 970 as one of the six selections below, where a Request is set to 971 either an InvestigationRequest or TraceRequest. 973 1. TraceRequest. This Request message may be used to initiate 974 a TraceRequest or to continue a TraceRequest to an upstream 975 network closer to the source address of the origin of the 976 security incident. 978 2. Acknowledgement. This message is sent to the initiating 979 RID system from each of the upstream RID systems to provide 980 information on the request status in the current network. 982 3. Result. This message indicates that the source of the 983 attack was located and the message is sent to the 984 initiating RID system through the RID systems in the path 985 of the trace. 987 4. InvestigationRequest. This Request message type is used 988 when the source of the traffic is believed to be valid. 989 The purpose of the InvestigationRequest is to leverage the 990 existing peer or consortium relationships in order to 991 notify the SP closest to the source of the valid traffic 992 that some event occurred, which may be a security-related 993 incident. 995 5. Report. This message is used to report a security 996 incident, for which no action is requested in the IODEF 997 Expectation class. This may be used for the purpose of 998 correlating attack information by CSIRTs, statistics and 999 trending information, etc. 1001 6. Query. This message is used to request information from a 1002 trusted RID system about an incident or incident type. 1004 Additionally, there is an extension attribute to add new 1005 enumerated values: 1007 ext-value. An escape value used to extend this attribute. See 1008 IODEF [RFC5070], Section 5.1. 1010 MsgDestination 1012 One. REQUIRED. ENUM. The destination required at this level 1013 may either be the RID messaging system intended to receive the 1014 request, or, in the case of a Request with MsgType set to 1015 'InvestigationRequest', the source of the incident. In the 1016 case of an InvestigationRequest, the RID system that can help 1017 stop or mitigate the traffic may not be known, and the message 1018 may have to traverse RID messaging systems by following the 1019 routing path to the RID system closest to the source of the 1020 attack traffic. The Node element lists either the RID system 1021 or the IP address of the source, and the meaning of the value 1022 in the Node element is determined by the MsgDestination 1023 element. 1025 1. RIDSystem. The IP address of the next upstream system 1026 accepting RID communications is REQUIRED and is listed in 1027 the Node element of the RIDPolicy class. If NodeName 1028 element of the Node class is used, it contains a DNS domain 1029 name. The originating RID system is required to check that 1030 this domain name resolves to the IP address to which the 1031 RID message is sent. This check may be performed in 1032 advance of sending the message and the result saved for 1033 future use with additional RID messages. 1035 2. SourceOfIncident. The Address element of the Node element 1036 contains the IP address of the incident source, and the 1037 NodeName element of the Node class is not used. The IP 1038 address is REQUIRED when this option is selected. The IP 1039 address is used to determine the path of systems accepting 1040 RID communications that will be used to find the closest 1041 RID system to the source of an attack in which the IP 1042 address used by the source is believed to be valid and a 1043 Request message with MsgDst set to InvestigationRequest is 1044 used. This is not to be confused with the IncidentSource 1045 class, as the defined value here is from an initial trace 1046 or investigation Request, not the source used in a Result 1047 message. 1049 3. ext-value. An escape value used to extend this attribute. 1050 All extensions shall specify the contents and meaning of 1051 the Node element of RIDPolicy. See IODEF [RFC5070], 1052 Section 5.1 on extensibility. If the NodeName element of 1053 the Node class is used by an extension, NodeName may 1054 contain an Internationalized Domain Name (IDN); see Section 1055 11 for applicable requirements. All extensions SHOULD use 1056 an IP address in the Address element of the Node class as 1057 the primary means of Node identification. 1059 MsgType-ext 1060 OPTIONAL. STRING. A means by which to extend the MsgType 1061 attribute. See IODEF [RFC5070], Section 5.1. 1063 MsgDestination-ext 1065 OPTIONAL. STRING. A means by which to extend the 1066 MsgDestination attribute. See IODEF [RFC5070], Section 5.1 1068 5.1.1. ReportSchema 1070 The ReportSchema class is an aggregate class in the RIDPolicy class. 1071 The IODEF schema is the approved schema for inclusion in RID messages 1072 via the ReportSchema class. 1074 +-------------------------+ 1075 | ReportSchema | 1076 +-------------------------+ 1077 | | 1078 | ENUM Version | 1079 | STRING ext-Version |<>---{1}-------[ XMLDocument ] 1080 | ENUM XMLSchemaID | 1081 | STRING ext-XMLSchemaID |<>---{0..1}----[ URL ] 1082 | | 1083 | |<>---{0..*}----[ Signature ] 1084 | | 1085 +-------------------------+ 1087 Figure 5: The ReportSchema Class 1089 The elements that constitute the ReportSchema class are as follows: 1091 XMLDocument 1093 One. The XMLDocument is a complete XML document defined by the 1094 iodef:ExtensionType class. This class follows the guidelines 1095 in [RFC5070] Section 5 where the data type is set to "xml" and 1096 meaning is set to "xml" to include an xml document. 1098 URL 1100 Zero or One. URL. A reference to the XML schema of the XML 1101 document included. The URL data type is defined in [RFC5070] 1102 Section 2.15 as "xs:anyURI" in the schema. The schemaLocation 1103 for IODEF is already included in the RID schema, so this is not 1104 necessary to include a URL for IODEF documents. The list of 1105 registered schemas for inclusion will be maintained by IANA. 1107 Signature 1109 Zero to many. The Signature uses the iodef:ExtensionType class 1110 to enable this element to contain a detached or enveloped 1111 signature. This class follows the guidelines in [RFC5070] 1112 Section 5 where the data type is set to "xml" and meaning is 1113 set to "xml" to include an xml document. This element is used 1114 to encapsulate the detached signature based on the iodef: 1115 RecordItem class within the IODEF document to verify the 1116 originator of the message or to include the enveloped 1117 signature. If other schemas are used instead of IODEF, they 1118 MUST provide guidance on what class to use if a detached 1119 signature is provided for this purpose. 1121 The ReportSchema class has four attributes: 1123 Version 1125 OPTIONAL. One. The Version attribute is the version number of 1126 the specified XML schema. That schema must be an approved 1127 version of IODEF or a schema registered with IANA for use with 1128 RID. The IANA registry for managing schemas other than IODEF 1129 is specified in Section 11. 1131 ext-value. An escape value used to extend this attribute. 1132 See IODEF [RFC5070], Section 5.1. 1134 ext-Version 1136 OPTIONAL. One. The ext-Version attribute is the version number 1137 of the included XML schema. This attribute is used if a schema 1138 other than IODEF or an IANA registered schema that has been 1139 added to the enumerated list for Version is included. 1141 XMLSchemaID 1143 OPTIONAL. One. The XMLSchemaID attribute is the identifier, 1144 the defined namespace[XMLNames], of the XML schema of the XML 1145 document included. The XMLSchemaID and Version specify the 1146 format of the XMLDocument element. The only permitted values, 1147 include the namespace for IODEF [RFC5070], 1148 "urn:ietf:params:xml:ns:iodef-1.0", any future IETF approved 1149 versions of IODEF, and any namespace included in the IANA 1150 managed list of registered schemas for use with RID. The IANA 1151 registry for managing schemas other than IODEF is specified in 1152 Section 11. 1154 ext-value. An escape value used to extend this attribute. 1155 See IODEF [RFC5070], Section 5.1. 1157 ext-XMLSchemaID 1159 OPTIONAL. One. The ext-XMLSchemaID attribute is the identifier 1160 (defined namespace) of the XML schema of the XML document 1161 included. The ext-XMLSchemaID and ext-Version specify the 1162 format of the XMLDocument element and are used if the included 1163 schema is not IODEF version 1.0 or an IANA registered schema 1164 that has been added to the enumerated list for XMLSchemaID. 1166 5.2. RequestStatus 1168 The RequestStatus class is an aggregate class in the RID class. 1170 +--------------------------------+ 1171 | RequestStatus | 1172 +--------------------------------+ 1173 | | 1174 | ENUM restriction | 1175 | ENUM AuthorizationStatus | 1176 | ENUM Justification | 1177 | STRING ext-AuthorizationStatus | 1178 | STRING ext-Justification | 1179 | | 1180 +--------------------------------+ 1182 Figure 6: The RequestStatus Class 1184 The RequestStatus class has five attributes: 1186 restriction 1188 OPTIONAL. ENUM. This attribute indicates the disclosure 1189 guidelines to which the sender expects the recipient to adhere. 1190 This guideline provides no real security since it is the choice 1191 of the recipient of the document to honor it. This attribute 1192 follows the same guidelines as "restriction" used in IODEF. 1194 AuthorizationStatus 1196 One. REQUIRED. ENUM. The listed values are used to provide a 1197 response to the requesting CSIRT of the status of a Request, 1198 Report, or Query. 1200 1. Approved. The trace was approved and will begin in the 1201 current SP. 1203 2. Denied. The trace was denied in the current SP. The next 1204 closest SP can use this message to filter traffic from the 1205 upstream SP using the example packet to help mitigate the 1206 effects of the attack as close to the source as possible. 1207 The Acknowledgement message must be passed back to the 1208 originator and a Result message used from the closest SP to 1209 the source to indicate actions taken in the IODEF History 1210 class. 1212 3. Pending. Awaiting approval; a timeout period has been 1213 reached, which resulted in this Pending status and 1214 Acknowledgement message being generated. 1216 4. ext-value. An escape value used to extend this attribute. 1217 See IODEF [RFC5070], Section 5.1. 1219 Justification 1221 OPTIONAL. ENUM. Provides a reason for a Denied or Pending 1222 message. 1224 1. SystemResource. A resource issue exists on the systems 1225 that would be involved in the request. 1227 2. Authentication. The enveloped digital signature 1228 [RFC3275] failed to validate. 1230 3. AuthenticationOrigin. The detached digital signature 1231 for the original requestor on the RecordItem entry 1232 failed to validate. 1234 4. Encryption. Unable to decrypt the request, report, or 1235 query. 1237 5. UnrecognizedFormat. The format of the provided document 1238 was unrecognized. 1240 6. CannotProcess. The document could not be processed. 1241 Reasons may include legal or policy decisions. 1242 Resolution may require communication outside of this 1243 protocol to resolve legal or policy issues. No further 1244 messages SHOULD be sent until resolved. 1246 7. Other. There were other reasons this request could not 1247 be processed. 1249 8. ext-value. An escape value used to extend this 1250 attribute. See IODEF [RFC5070], Section 5.1. 1252 AuthorizationStatus-ext 1254 OPTIONAL. STRING. A means by which to extend the 1255 AuthorizationStatus attribute. See IODEF [RFC5070], Section 1256 5.1. 1258 Justification-ext 1260 OPTIONAL. STRING. A means by which to extend the 1261 Justification attribute. See IODEF [RFC5070], Section 5.1. 1263 5.3. IncidentSource 1265 The IncidentSource class is an aggregate class in the RID class. 1267 +-------------------+ 1268 | IncidentSource | 1269 +-------------------+ 1270 | | 1271 | ENUM restriction | 1272 | |<>-------------[ SourceFound ] 1273 | | 1274 | |<>---{0..*}----[ Node ] 1275 | | 1276 +-------------------+ 1278 Figure 7: The IncidentSource Class 1280 The elements that constitute the IncidentSource class follow: 1282 SourceFound 1284 One. BOOLEAN. The Source class indicates if a source was 1285 identified. If the source was identified, it is listed in the 1286 Node element of this class. 1288 True. Source of incident was identified. 1290 False. Source of incident was not identified. 1292 Node 1294 Zero or many. The Node class is used to identify a system 1295 identified as part of an incident. If this element is used, 1296 the Address element of the Node element MUST contain the IP 1297 address of the system. If the NodeName element of the Node 1298 class is used, it contains a DNS domain name that has been 1299 checked to ensure that it resolved to that IP address when the 1300 check was performed. See Section 11 of this document for 1301 internationalization considerations for NodeName. The base 1302 definition of this class from the IODEF [RFC5070] can be 1303 expanded to include other identifiers, Section 3.16. 1305 The IncidentSource class has one attribute: 1307 restriction 1309 OPTIONAL. ENUM. This attribute indicates the disclosure 1310 guidelines to which the sender expects the recipient to adhere. 1311 This guideline provides no real security since it is the choice 1312 of the recipient of the document to honor it. This attribute 1313 follows the same guidelines as "restriction" used in IODEF. 1315 5.4. RID Name Spaces 1317 The RID schema declares a namespace of 1318 "urn:ietf:params:xml:ns:iodef-rid-2.0" and registers it per 1319 [RFC3688]. Each IODEF-RID document MUST use the "iodef-rid-2.0" 1320 namespace in the top-level element RID-Document. It can be 1321 referenced as follows: 1323 1328 5.5. Encoding 1330 RID documents MUST begin with an XML declaration, MUST specify the 1331 XML version used, and the use of UTF-8 encoding is REQUIRED [RFC3470] 1332 Section 4.4. RID conforms to all XML data encoding conventions and 1333 constraints. 1335 The XML declaration with no character encoding will read as follows: 1337 1339 The following characters have special meaning in XML and MUST be 1340 escaped with their entity reference equivalent: "&", "<", ">", "\"" 1341 (double quotation mark), and "'" (apostrophe). These entity 1342 references are "&", "<", ">", """, and "'" 1343 respectively. 1345 5.6. Including IODEF or other XML Documents 1347 In order to support the changing activity of CSIRTS, the RID schema 1348 can include an IODEF or other data model. The IODEF is also 1349 extensible, enabling the schemas to evolve along with the needs of 1350 CSIRTs. This section discusses how to include the IODEF XML document 1351 or other XML documents to leverage the security and trust 1352 relationships established through the use of RID. These techniques 1353 are designed so that adding new data will not require a change to the 1354 RID schema. This approach also supports the exchange of private XML 1355 documents relevant only to a closed consortium. XML documents can be 1356 included through the ReportSchema class in the RIDPolicy class. The 1357 XMLDocument attribute is set to XML to allow for the inclusion of 1358 full IODEF or other XML documents. The following guidelines MUST be 1359 followed: 1361 1. The included schema MUST define a separate namespace, such as the 1362 declared namespace for IODEF of 1363 "urn:ietf:params:xml:ns:iodef-1.0". 1365 2. When a parser encounters an included XML document it does not 1366 understand, it MUST be ignored (and not processed), but the 1367 remainder of the document MUST be processed. Parsers will be 1368 able to identify the XML documents for which they have no 1369 processing logic through the namespace declaration. Parsers that 1370 encounter an unrecognized element in a namespace that they do 1371 support SHOULD reject the document as a syntax error. 1373 3. Implementations SHOULD NOT download schemas at runtime due to the 1374 security implications, and included documents MUST NOT be 1375 required to provide a resolvable location of their schema. 1377 The examples included in Section 7 demonstrate how an IODEF document 1378 is included. The included schema, of IODEF is represented in 1379 ReportSchema as follows: 1381 Version: "1.0" 1383 XMLSchemaID: "urn:ietf:params:xml:ns:iodef-1.0" 1385 URL: "http://www.iana.org/assignments/xml-registry/schema/ 1386 iodef-1.0.xsd" 1388 The URL is optionally included for IODEF since it is already in the 1389 RID schema and the schemaLocation is defined. 1391 5.6.1. Including XML Documents in RID 1393 The Common Vulnerability Reporting Format (CVRF) is an additional 1394 schema registered for inclusion in a RID message. The registered 1395 IANA information for additional schemas MUST include the 1396 specification name, version, specification Uniform Resource 1397 Identifier (URI), and namespace. The following provides an example 1398 of the necessary information for additional schemas beyond IODEF and 1399 CVRF. 1401 Common Vulnerability Reporting Format (CVRF) 1403 Schema Name: CVRF_1.0 1404 Version: 1.0 1405 Namespace: http://www.icasi.org/CVRF/schema/cvrf/1.0 1406 Specification URI: http://www.icasi.org/cvrf 1408 The version attribute of the ReportSchema class is populated with the 1409 approved versions of IODEF, CVRF, and any additional schemas 1410 registered by IANA, see Section 11. 1412 The XMLSchemaID of the ReportSchema class is populated with the 1413 namespace of the included schema. The attribute enumeration values 1414 include the namespace for IODEF and CVRF and any schema registered by 1415 IANA, see Section 11. 1417 The URL element of the ReportSchema class is populated with the 1418 Specification URI value of the included schema. 1420 6. RID Messages 1422 The IODEF model is followed as specified in [RFC5070] for each of the 1423 RID message types. The RID schema is used in combination with IODEF 1424 documents to facilitate RID communications. Each message type varies 1425 slightly in format and purpose; hence, the requirements vary and are 1426 specified for each. All classes, elements, attributes, etc., that 1427 are defined in the IODEF-Document are valid in the context of a RID 1428 message; however, some listed as optional in IODEF are mandatory for 1429 RID as listed for each message type. The IODEF model MUST be fully 1430 implemented for RID messages that include IODEF payloads to ensure 1431 proper parsing of those messages. 1433 Note: The implementation of RID may automate the ability to fill in 1434 the content required for each message type from packet input, 1435 incident data, situational awareness information, or default values 1436 such as those used in the EventData class. 1438 6.1. Request 1440 Description: This message type is used to request assistance in a 1441 computer security investigation. The investigation Request may be 1442 directed to another party that can assist with forensics, continue 1443 the investigation (incident may have originated on the SP network to 1444 which the Request was sent), or even to an SP to trace the traffic 1445 from an unknown source. The Request message with MsgType set to 1446 'InvestigationRequest' may leverage the existing bilateral peer 1447 relationships in order to notify the SP closest to the source of the 1448 valid traffic that some event occurred, which may be a security- 1449 related incident. A Request message with the MsgType set to 1450 'TraceRequest' may be sent to an upstream peer to trace back through 1451 the network to locate the source of malicious traffic. The following 1452 information is REQUIRED for Request messages and is provided through: 1454 RID Information: 1456 RIDPolicy 1458 RID message type, IncidentID, and destination policy 1459 information 1461 IODEF Information: 1463 Time Stamps (DetectTime, StartTime, EndTime, ReportTime). 1465 Incident Identifier (Incident class, IncidentID). 1467 Confidence rating of security incident (Impact and Confidence 1468 class). 1470 System class is used to list both the Source and Destination. 1472 Expectation class should be used to request any specific actions 1473 to be taken close to the source. 1475 Path information of nested RID systems, beginning with the request 1476 originator used in the trace using IODEF EventData with category 1477 set to "infrastructure". 1479 Event, Record, and RecordItem classes to include example packets 1480 and other information related to the incident. Note: Event 1481 information included here requires a second instance of EventData 1482 in addition to that used to convey SP path contact information. 1484 Standards for encryption and digital signatures [RFC3275], [XMLsig], 1485 [XMLencrypt]: 1487 Digital signature from initiating CSIRT or provider system sending 1488 the RID message, passed to all systems receiving the Request using 1489 a detached XML digital signature on a RecordItem entry, placed in 1490 an instance of the Signature element. 1492 Digital signature of sending CSIRT or SP for authenticity of the 1493 RID message, from the CSIRT or provider creating this message 1494 using an enveloped XML digital signature on the IODEF document, 1495 placed in an instance of the Signature element. 1497 XML encryption as required by policy, agreements, and data 1498 markers. 1500 Security requirements include the ability to encrypt [XMLencrypt] the 1501 contents of the Request message using the public key of the 1502 destination RID system. The incident number increases whether the 1503 Request message has the MsgDst set to 'InvestigationRequest' or 1504 'TraceRequest' in order to ensure uniqueness within the system. The 1505 relaying peers also append their Autonomous System (AS) or RID system 1506 information using the NPPath element as the Request message was 1507 relayed through SPs. This enables the response (Result message) to 1508 utilize the same path and trust relationships for the return message, 1509 indicating any actions taken. The request is recorded in the state 1510 tables of both the initiating and destination SP RID systems. The 1511 destination SP is responsible for any actions taken as a result of 1512 the request in adherence to any service level agreements or policies. 1513 The SP MUST confirm that the traffic actually originated from the 1514 suspected system before taking any action and confirm the reason for 1515 the request. The request may be sent directly to a known RID system 1516 or routed by the source address of the attack using the message 1517 destination of RIDPolicy, SourceOfIncident. Note: Any intermediate 1518 parties in a TraceRequest MUST be able to view RIDPolicy information 1519 of responding message types in order to properly direct RID messages. 1521 A DDoS attack can have many sources, resulting in multiple traces to 1522 locate the sources of the attack. It may be valid to continue 1523 multiple traces for a single attack. The path information enables 1524 the administrators to determine if the exact trace had already passed 1525 through a single network. The Incident Identifier must also be used 1526 to identify multiple Requests from a single incident. If a single 1527 Request results in divergent paths of Requests, a separate instance 1528 number MUST be used under the same IncidentID. The IncidentID 1529 instance number of IODEF can be used to correlate related incident 1530 data that is part of a larger incident. 1532 6.2. Acknowledgement 1534 Description: The Acknowledgement is also used to provide a status to 1535 any message type along with a Justification if the message could not 1536 be processed for any reason. This message is sent to the initiating 1537 RID system from the next upstream provider's application or system 1538 designated for accepting RID communications to provide information on 1539 the request status in the current SP. 1541 The following information is REQUIRED for Acknowledgement messages 1542 and is provided through: 1544 RID Information: 1546 RIDPolicy 1548 RID message type, IncidentID, and destination policy 1549 information 1551 RequestStatus class: 1553 Status of Request 1555 Standards for encryption and digital signatures [RFC3275], [XMLsig], 1556 [XMLencrypt]: 1558 Digital signature of responding CSIRT or provider for authenticity 1559 of Trace Status Message, from the CSIRT or provider creating this 1560 message using an enveloped XML digital signature. 1562 XML encryption as required by policy, agreements, and data 1563 markers. 1565 A message is sent back to the initiating CSIRT or provider's system 1566 accepting RID communications of the trace as status notification. 1567 This message verifies that the next RID system in the path has 1568 received the message from the previous system in the path. This 1569 message also verifies that the trace is now continuing, has stopped, 1570 or is pending in the next upstream CSIRT or provider's RID system. 1571 The Pending status is automatically generated after a 2-minute 1572 timeout without system-predefined or administrator action taken to 1573 approve or disapprove the trace continuance. If a Request is denied, 1574 the originator and sending peer (if they are not the same) MUST both 1575 receive the message. This enables the sending peer the option to 1576 take action to stop or mitigate the traffic as close to the source as 1577 possible. 1579 6.3. Result 1581 Description: This message indicates that the trace or investigation 1582 has been completed and provides the result. The Result message 1583 includes information on whether or not a source was found and the 1584 source information is provided through the IncidentSource class. The 1585 Result information MUST go back to the originating RID system that 1586 began the investigation or trace. An provider may use any number of 1587 incident handling data sources to ascertain the true source of an 1588 attack. All of the possible information sources may or may not be 1589 readily tied into the RID communications system. 1591 The following information is REQUIRED for Result messages and will be 1592 provided through: 1594 RID Information: 1596 RIDPolicy 1598 RID message type, IncidentID, and destination policy 1599 information 1601 Incident Source 1603 The IncidentSource class of the RID schema is used to note 1604 if a source was identified and provide the source 1605 address(es) or other Node information. 1607 IODEF Information: 1609 Time Stamps (DetectTime, StartTime, EndTime, ReportTime). 1611 Incident Identifier (Incident class, IncidentID). 1613 Trace number - used for multiple traces of a single 1614 incident; MUST be included if the response is specific to an 1615 instance of an incident. 1617 Confidence rating of security incident (Impact and Confidence 1618 class). 1620 System class is used to list both the Source and Destination 1621 Information used in the attack and must note if the traffic is 1622 spoofed, thus requiring an upstream Request set to 1623 'TraceRequest' in RID. 1625 History class "atype" attribute is used to note any actions 1626 taken. 1628 History class also notes any other background information 1629 including notes about the confidence level or rating of the 1630 result information. 1632 Path information of nested RID systems, beginning with the 1633 request originator used in the trace using IODEF EventData with 1634 category set to "infrastructure". The last SP listed is the SP 1635 that located the source of the traffic (the provider sending 1636 the Result message). 1638 Event, Record, and RecordItem classes to include example 1639 packets and other information related to the incident 1640 (optional). Note: Event information included here requires a 1641 second instance of EventData in addition to that used to convey 1642 SP path contact information. 1644 Standards for encryption and digital signatures [RFC3275], 1645 [XMLsig], [XMLencrypt]: 1647 Digital signature of source CSIRT or provider for authenticity 1648 of Result message, from the CSIRT or provider creating this 1649 message using an enveloped XML digital signature. 1651 XML encryption as required by policy, agreements, and data 1652 markers. 1654 A message is sent back to the initiating CSIRT or provider's RID 1655 system to notify the CSIRT that the source has been located. The 1656 actual source information may or may not be included, depending on 1657 the policy of the network in which the client or host is attached. 1658 Any action taken by the SP to act upon the discovery of the source of 1659 a trace should be included. The SP may be able to automate the 1660 adjustment of filters at their border router to block outbound access 1661 for the machine(s) discovered as a part of the attack. The filters 1662 may be comprehensive enough to block all Internet access until the 1663 host has taken the appropriate action to resolve any security issues 1664 or to rate-limit the ingress traffic as close to the source as 1665 possible. 1667 Security and privacy requirements discussed in Section 9 MUST be 1668 taken into account. 1670 Note: The History class has been expanded in IODEF to accommodate all 1671 of the possible actions taken as a result of a RID Request using the 1672 "iodef:atype", or action type, attribute. The History class should 1673 be used to note all actions taken close to the source of a trace or 1674 incident using the most appropriate option for the type of action 1675 along with a description. The "atype" attribute in the Expectation 1676 class can also be used to request an appropriate action when a 1677 Request is made. 1679 6.4. Report 1681 Description: This message or document is sent to a RID system to 1682 provide a report of a security incident. This message does not 1683 require any actions to be taken, except to file the report on the 1684 receiving RID system or associated database. 1686 The following information is REQUIRED for Report messages and will be 1687 provided through: 1689 RID Information: 1691 RID Policy RID message type, IncidentID, and destination policy 1692 information 1694 The following data is RECOMMENDED if available and can be provided 1695 through: 1697 IODEF Information: 1699 Time Stamps (DetectTime, StartTime, EndTime, ReportTime). 1701 Incident Identifier (Incident class, IncidentID). Trace number 1702 - used for multiple traces of a single incident; MUST be 1703 included if the Report is specific to an instance of an 1704 incident. 1706 Confidence rating of security incident (Impact and Confidence 1707 class). 1709 System class is used to list both the Source and Destination 1710 Information used in the attack. 1712 Event, Record, and RecordItem classes to include example 1713 packets and other information related to the incident 1714 (optional). 1716 Standards for encryption and digital signatures [RFC3275], 1717 [XMLsig], [XMLencrypt]: 1719 Digital signature from initiating RID system, passed to all 1720 systems receiving the report using an enveloped XML digital 1721 signature, placed in an instance of the Signature element. 1723 XML encryption as required by policy, agreements, and data 1724 markers. 1726 Security requirements include the ability to encrypt [XMLencrypt] the 1727 contents of the Report message using the public key of the 1728 destination RID system. Senders of a Report message should note that 1729 the information may be used to correlate security incident 1730 information for the purpose of trending, pattern detection, etc., and 1731 may be shared with other parties unless otherwise agreed upon with 1732 the receiving RID system. Therefore, sending parties of a Report 1733 message may obfuscate or remove destination addresses or other 1734 sensitive information before sending a Report message. A Report 1735 message may be sent either to file an incident report or in response 1736 to a Query, and data sensitivity must be considered in both cases. 1737 The SP path information is not necessary for this message, as it will 1738 be communicated directly between two trusted RID systems. 1740 6.5. Query 1742 Description: The Query message is used to request incident 1743 information from a trusted RID system. The request can include the 1744 incident number, if known, or detailed information about the 1745 incident. If the incident number is known, the Report message 1746 containing the incident information can easily be returned to the 1747 trusted requestor using automated methods. If an example packet or 1748 other unique information is included in the Query, the return report 1749 may be automated; otherwise, analyst intervention may be required. 1751 The following information is REQUIRED for a Query message and is 1752 provided through: 1754 RID Information: 1756 RID Policy 1758 RID message type, IncidentID, and destination policy 1759 information 1761 IODEF Information (optional): 1763 Time Stamps (DetectTime, StartTime, EndTime, ReportTime). 1765 Incident Identifier (Incident class, IncidentID). 1767 Trace number - used for multiple traces of a single 1768 incident; MUST be included if the Query is an instance of an 1769 incident. 1771 Confidence rating of security incident (Impact and Confidence 1772 class). 1774 System class is used to list both the Source and Destination 1775 Information used in the attack. 1777 Event, Record, and RecordItem classes to include example 1778 packets and other information related to the incident 1779 (optional). 1781 Standards for encryption and digital signatures [RFC3275], 1782 [XMLsig], [XMLencrypt]: 1784 Digital signature from the CSIRT or SP initiating the RID 1785 message, passed to all systems receiving the Query using an 1786 enveloped XML digital signature, placed in an instance of the 1787 Signature element. 1789 XML encryption as required by policy, agreements, and data 1790 markers. 1792 The proper response to the Query message is a Report message. 1793 Multiple incidents may be returned for a single query if an incident 1794 type is requested. In this case, the receiving system sends an IODEF 1795 document containing multiple incidents or all instances of an 1796 incident. The system sending the reply may pre-set a limit to the 1797 number of documents returned in one report. The recommended limit is 1798 5, to prevent the documents from becoming too large. Other transfer 1799 methods may be better suited than RID for large transfers of data. 1800 The Confidence rating may be used in the Query message to select only 1801 incidents with an equal or higher Confidence rating than what is 1802 specified. This may be used for cases when information is gathered 1803 on a type of incident but not on specifics about a single incident. 1804 Source and Destination Information may not be needed if the Query is 1805 intended to gather data about a specific type of incident. 1807 7. RID Communication Exchanges 1809 The following section outlines the communication flows for RID and 1810 also provides examples of messages. 1812 The possible set of message exchanges include: 1814 o Request: Asynchronous Request for assistance and/or action to be 1815 taken, MAY involve multiple systems and iterative Requests 1816 MsgType set to InvestigationRequest or TraceRequest 1818 Possible responses: 1820 + Acknowledgement (OPTIONAL for InvestigationRequest) 1822 + Result (REQUIRED unless Acknowledgement was set to no) 1824 + Report (OPTIONAL, zero or more: Report can be sent 1825 unsolicited) 1827 o Query: Synchronous request for information 1829 MsgType set to Query 1831 Possible responses: 1833 + Acknowledgement (OPTIONAL if yes, required if no Report will 1834 be sent) 1836 + Report (REQUIRED unless Acknowledgement was set to no) 1838 o Report: Asynchronous information report, may be pushed to systems 1839 or a response from a Query 1841 MsgType set to Report 1843 Possible responses: 1845 + Acknowledgement (OPTIONAL) 1847 Processing considerations for the IODEF document and any IODEF 1848 included elements or attributes MUST follow the guidelines specified 1849 in [RFC5070] Section 4. [RFC3023] and [RFC3470] specify requirements 1850 and best practices for the use of XML in IETF application protocols. 1851 RID and IODEF documents MUST be well-formed [RFC3470], see Section 1852 4.1, and MUST be validated against the appropriate schema. Internal 1853 or external DTD subsets are prohibited in RID, see [RFC3023] Section 1854 3. 1856 Comments can be ignored by conform ant processors for RID or IODEF 1857 documents [RFC3470], see Section 4.6, and are included below for 1858 informational purposes only. The first example demonstrates the use 1859 of a detached digital signature. Subsequent examples do not include 1860 the detached signature required for some message types. The 1861 signature is applied after the message is created as demonstrated in 1862 the first example. 1864 Note: For each example listed below, [RFC5735] addresses were used. 1865 Assume that each IP address listed is actually a separate network 1866 range held by different SPs. Addresses were used from /27 network 1867 ranges. 1869 7.1. Upstream Trace Communication Flow 1871 The diagram below outlines the RID Request communication flow for a 1872 TraceRequest between RID systems on different networks tracing an 1873 attack. The Request message with MsgDst set to 'TraceRequest' is 1874 represented in the diagram by TraceRequest. SP-1, SP-2, SP-3 1875 represent service providers that are involved in the example trace 1876 communication flow. 1878 Attack Dest SP-1 SP-2 SP-3 Attack Src 1880 1. Attack | Attack 1881 reported | detected 1883 2. Initiate trace 1885 3. Locate origin 1886 through 1887 upstream SP 1889 4. o---TraceRequest-----> 1891 5. Trace 1892 Initiated 1894 6. <---Acknowledgement--o 1896 7. Locate origin 1897 through 1898 upstream SP 1900 8. o---TraceRequest---> 1902 9. Trace Initiated 1904 10. <----------Acknowledgement----o 1905 <-Acknowledgement-o 1907 11. Locate attack 1908 source on network X 1910 12. <------------Result----------------o 1912 13. o- - - - -Acknowledgement- - - - - > 1914 Figure 8: TraceRequest Communication Flow 1916 Before a trace is initiated, the RID system should verify if an 1917 instance of the trace or a similar request is not active. The traces 1918 may be resource intensive; therefore, providers need to be able to 1919 detect potential abuse of the system or unintentional resource 1920 drains. Information such as the Source and Destination Information, 1921 associated packets, and the incident may be desirable to maintain for 1922 a period of time determined by administrators. 1924 The communication flow demonstrates that an Acknowledgement message 1925 is sent to both the downstream peer and the original requestor. If a 1926 Request in a traceback is denied, the downstream peer has the option 1927 to take an action and respond with a Result message. The originator 1928 of the request may follow up with the downstream peer of the SP 1929 involved using a Request with the MsgType set to 1930 'InvestigationRequest' to ensure that an action is taken if no 1931 response is received. Nothing precludes the originator of the 1932 request from initiating a new Request with the MsgType set to 1933 'TraceRequest' bypassing the SP that denied the request, if a trace 1934 is needed beyond that point. Another option may be for the initiator 1935 to send an 'InvestigationRequest' to an SP upstream of the SP that 1936 denied the request. This action assumes enough information was 1937 gathered to discern the true source of the attack traffic from the 1938 incident handling information. 1940 The proper response to a TraceRequest is an Acknowledgement message. 1941 The Acknowledgement message lets the requestor know if the trace will 1942 continue through the next upstream network. If there is a problem 1943 with the request, such as a failure to validate the digital signature 1944 or decrypt the request, an Acknowledgement message MUST be sent to 1945 the requestor and the downstream peer (if they are not one and the 1946 same) providing the reason why the message could not be processed. 1947 Assuming that the trace continued, additional TraceRequests with the 1948 response of an Acknowledgement message would occur passing the 1949 request upstream in the path to the source of the traffic related to 1950 the incident. Once a source is found, a Result message is sent to 1951 the originator of the trace, as determined by the SP path information 1952 provided through the document instance of EventData, where contact is 1953 set to "infrastructure". The SP path information is also used when 1954 sending the Acknowledgement messages to the first entry (the trace 1955 originator) and the last nested entry (the downstream peer). The 1956 Result message is encrypted [XMLencrypt] for the originator providing 1957 information about the incident source and any actions taken. If the 1958 originator fails to decrypt or authenticate the Result message, an 1959 Acknowledgement message is sent in response; otherwise, no return 1960 message is sent. The final Acknowledgement to the Result message is 1961 depicted as optional in the diagram above. If an Acknowledgement 1962 message is sent with the RequestStatus set to Denied, a downstream 1963 peer receiving this message may choose to take action to stop or 1964 mitigate the traffic at that point in the network, as close to the 1965 source as possible. If the downstream peer chooses this option, it 1966 would send a Result message to the trace originator. 1968 7.1.1. RID TraceRequest Example 1970 The example listed is of a Request message with MsgDst set to 1971 'TraceRequest' based on the incident report example from the IODEF 1972 document. The RID classes were included as appropriate for a Request 1973 message of this type using the RIDPolicy class. The example given is 1974 that of a CSIRT reporting a DoS attack in progress to the upstream 1975 SP. The request asks the next SP to continue the trace and have the 1976 traffic mitigated closer to the source of the traffic. The example 1977 Request message is the first step of a TraceRequest as depicted in 1978 the previous diagram, where 'Attack Dest' is represented by 1979 192.0.2.67 (and SP-1). The "Attack Src' is later identified in the 1980 Result message example as 192.0.2.37 and initially as tracing closer 1981 to 192.0.2.35. 'SP-1' is identified in the Request as CSIRT-FOR-OUR- 1982 DOMAIN, and 'SP-2' is identified in the RID document for the Request 1983 as the 'RIDSystem' in 'MsgDestination' as 192.0.2.3 using the Node 1984 class. SP-3 is later used in the Result message and the 1985 administrator is identified as 'Admin-contact@10.1.1.2' as they 1986 searched for 192.0.2.35, the administrator may be different than the 1987 constituency contact (an additional Request with MsgDst set to 1988 'TraceRequest' occurred between SP-2 to SP-3 that is not included). 1989 SP-3 is the service provider for 192.0.2.32/27 and was able to take 1990 the action to rate-limit their traffic. The SP-1, SP-2, and SP-3 1991 information would be replaced with the appropriate (and valid) email 1992 and other contact information in real usages. The Node class enables 1993 multiple methods to identify a system, such as a fully qualified 1994 domain or the IP address to be provided for the SP. Any mapping of 1995 existing relationships from the SP Node information to the name, 1996 contact, digital signature verification information and other 1997 identifying or trust information is provided at the application layer 1998 to support end users of the incident management system. A packet is 1999 provided in this example to enable any traces to be performed by SP-2 2000 and SP-3 to perform traces to the attack source before taking the 2001 requested action to 'rate-limit' the traffic. The subnet of 2002 192.0.2.0uses a 27 bit mask in the examples below. 2004 In the following example, use of [XMLsig] to generate digital 2005 signatures follows the guidance of [XMLsig] 1.0. Version 1.1 of 2006 [XMLsig] supports additional digest algorithms. Reference [RFC4051] 2007 for URIs intended for use with XML digital signatures, encryption, 2008 and canonicalization. SHA-1 SHOULD NOT be used, see [RFC6194] for 2009 further details. 2011 2012 2017 2018 2019 2020 192.0.2.3 2021 2022 2023 2024 CERT-FOR-OUR-DOMAIN#207-1 2025 2026 2027 2028 2029 2030 2031 2032 CERT-FOR-OUR-DOMAIN#207-1 2033 2034 2004-02-02T22:49:24+00:00 2035 2004-02-02T22:19:24+00:00 2036 2004-02-02T23:20:24+00:00 2037 Host involved in DoS attack 2038 2039 2040 2041 2042 Constituency-contact for 192.0.2.35 2043 2044 Constituency-contact@192.0.2.35 2045 2046 2047 2048 2049 2050 192.0.2.35 2051 2052 2053 2054 38765 2055 2056 2057 2058 2059 192.0.2.67 2060 2061 2062 2063 80 2064 2065 2066 2067 2068 2069 Rate-limit traffic close to source 2071 2072 2073 2074 2075 2076 The IPv4 packet included was used in the described attack 2077 2078 450000522ad9 2079 0000ff06c41fc0a801020a010102976d0050103e020810d9 2080 4a1350021000ad6700005468616e6b20796f7520666f7220 2081 6361726566756c6c792072656164696e6720746869732052 2082 46432e0a 2083 2084 2085 2086 2087 2088 2089 2001-09-14T08:19:01+00:00 2090 2091 CSIRT-FOR-OUR-DOMAIN#207-1 2092 2093 2094 Notification sent to next upstream SP closer to 192.0.2.35 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2116 //dsig:Signature[@Id = 'dsig-123456']/ancestor::iodef-rid:ReportSchema/ 2117 iodef-rid:XMLDocument/IODEF-Document[1]/iodef:Incident[1]/ 2118 iodef:EventData[1]/iodef:Record[1]/iodef:RecordData[1]/ 2119 iodef:RecordItem[1] 2120 2121 NQuIhPjdZuZJnPi/hW62dwJT1dR+vqcZV8mpemCVN5g= 2122 2123 2124 lnq/ePQ4AVpxCR0ifCp9sMsW0r/AdT3C2GR/zaN1V+hZ/NApOygUjMzTCQnx+RvGPNkO/RVqBEID 2125 gZQUEnQZn/uSbmr0tQ6xpBfaxF1DCosLgiZy+2jFzpXrwoN/jHNgtxR/9QLW9mZ+I7V6LEEJ73Ku 2126 t+d0naTGHlyi64ab2PqsVuRXQ4pXUKbhMkhzeTIqvFLK93KGfsIMd6Cb+n2u/AByLkc+gflJYUWV 2127 P4DxkQ4cyex6hM6RYTRUSr7jVD9K4d8KFP2g85i69YLtSu01W1Np0afpJ4a9MK0E7ISMNRmC8wIk 2128 lCAsSXiBRqyaEwaSy/clybI0vCTPqGOYh3/SZg== 2129 2130 2131 2132 2133 z8adrX9m0S8OxIxN+fui33wiz4ZYgb4xPbR9MS5pOp1A8kVpH5Ew3N6O3/dMs2a4diIxyGLVh0r8 2134 6QXWH/W6T2IC2ny+hi+jWRwXrvgTY3ZAFgePvz2OdRhVN/cUbOto4Pa4I2mVZWW+/Q0Fn7YpqPBD 2135 DxlGq/xyFPuYq/4y7Y+Ah+vHO2ZSaiQjbj8F38XrGhwlcbFVyK8AmxK3z0zWwX86uMEqVCjW6s6j 2136 2KAWdbAjEpgZHlJY87i/DqnFgxfmdg3oru+YeiEPVRY8hyQpYbtgryveZOHTgnCHmS/53U9jSS0c 2137 yb/ADuj1upfyNoOiMMgQr7Olhc5pTvuWAl4Fnw== 2138 AQAB 2139 2140 2141 2142 2143 2144 2145 2146 2147 2149 7.1.2. Acknowledgement Message Example 2151 The example Acknowledgement message is in response to the Request 2152 message listed above. The SP that received the request is responding 2153 to approve the trace continuance in their network. 2155 2158 2160 2161 2162 192.0.2.67 2163 2164 2165 2166 CERT-FOR-OUR-DOMAIN#207-1 2167 2168 2169 2170 2172 7.1.3. Result Message Example 2174 The example Result message is in response to the Request listed 2175 above. This message type only comes after an Acknowledgement within 2176 the Request flow of messages where a TraceRequest is in progress. It 2177 may be a direct response to a Request with the MsgType set to 2178 'InvestigationRequest'. This message provides information about the 2179 source of the attack and the actions taken to mitigate the traffic. 2180 The Result message is typically the last message in a Request flow, 2181 however an Acknowledgement MAY follow if there are any issues 2182 receiving or processing the Result. 2184 2187 2189 2190 2191 192.0.2.67 2192 2193 2194 2195 CERT-FOR-OUR-DOMAIN#207-1 2196 2197 2198 2199 2200 2201 2202 2203 CERT-FOR-OUR-DOMAIN#207-1 2204 2205 2004-02-02T22:49:24+00:00 2206 2004-02-02T22:19:24+00:00 2207 2004-02-02T23:20:24+00:00 2208 Host involved in DoS attack 2209 2210 2211 2212 2213 Constituency-contact for 192.0.2.35 2214 2215 Constituency-contact@192.0.2.35 2216 2217 2218 2219 Admin-contact for 192.0.2.35 2220 2221 Admin-contact@10.1.1.2 2222 2223 2224 2225 2226 192.0.2.35 2227 2228 2229 2230 2231 2232 2233 Admin-contact for 192.0.2.3 2234 2235 Admin-contact@192.0.2.3 2236 2237 2238 2239 2240 192.0.2.3 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2251 192.0.2.35 2252 2253 2254 2255 38765 2256 2257 2258 2259 2260 192.0.2.67 2261 2262 2263 2264 80 2265 2266 2267 2268 2269 2270 Rate-limit traffic close to source 2271 2272 2273 2274 2275 2276 The IPv4 packet included was used in the described attack 2277 2278 450000522ad9 2279 0000ff06c41fc0a801020a010102976d0050103e020810d9 2280 4a1350021000ad6700005468616e6b20796f7520666f7220 2281 6361726566756c6c792072656164696e6720746869732052 2282 46432e0a 2283 2284 2285 2286 2287 2288 2289 2004-02-02T22:53:01+00:00 2290 2291 CSIRT-FOR-OUR-DOMAIN#207-1 2292 2293 2294 Notification sent to next upstream SP closer to 192.0.2.35 2295 2296 2297 2298 2004-02-02T23:07:21+00:00 2299 2300 CSIRT-FOR-SP3#3291-1 2301 2302 2303 Host rate-limited for 24 hours 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 true 2315 2316 192.0.2.37 2317 2318 2319 2321 7.2. Investigation Request Communication Flow 2323 The diagram below outlines a RID Request communication flow between 2324 RID systems on different networks for a security incident with a 2325 known source address. Therefore, MsgDst is set to 2326 'InvestigationRequest' for the Request message and is included in the 2327 diagram below as an Investigation. The proper response to a Request 2328 with the MsgDst set to 'InvestigationRequest' is a Result message. 2329 If there is a problem with the Request, such as a failure to validate 2330 the digital signature or decrypt the Request, an Acknowledgement 2331 message is sent to the requestor. The Acknowledgement message should 2332 provide the reason why the message could not be processed. 2334 Attack Dest SP-1 SP-2 Attack Src 2336 1. Attack | Attack 2337 reported | detected 2339 2. Determine source 2340 of security incident 2342 3. o---Investigation----> 2344 4. Research 2345 incident and 2346 determine appropriate 2347 actions to take 2349 5. <-------Result-------o 2351 Figure 9: Investigation Request Communication Flow 2353 7.2.1. Investigation Request Example 2355 The following example only includes the RID-specific details. The 2356 IODEF and security measures are similar to the TraceRequest, with the 2357 exception that the source is known, the receiving RID system is known 2358 to be close to the source, and the MsgDst is set to 2359 'InvestigationRequest'. The source known is indicated in the IODEF 2360 document, which allows for incident sources to be listed as spoofed, 2361 if appropriate. 2363 This flow does not include a Result message as the request is denied 2364 as shown in the Acknowledgement response. 2366 SP-1 is represented by CERT-FOR-OUR-DOMAIN and 192.0.2.67. SP-2 is 2367 identified by 192,0.2.98. In this example SP-2 is the service 2368 provider for systems on the 192.0.2.32/27 subnet. The contact for 2369 the host 192.0.2.35 is known at the start of the request as 2370 'Constituency-contact@10.1.1.2'. 2372 2375 2377 2378 2379 192.0.2.98 2380 2381 2382 2383 CERT-FOR-OUR-DOMAIN#208-1 2384 2385 2386 2387 2388 2389 2390 2391 CERT-FOR-OUR-DOMAIN#208-1 2392 2393 2004-02-05T08:13:33+00:00 2394 2004-02-05T08:13:31+00:00 2395 2004-02-05T08:13:33+00:00 2396 2004-02-05T08:13:35+00:00 2397 Host involved in DoS attack 2398 2399 2400 2401 2402 Constituency-contact for 192.0.2.35 2403 2404 Constituency-contact@10.1.1.2 2405 2406 2407 2408 2409 2410 192.0.2.35 2411 2412 2413 2414 41421 2415 2416 2417 2418 2419 192.0.2.67 2420 2421 2422 2423 80 2424 2425 2426 2427 2428 2429 Investigate whether source has been compromised 2430 2431 2432 2433 2434 2435 2004-02-05T08:19:01+00:00 2436 2437 CSIRT-FOR-OUR-DOMAIN#208-1 2438 2439 2440 Investigation request sent to SP for 192.0.2.35 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2452 7.2.2. Acknowledgement Message Example 2454 The example Acknowledgement message is in response to the Request 2455 listed above. The SP that received the request was unable to 2456 validate the digital signature used to authenticate the sending RID 2457 system. 2459 2462 2464 2465 2466 192.0.2.67 2467 2468 2469 2470 CERT-FOR-OUR-DOMAIN#208-1 2471 2472 2473 2475 2477 7.3. Report Communication Flow 2479 The diagram below outlines the RID Report communication flow between 2480 RID systems on different SPs. 2482 SP-1 SP-2 2484 1. Generate incident information 2485 and prepare Report message 2487 2. o-------Report-------> 2489 3. File report in database 2491 Figure 10: Report Communication Flow 2493 The Report communication flow is used to provide information on 2494 incidents. Incident information may be shared between CSIRTs or 2495 other entities using this format. When a report is received, the RID 2496 system must verify that the report has not already been filed. The 2497 incident number and incident data, such as the hexadecimal packet and 2498 incident class information, can be used to compare with existing 2499 database entries. The Report message typically does not have a 2500 response. If there is a problem with the Report message, such as a 2501 failure to validate the digital signature [RFC3275] or decrypt the 2502 request, an Acknowledgement message is sent to the requestor. The 2503 Acknowledgement message should provide the reason why the message 2504 could not be processed. 2506 7.3.1. Report Example 2508 The following example only includes the RID-specific details. This 2509 report is an unsolicited Report message that includes an IPv4 packet. 2510 The IODEF document and digital signature is similar to the Request 2511 example with MsgDst set to 'TraceRequest'. 2513 This example is a message sent from SP-1, CERT-FOR-OUR-DOMAIN at 2514 192.0.2.67, to SP-2 at 192.0.2.130 for informational purposes on an 2515 attack that took place. 2517 2520 2521 2522 2523 192.0.2.130 2525 2526 2527 2528 CERT-FOR-OUR-DOMAIN#209-1 2529 2530 2531 2532 2533 2534 2535 2536 CERT-FOR-OUR-DOMAIN#209-1 2537 2538 2004-02-05T10:21:08+00:00 2539 2004-02-05T10:21:05+00:00 2540 2004-02-05T10:35:00+00:00 2541 2004-02-05T10:27:38+00:00 2542 Host illicitly accessed admin account 2543 2544 2545 2547 2548 2549 2550 Constituency-contact for 192.0.2.35 2551 2552 Constituency-contact@10.1.1.2 2553 2554 2555 2556 2557 2558 192.0.2.35 2559 2560 2561 2562 32821 2563 2564 2565 2566 2567 192.0.2.67 2568 2569 2570 2571 22 2572 2574 2575 2576 2577 2578 2579 2004-02-05T10:28:00+00:00 2580 2581 CSIRT-FOR-OUR-DOMAIN#209-1 2582 2583 2584 Incident report sent to SP for 192.0.2.35 2585 2586 2587 2588 2589 2590 2591 2592 2593 2594 2596 7.4. Query Communication Flow 2598 The diagram below outlines the RID Query communication flow between 2599 RID systems on different networks. 2601 SP-1 SP-2 2603 1. Generate a request for 2604 information on a specific 2605 incident number or incident type 2607 2. o-------Query-------> 2609 3. Verify policy information 2610 and determine if matches exist 2611 for requested information 2613 4. <-------Report------o 2615 5. Associate report to request 2616 by incident number or type 2617 and file report(s). 2619 Figure 11: Query Communication Flow 2621 The Query message communication receives a response of a Report 2622 message. If the Report message is empty, the responding host did not 2623 have information available to share with the requestor. The incident 2624 number and responding RID system, as well as the transport, assist in 2625 the association of the request and response since a report can be 2626 filed and is not always solicited. If there is a problem with the 2627 Query message, such as a failure to validate the digital signature or 2628 decrypt the request, an Acknowledgement message is sent to the 2629 requestor. The Acknowledgement message should provide the reason why 2630 the message could not be processed. 2632 7.4.1. Query Example 2634 The Query request may be received in several formats as a result of 2635 the type of query being performed. If the incident number is the 2636 only information provided, the IODEF document and IP packet data may 2637 not be needed to complete the request. However, if a type of 2638 incident is requested, the incident number remains NULL, and the IP 2639 packet data will not be included in the IODEF RecordItem class; the 2640 other incident information is the main source for comparison. In the 2641 case in which an incident number may not be the same between CSIRTs, 2642 the incident number and/or IP packet information can be provided and 2643 used for comparison on the receiving RID system to generate (a) 2644 Report message(s). 2646 This query is sent to 192.0.2.3, inquiring about the incident with 2647 the identifier CERT-FOR-OUR-DOMAIN#210-1. The Report will be 2648 provided to the requestor identified and verified through the 2649 authentication and digital signature information provided in the RID 2650 message. An example Report is provided above. 2652 2655 2657 2658 2659 192.0.2.3 2660 2661 2662 2663 CERT-FOR-OUR-DOMAIN#210-1 2664 2665 2666 2668 8. RID Schema Definition 2670 2671 2677 2679 2682 2690 2692 2697 2698 XML Schema wrapper for IODEF 2699 2700 2701 2702 2703 2704 2705 2706 2707 2709 2711 2713 2714 2715 2716 2717 2718 2719 2720 2721 2722 2723 2724 2725 2726 2728 2729 2730 2731 2732 2733 2734 2735 2736 2737 2738 2739 2740 2741 2742 2743 2745 2746 2748 2750 2751 2752 2753 2754 2756 2757 2758 2759 2761 2766 2767 RID Policy used for transport of 2768 messages 2769 2771 2774 2775 2776 2777 2778 2779 2780 2781 2782 2783 2784 2785 2786 2787 2788 2789 2790 2791 2792 2793 2794 2795 2796 2797 2798 2799 2800 2801 2802 2803 2804 2805 2806 2807 2808 2810 2811 2813 2814 2815 2816 2817 2818 2819 2820 2821 2822 2823 2824 2825 2826 2827 2828 2830 2831 2832 2833 2834 2835 2836 2837 2838 2839 2840 2841 2842 2843 2844 2845 2846 2847 2848 2850 2851 2852 2853 2854 2855 2856 2858 2860 2862 2863 2864 2865 2866 2867 2868 2869 2870 2871 2872 2874 2875 2876 2877 2878 2879 2880 2881 2882 2883 2884 2886 2887 2889 2891 2893 2895 9. Security Requirements 2897 9.1. XML Digital Signatures and Encryption 2899 RID leverages existing security standards and data markings in 2900 RIDPolicy to achieve the required levels of security for the exchange 2901 of incident information. The use of standards include TLS and the 2902 XML security features of encryption [XMLencrypt] and digital 2903 signatures [RFC3275], [XMLsig]. The standards provide clear methods 2904 to ensure that messages are secure, authenticated, authorized, that 2905 the messages meet policy and privacy guidelines, and maintain 2906 integrity. XML Signature Best Practices [XMLSigBP] should be 2907 referenced by implementers for information on improving security to 2908 mitigate attacks. 2910 As specified in the relevant sections of this document, the XML 2911 digital signature [RFC3275] and XML encryption [XMLencrypt] are used 2912 in the following cases: 2914 XML Digital Signature 2916 o The originator of a Request MUST use a detached signature to sign 2917 at least one of the original elements contained in the RecordItem 2918 class to provide authentication to all upstream participants in 2919 the trace or those involved in the investigation. All instances 2920 of RecordItem provided by the originator may be individually 2921 signed, and additional RecordItem entries by upstream peers in the 2922 trace or investigation may be signed by the peer adding the data, 2923 while maintaining the original RecordItem entry(s) and detached 2924 signature(s) from the original requestor. It is important to note 2925 that the data is signed at the RecordItem level. Since multiple 2926 RecordItems may exist within an IODEF document and may originate 2927 from different sources, the signature is applied at the RecordItem 2928 level to enable the use of an XML detached signature. Exclusive 2929 canonicalization [XMLCanon] is REQUIRED for the detached signature 2930 and not the references as the XML document generated is then 2931 included in the RID message within the Signature element of the 2932 ReportSchema class. This signature MUST be passed to all 2933 recipients of the Request message. 2935 o If a Request does not include a RecordItem entry, a timestamp MUST 2936 be used to ensure there is data to be signed for the multi-hop 2937 authentication use case. The DateTime element of the IODEF: 2938 RecordItem class, [RFC5070] Section3.19.1, is used for this 2939 purpose. 2941 o For all message types, the full IODEF/RID document MUST be signed 2942 using an enveloped signature by the sending peer to provide 2943 authentication and integrity to the receiving RID system. The 2944 signature is placed in an instance of the Signature element. 2946 o XML Signature Best Practices [XMLSigBP] guidance SHOULD be 2947 followed to prevent or mitigate security risks. Examples include 2948 the recommendation to authenticate a signature prior to processing 2949 (executing potentially dangerous operations) and limiting the use 2950 of URIs since they may enable cross-site scripting attacks or 2951 access to local information. 2953 o XML Path Language (XPath) 2.0 [XMLPath] MUST be followed to 2954 specify the portion of the XML document to be signed. XPath is 2955 used to specify a location within an XML document. Best practice 2956 recommendations for using XPath [XMLSigBP] SHOULD be referenced to 2957 reduce the risk of denial of service attacks. The use of XSLT 2958 transforms MUST be restricted according to security guidance in 2959 [XMLSigBP]. 2961 XML Encryption 2963 o The IODEF/RID document MAY be encrypted to provide an extra layer 2964 of security between peers so that the message is not only 2965 encrypted for transport. This behavior would be agreed upon 2966 between peers or a consortium, or determined on a per-message 2967 basis, depending on security requirements. It should be noted 2968 that there are cases for transport where the RIDPolicy class needs 2969 to be presented in clear text, as detailed in the transport 2970 document [RFC6046-bis]. 2972 o A Request, or any other message type that may be relayed through 2973 RID systems before reaching the intended destination as a result 2974 of trust relationships, MAY be encrypted specifically for the 2975 intended recipient. This may be necessary if the RID network is 2976 being used for message transfer, the intermediate parties do not 2977 need to have knowledge of the request contents, and a direct 2978 communication path does not exist. In that case, the RIDPolicy 2979 class is used by intermediate parties and as such, RIDPolicy is 2980 maintained in clear text. 2982 o The action taken in the Result message may be encrypted using the 2983 key of the request originator. In that case, the intermediate 2984 parties can view the RIDPolicy information and know the trace has 2985 been completed and do not need to see the action. If the use of 2986 encryption were limited to sections of the message, the History 2987 class information would be encrypted. Otherwise, it is 2988 RECOMMENDED to encrypt the entire IODEF/RID document and use an 2989 enveloped signature, for the originator of the request. The 2990 existence of the Result message for an incident would tell any 2991 intermediate parties used in the path of the incident 2992 investigation that the incident handling has been completed. 2994 o The iodef:restriction attribute sets expectations for the privacy 2995 of an incident and is defined in section 3.2 of RFC5070. 2996 Following the guidance for XML encryption in the Security 2997 Requirements Section, the iodef:restriction attribute can be set 2998 in any of the RID classes to define restrictions and encryption 2999 requirements for the exchange of incident information. The 3000 restriction options enable encryption capabilities for the 3001 complete exchange of an IODEF document (including any extensions), 3002 within specific classes of IODEF, or IODEF extensions where more 3003 limited restrictions are desired. The restriction attribute is 3004 contained in each of the RID classes and MUST be used in 3005 accordance with confidentiality expectations for either sections 3006 of the IODEF document or the complete IODEF document. Consortiums 3007 and organizations should consider this guidance when creating 3008 exchange policies. 3010 o Expectations based on restriction setting: 3012 * If restriction is set to "private", the class or document MUST 3013 be encrypted for the recipient using XML encryption and the 3014 public key of the recipient. See Section 9.3 for a discussion 3015 on public key infrastructure (PKI) and other security 3016 requirements. 3018 * If restriction is set to "need-to-know", the class or document 3019 MUST be encrypted to ensure only those with need-to-know access 3020 can decrypt the data. The document can either be encrypted for 3021 each individual for which access is intended or a single group 3022 key may be used. The method used SHOULD adhere to any 3023 certificate policy and practices agreements between entities 3024 for the use of RID. A group key in this instance refers to a 3025 single key (symmetric) that is used to encrypt the block of 3026 data. The users with need-to-know access privileges may be 3027 given access to the shared key via a secure distribution 3028 method, for example, providing access to the symmetric key 3029 encrypted with each of users public keys. 3031 * If restriction is set to "public", the class or document MUST 3032 be sent in clear text. This setting can be critical if certain 3033 sections of a document or an entire document are to be shared 3034 without restrictions. This provides flexibility within an 3035 incident to share out certain information freely where 3036 appropriate. 3038 * If restriction is set to "default", The information can be 3039 shared according to an information disclosure policy pre- 3040 arranged by the communicating parties. 3042 o Expectations based on placement of the restriction setting: 3044 * If restriction is set within one of the RID classes, the 3045 restriction applies to the entire IODEF document. 3047 * If restriction is set within individual IODEF classes, the 3048 restriction applies to the specific IODEF class and the 3049 children of that class. 3051 The formation of policies is a very important aspect of using a 3052 messaging system like RID to exchange potentially sensitive 3053 information. Many considerations should be involved for peering 3054 parties, and some guidelines to protect the data, systems, and 3055 transport are covered in this section. Policies established should 3056 provide guidelines for communication methods, security, and fall-back 3057 procedures. See sections 9.4 and 9.5 for additional information on 3058 consortiums and PKI considerations. 3060 The security considerations for the storage and exchange of 3061 information in RID messaging may include adherence to local, 3062 regional, or national regulations in addition to the obligations to 3063 protect client information during an investigation. RID Policy is a 3064 necessary tool for listing the requirements of messages to provide a 3065 method to categorize data elements for proper handling. Controls are 3066 also provided for the sending entity to protect messages from third 3067 parties through XML encryption. 3069 RID provides a method to exchange incident handling request and 3070 Report messages between entities. Administrators have the ability to 3071 base decisions on the available resources and other factors of their 3072 network and maintain control of incident investigations within their 3073 own network. Thus, RID provides the ability for participating 3074 networks to manage their own security controls, leveraging the 3075 information listed in RIDPolicy. 3077 RID is used to transfer or exchange XML documents in an IODEF format 3078 or using another IANA registered format. Implementations SHOULD NOT 3079 download schemas at runtime due to the security implications, and 3080 included documents MUST NOT be required to provide a resolvable 3081 location of their schema. 3083 9.2. Message Transport 3085 A transport specification is defined in a separate document [RFC6046- 3086 bis]. The specified transport protocols MUST use encryption to 3087 provide an additional level of security and integrity, while 3088 supporting mutual authentication through bi-directional certificate 3089 usage. Any subsequent transport method defined should take advantage 3090 of existing standards for ease of implementation and integration of 3091 RID systems. Session encryption for the transport of RID messages is 3092 enforced in the transport specification. The privacy and security 3093 considerations are addressed fully in RID to protect sensitive 3094 portions of documents and provide a method to authenticate the 3095 messages. Therefore, RID messages do not rely on the security 3096 provided by the transport layer alone. The encryption requirements 3097 and considerations for RID messages are discussed in Section 9.1 of 3098 this document. 3100 Consortiums may vary their selected transport mechanisms and thus 3101 decide upon a mutual protocol to use for transport when communicating 3102 with peers in a neighboring consortium using RID. RID systems MUST 3103 implement and deploy HTTPS as defined in the transport document 3104 [RFC6046-bis] and optionally support other protocols such as the 3105 Blocks Extensible Exchange Protocol (BEEP) [RFC3080]. Bindings would 3106 need to be defined to enable support for other transport protocols. 3108 Systems used to send authenticated RID messages between networks MUST 3109 use a secured system and interface to connect to a border network's 3110 RID systems. Each connection to a RID system MUST meet the security 3111 requirements agreed upon through the consortium regulations, peering, 3112 or SLAs. The RID system MUST only listen for and send RID messages 3113 on the designated port, which also MUST be over an encrypted tunnel 3114 meeting the minimum requirement of algorithms and key lengths 3115 established by the consortium, peering, or SLA. The selected 3116 cryptographic algorithms for symmetric encryption, digital 3117 signatures, and hash functions MUST meet minimum security levels of 3118 the times. The encryption strength MUST adhere to import and export 3119 regulations of the involved countries for data exchange. 3121 Out-of-band communications dedicated to SP interaction for RID 3122 messaging would provide additional security as well as guaranteed 3123 bandwidth during a denial-of-service attack. For example, an out-of- 3124 band channel may consist of logical paths defined over the existing 3125 network. Out-of-band communications may not be practical or possible 3126 between service providers, but provisions should be considered to 3127 protect the incident management systems used for RID messaging. 3128 Methods to protect the data transport may also be provided through 3129 session encryption. 3131 9.3. Public Key Infrastructure 3133 It is RECOMMENDED that RID, the XML security functions, and transport 3134 protocols properly integrate with a PKI managed by the consortium, 3135 federate PKIs within a consortium, or use a PKI managed by a trusted 3136 third party. Entities MAY use shared keys as an alternate solution, 3137 although this may limit the ability to validate certificates and 3138 could introduce risk. For the Internet, a few of examples of 3139 existing efforts that could be leveraged to provide the supporting 3140 PKI include the Regional Internet Registry's (RIR's) PKI hierarchy, 3141 vendor issued certificates, or approved issuers of Extended 3142 Validation (EV) Certificates. Security and privacy considerations 3143 related to consortiums are discussed in Sections 9.4 and 9.5. 3145 The use of PKI between entities or by a consortium SHOULD adhere to 3146 any applicable certificate policy and practices agreements for the 3147 use of RID. [RFC3647] specifies a commonly used format for 3148 certificate policy (CP) and certification practices statements (CPS). 3149 Systems with predefined relationships for RID include those who peer 3150 directly or through a consortium with agreed-upon appropriate use 3151 agreements. The agreements to trust other entities may be based on 3152 assurance levels that could be determined by a comparison of the CP, 3153 CPS, and/or RID operating procedures. The initial comparison of 3154 policies and ability to audit controls provides a baseline assurance 3155 level for entities to form and maintain trust relationships. Trust 3156 relationships may also be defined through a bridged or hierarchical 3157 PKI in which both peers belong. If shared keys or keys issued from a 3158 common CA are used, the verification of controls to determine the 3159 assurance level to trust other entities may be limited to the RID 3160 policies and operating procedures. 3162 XML security functions utilized in RID require a trust center such as 3163 a PKI for the distribution of credentials to provide the necessary 3164 level of security for this protocol. Layered transport protocols 3165 also utilize encryption and rely on a trust center. Public key 3166 certificate pairs issued by a trusted Certification Authority (CA) 3167 MAY be used to provide the necessary level of authentication and 3168 encryption for the RID protocol. The CA used for RID messaging must 3169 be trusted by all involved parties and may take advantage of similar 3170 efforts, such as the Internet2 federated PKI or the ARIN/RIR effort 3171 to provide a PKI to service providers. The PKI used for 3172 authentication also provides the necessary certificates needed for 3173 encryption used for the RID transport protocol [RFC6046-bis]. 3175 9.3.1. Authentication 3177 Hosts receiving a RID message MUST be able to verify that the sender 3178 of the request is valid and trusted. Using digital signatures on a 3179 hash of the RID message with an X.509 version 3 certificate issued by 3180 a trusted party MUST be used to authenticate the request. The X.509 3181 version 3 specifications as well as the digital signature 3182 specifications and path validation standards set forth in [RFC5280] 3183 MUST be followed in order to interoperate with a PKI designed for 3184 similar purposes. Full path validation verifies the chaining 3185 relationship to a trusted root and also performs a certificate 3186 revocation check. The use of digital signatures in RID XML messages 3187 MUST follow the World Wide Web Consortium (W3C) recommendations for 3188 signature syntax and processing when either the XML encryption 3189 [XMLencrypt] or digital signature [XMLsig], [RFC3275] is used within 3190 a document. 3192 It might be helpful to define an extension to the authentication 3193 scheme that uses attribute certificates [RFC5755] in such a way that 3194 an application could automatically determine whether human 3195 intervention is needed to authorize a request; however, the 3196 specification of such an extension is out of scope for this document. 3198 The use of pre-shared keys may be considered for authentication at 3199 the transport layer. If this option is selected, the specifications 3200 set forth in "Pre-Shared Key Ciphersuites for Transport Layer 3201 Security (TLS)" [RFC4279] MUST be followed. Transport specifications 3202 are detailed in a separate document [RFC6046-bis]. 3204 9.3.2. Multi-Hop Request Authentication 3206 The use of multi-hop authentication in a Request is used when a 3207 Request is sent to multiple entities or SPs in an iterative manner. 3208 Multi-hop authentication is REQUIRED in Requests that involve 3209 multiple SPs where Requests are forwarded iteratively through peers. 3210 Bilateral trust relationships MAY be used between peers, then Multi- 3211 hop authentication MUST be used for cases where the originator of a 3212 message is authenticated several hops into the message flow. 3214 For practical reasons, SPs may want to prioritize incident handling 3215 events based upon the immediate peer for a Request, the originator of 3216 a request, and the listed Confidence rating for the incident. In 3217 order to provide a higher assurance level of the authenticity of a 3218 Request, the originating RID system is included in the Request along 3219 with contact information and the information of all RID systems in 3220 the path the trace has taken. This information is provided through 3221 the IODEF EventData class nesting the list of systems and contacts 3222 involved in a trace, while setting the category attribute to 3223 "infrastructure". 3225 To provide multi-hop authentication, the originating RID system MUST 3226 include a digital signature in the Request sent to all systems in the 3227 upstream path. The digital signature from the RID system is 3228 performed on the RecordItem class of the IODEF following the XML 3229 digital signature specifications from W3C [XMLsig] using a detached 3230 signature. The signature MUST be passed to all parties that receive 3231 a Request, and each party MUST be able to perform full path 3232 validation on the digital signature [RFC5280]. In order to 3233 accommodate that requirement, the RecordItem data MUST remain 3234 unchanged as a request is passed along between providers and is the 3235 only element for which the signature is applied. If additional 3236 RecordItems are included in the document at upstream peers, the 3237 initial RecordItem entry MUST still remain with the detached 3238 signature. The subsequent RecordItem elements may be signed by the 3239 peer adding the incident information for the investigation. A second 3240 benefit to this requirement is that the integrity of the filter used 3241 is ensured as it is passed to subsequent SPs in the upstream trace of 3242 the incident. The trusted PKI also provides the keys used to 3243 digitally sign the RecordItem class for a Request to meet the 3244 requirement of authenticating the original request. Any host in the 3245 path of the trace should be able to verify the digital signature 3246 using the trusted PKI. 3248 In the case in which an enterprise using RID sends a Request to its 3249 provider, the signature from the enterprise MUST be included in the 3250 initial request. The SP may generate a new request to send upstream 3251 to members of the SP consortium to continue the investigation. If 3252 the original request is sent, the originating SP, acting on behalf of 3253 the enterprise network under attack, MUST also digitally sign, with 3254 an enveloped signature, the full IODEF document to assure the 3255 authenticity of the Request. An SP that offers RID as a service may 3256 be using its own PKI to secure RID communications between its RID 3257 system and the attached enterprise networks. SPs participating in 3258 the trace MUST be able to determine the authenticity of RID requests. 3260 9.4. Consortiums and Public Key Infrastructures 3262 Consortiums are an ideal way to establish a communication web of 3263 trust for RID messaging. It should be noted that direct 3264 relationships may be ideal for some communications, such as those 3265 between a provider of incident information and a subscriber of the 3266 incident reports. The consortium could provide centralized 3267 resources, such as a PKI, and established guidelines and control 3268 requirements for use of RID. The consortium may assist in 3269 establishing trust relationships between the participating SPs to 3270 achieve the necessary level of cooperation and experience-sharing 3271 among the consortium entities. This may be established through PKI 3272 certificate policy [RFC3647] reviews to determine the appropriate 3273 trust levels between organizations or entities. The consortium may 3274 also be used for other purposes to better facilitate communication 3275 among SPs in a common area (Internet, region, government, education, 3276 private networks, etc.). 3278 Using a PKI to distribute certificates used by RID systems provides 3279 an already established method to link trust relationships between 3280 consortiums that peer with SPs belonging to a separate consortium. 3281 In other words, consortiums could peer with other consortiums to 3282 enable communication of RID messages between the participating SPs. 3283 The PKI along with Memorandums of Agreement could be used to link 3284 border directories to share public key information in a bridge, a 3285 hierarchy, or a single cross-certification relationship. 3287 Consortiums also need to establish guidelines for each participating 3288 SP to adhere to. The RECOMMENDED guidelines include: 3290 o Physical and logical practices to protect RID systems; 3291 o Network and application layer protection for RID systems and 3292 communications; 3294 o Proper use guidelines for RID systems, messages, and requests; and 3296 o A PKI, certificate policy, and certification practices statement 3297 to provide authentication, integrity, and privacy. 3299 The functions described for a consortium's role parallel that of a 3300 PKI federation. The PKI federations that currently exist are 3301 responsible for establishing security guidelines and PKI trust 3302 models. The trust models are used to support applications to share 3303 information using trusted methods and protocols. 3305 A PKI can also provide the same level of security for communication 3306 between an end entity (enterprise, educational, or government 3307 customer network) and the SP. 3309 9.5. Privacy Concerns and System Use Guidelines 3311 Privacy issues raise many concerns when information-sharing is 3312 required to achieve the goal of stopping or mitigating the effects of 3313 a security incident. The RIDPolicy class is used to automate the 3314 enforcement of the privacy concerns listed within this document. The 3315 privacy and system use concerns for the system communicating RID 3316 messages and other integrated components include the following: 3318 Service Provider Concerns: 3320 o Privacy of data monitored and/or stored on Intrusion Detection 3321 Systems (IDSs) for attack detection. 3323 o Privacy of data monitored and stored on systems used to trace 3324 traffic across a single network. 3326 o Privacy of incident information stored on incident management 3327 systems participating in RID communications. 3329 Customer Attached Networks Participating in RID with SP: 3331 o Customer networks may include an enterprise, educational, 3332 government, or other attached networks to an SP participating in 3333 RID. Customers should review data handling policies to understand 3334 how data will be protected by a service provider. This 3335 information will enable customers to decide what types of data at 3336 what sensitivity level can be shared with service providers. This 3337 information could be used at the application layer to establish 3338 sharing profiles for entities and groups, see Section 9.6. 3340 o Customers should request information on the security and privacy 3341 considerations in place by their SP and the consortium of which 3342 the SP is a member. Customers should understand if their data 3343 were to be forwarded, how might it be sanitized and how will it be 3344 protected. Customers should also understand if limitations can be 3345 placed on how any data they share with their SP will be used in 3346 advance of sharing that data. 3348 o Customers should be aware that their data can and will be sent to 3349 other SPs in order to complete a trace unless an agreement stating 3350 otherwise is made in the service level agreements between the 3351 customer and SP. Customers considering privacy options may limit 3352 the use of this feature if they do not want the data forwarded. 3354 Parties Involved in the Attack: 3356 o Privacy of the identity of a host involved in an attack or any 3357 indicators of compromise. 3359 o Privacy of information such as the source and destination used for 3360 communication purposes over the monitored or RID connected 3361 network(s). 3363 o Protection of data from being viewed by intermediate parties in 3364 the path of an Request request should be considered. 3366 Consortium Considerations: 3368 o System use restrictions for security incident handling within the 3369 local region's definitions of appropriate traffic. When 3370 participating in a consortium, appropriate use guidelines should 3371 be agreed upon and entered into contracts. 3373 o System use prohibiting the consortium's participating SPs from 3374 inappropriately tracing traffic to locate sources or mitigate 3375 traffic unlawfully within the jurisdiction or region. 3377 Inter-Consortium Considerations: 3379 o System use between peering consortiums should consider any 3380 government communication regulations that apply between those two 3381 regions, such as encryption export and import restrictions. 3383 o System use between consortiums SHOULD NOT request traffic traces 3384 and actions beyond the scope intended and permitted by law or 3385 inter-consortium agreements. 3387 o System use between consortiums should consider national boundary 3388 issues and request limits in their appropriate system use 3389 agreements. Appropriate use should include restrictions to 3390 prevent the use of the protocol to limit or restrict traffic that 3391 is otherwise permitted within the country in which the peering 3392 consortium resides. 3394 The security and privacy considerations listed above are for the 3395 consortiums, SPs, and enterprises to agree upon. The agreed-upon 3396 policies may be facilitated through use of the RIDPolicy class and 3397 application layer options. Some privacy considerations are addressed 3398 through the RID guidelines for encryption and digital signatures as 3399 described in Section 9.1. 3401 RID is useful in determining the true source of an incident that 3402 traverses multiple networks or to communicate security incidents and 3403 automate the response. The information obtained from the 3404 investigation may determine the identity of the source host or the SP 3405 used by the source of the traffic. It should be noted that the trace 3406 mechanism used across a single-SP may also raise privacy concerns for 3407 the clients of the network. Methods that may raise concern include 3408 those that involve storing packets for some length of time in order 3409 to trace packets after the fact. Monitoring networks for intrusions 3410 and for tracing capabilities also raises concerns for potentially 3411 sensitive valid traffic that may be traversing the monitored network. 3412 IDSs and single-network tracing are outside of the scope of this 3413 document, but the concern should be noted and addressed within the 3414 use guidelines of the network. Some IDSs and single-network trace 3415 mechanisms attempt to properly address these issues. RID is designed 3416 to provide the information needed by any single-network trace 3417 mechanism. The provider's choice of a single trace mechanism depends 3418 on resources, existing solutions, and local legislation. Privacy 3419 concerns in regard to the single-network trace must be dealt with at 3420 the client-to-SP level and are out of scope for RID messaging. 3422 The identity of the true source of an attack being traced through RID 3423 could be sensitive. The true identity listed in a Result message can 3424 be protected through the use of encryption [XMLencrypt] enveloping 3425 the IODEF document and RID Result information, using the public 3426 encryption key of the originating SP. Alternatively, the action 3427 taken may be listed without the identity being revealed to the 3428 originating SP. The ultimate goal of the RID communication system is 3429 to stop or mitigate attack traffic, not to ensure that the identity 3430 of the attack traffic is known to involved parties. The SP that 3431 identifies the source should deal directly with the involved parties 3432 and proper authorities in order to determine the guidelines for the 3433 release of such information, if it is regarded as sensitive. In some 3434 situations, systems used in attacks are compromised by an unknown 3435 source and, in turn, are used to attack other systems. In that 3436 situation, the reputation of a business or organization may be at 3437 stake, and the action taken may be the only additional information 3438 reported in the Result message to the originating system. If the 3439 security incident is a minor incident, such as a zombie system used 3440 in part of a large-scale DDoS attack, ensuring the system is taken 3441 off the network until it has been fixed may be sufficient. The 3442 decision is left to the system users and consortiums to determine 3443 appropriate data to be shared given that the goal of the 3444 specification is to provide the appropriate technical options to 3445 remain compliant. The textual descriptions should include details of 3446 the incident in order to protect the reputation of the unknowing 3447 attacker and prevent the need for additional investigation. Local, 3448 state, or national laws may dictate the appropriate reporting action 3449 for specific security incidents. 3451 Privacy becomes an issue whenever sensitive data traverses a network. 3452 For example, if an attack occurred between a specific source and 3453 destination, then every SP in the path of the trace becomes aware 3454 that the cyber attack occurred. In a targeted attack, it may not be 3455 desirable that information about two nation states that are battling 3456 a cyber war would become general knowledge to all intermediate 3457 parties. However, it is important to allow the traces to take place 3458 in order to halt the activity since the health of the networks in the 3459 path could also be at stake during the attack. This provides a 3460 second argument for allowing the Result message to only include an 3461 action taken and not the identity of the offending host. In the case 3462 of a Request or Report, where the originating SP is aware of the SP 3463 that will receive the request for processing, the free-form text 3464 areas of the document could be encrypted [XMLencrypt] using the 3465 public key of the destination SP to ensure that no other SP in the 3466 path can read the contents. The encryption is accomplished through 3467 the W3C [XMLencrypt] specification for encrypting an element. 3469 In some situations, all network traffic of a nation may be granted 3470 through a single SP. In that situation, options must support sending 3471 Result messages from a downstream peer of that SP. That option 3472 provides an additional level of abstraction to hide the identity and 3473 the SP of the identified source of the traffic. Legal action may 3474 override this technical decision after the trace has taken place, but 3475 that is out of the technical scope of this document. 3477 Privacy concerns when using an Request message to request action 3478 close to the source of valid attack traffic needs to be considered. 3479 Although the intermediate SPs may relay the request if there is no 3480 direct trust relationship to the closest SP to the source, the 3481 intermediate SPs do not require the ability to see the contents of 3482 the packet or the text description field(s) in the request. This 3483 message type does not require any action by the intermediate RID 3484 systems, except to relay the packet to the next SP in the path. 3485 Therefore, the contents of the request may be encrypted for the 3486 destination system. The intermediate SPs only needs to know how to 3487 direct the request to the manager of the ASN in which the source IP 3488 address belongs. 3490 Traces must be legitimate security-related incidents and not used for 3491 purposes such as sabotage or censorship. An example of such abuse of 3492 the system includes a request to block or rate-limit legitimate 3493 traffic to prevent information from being shared between users on the 3494 Internet (restricting access to online versions of papers) or 3495 restricting access from a competitor's product in order to sabotage a 3496 business. 3498 Intra-consortium RID communications raise additional issues, 3499 especially when the peering consortiums reside in different regions 3500 or nations. Request messages and requested actions to mitigate or 3501 stop traffic must adhere to the appropriate use guidelines and yet 3502 prevent abuse of the system. First, the peering consortiums must 3503 identify the types of traffic that can be traced between the borders 3504 of the participating SPs of each consortium. The traffic traced 3505 should be limited to security-incident-related traffic. Second, the 3506 traces permitted within one consortium if passed to a peering 3507 consortium may infringe upon the peering consortium's freedom of 3508 information laws. An example would be a consortium in one country 3509 permitting a trace of traffic containing objectionable material, 3510 outlawed within that country. The RID trace may be a valid use of 3511 the system within the confines of that country's network border; 3512 however, it may not be permitted to continue across network 3513 boundaries where such content is permitted under law. By continuing 3514 the trace in another country's network, the trace and response could 3515 have the effect of improperly restricting access to data. A 3516 continued trace into a second country may break the laws and 3517 regulations of that nation. Any such traces MUST cease at the 3518 country's border. 3520 The privacy concerns listed in this section address issues among the 3521 trusted parties involved in a trace within an SP, a RID consortium, 3522 and peering RID consortiums. Data used for RID communications must 3523 also be protected from parties that are not trusted. This protection 3524 is provided through the authentication and encryption of documents as 3525 they traverse the path of trusted servers and the local security 3526 controls in place for the incident management systems. Each RID 3527 system MUST perform a bi-directional authentication when sending a 3528 RID message and use the public encryption key of the upstream or 3529 downstream peer to send a message or document over the network. This 3530 means that the document is decrypted and re-encrypted at each RID 3531 system via TLS over a transport protocol such as [RFC6046-bis]. The 3532 RID messages may be decrypted at each RID system in order to properly 3533 process the request or relay the information. Today's processing 3534 power is more than sufficient to handle the minimal burden of 3535 encrypting and decrypting relatively small typical RID messages. 3537 9.6. Sharing Profiles and Policies 3539 The application layer can be used to establish workflows and rulesets 3540 specific to sharing profiles for entities or consortiums. The 3541 profiles can leverage sharing agreements to restrict data types or 3542 classifications of data that are shared. The level of information or 3543 classification of data shared with any entity may be based on 3544 protection levels offered by the receiving entity and periodic 3545 validation of those controls. The profile may also indicate how far 3546 information can be shared according to the entity and data type. The 3547 profile can also support if requests to share data from an entity 3548 must go directly to that entity. 3550 In some cases, pre-defined sharing profiles will be possible. These 3551 include any use case where an agreement is in place in advance of 3552 sharing. Examples may be between clients and SPs, entities such as 3553 partners, or consortiums. There may be other cases when sharing 3554 profiles may not be established in advance, such as an organization 3555 dealing with an incident who requires assistance from an entity that 3556 have not worked with before. An organization may want to establish 3557 sharing profiles specific to possible user groups to prepare for 3558 possible incident scenarios. The user groups could include business 3559 partners, industry peers, service providers, experts not part of a 3560 service provider, law enforcement, or regulatory repotting bodies. 3562 Workflows to approve transactions may be specific to sharing profiles 3563 and data types. Application developers should include capabilities 3564 to enable these decision points for users of the system. 3566 Any expectations between entities to preserve the weight and 3567 admissibility of evidence should be handled at the policy and 3568 agreement level. A sharing profile may include notes or an indicator 3569 for approvers in workflows to reflect if such agreements exist. 3571 10. Security Considerations 3573 RID has many security requirements and considerations built into the 3574 design of the protocol, several of which are described in the 3575 Security Requirements section. For a complete view of security, 3576 considerations include the availability, confidentiality, and 3577 integrity concerns for the transport, storage, and exchange of 3578 information. 3580 Protected tunnels between systems accepting RID communications are 3581 used to provide confidentiality, integrity, authenticity, and privacy 3582 for the data at the transport layer. Encryption and digital 3583 signatures are also used at the IODEF document level through RID 3584 options to provide confidentiality, integrity, authenticity, privacy 3585 and traceability of the document contents at the application layer. 3586 Trust relationships are based on PKI and the comparison/validation of 3587 security controls for the incident management systems communicating 3588 via RID. Trust levels can be established in cross-certification 3589 processes where entities compare PKI policies that include the 3590 specific management and handling of an entity's PKI and certificates 3591 issued under that policy. [RFC3647] defines an Internet X.509 Public 3592 Key Infrastructure Certificate Policy and Certification Practices 3593 Framework that may be used in the comparison of policies to establish 3594 trust levels and agreements between entities, an entity and a 3595 consortium, and consortia. The agreements SHOULD consider key 3596 management practices including the ability to perform path validation 3597 on certificates [RFC5280], key distribution techniques [RFC2585], 3598 Certificate Authority and Registration Authority management 3599 practices. 3601 The agreements between entities SHOULD also include a common 3602 understanding of the usage of RID security, policy, and privacy 3603 options discussed in both the Security Requirements and Security 3604 Considerations sections. The formality, requirements, and complexity 3605 of the agreements for the certificate policy, practices, supporting 3606 infrastructure, and the use of RID options SHOULD be decided by the 3607 entities or consortiums creating those agreements. 3609 11. Internationalization Issues 3611 The Node class identifies a host or network device. This document 3612 re-uses the definition of Node from the IODEF specification 3613 [RFC5070], Section 3.16. However, that document did not clearly 3614 specify whether a NodeName could be an Internationalized Domain Name 3615 (IDN). RID systems MUST treat the NodeName class as a domain name 3616 slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName 3617 class; if they do so, the UTF-8 representation of the domain name 3618 MUST be used, i.e., all of the domain name's labels MUST be U-labels 3619 expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be 3620 used. An application communicating via RID can convert between 3621 A-labels and U-labels by using the Punycode encoding [RFC3492] for 3622 A-labels as described in the protocol specification for 3623 Internationalized Domain Names in Applications [RFC5891]. 3625 12. IANA Considerations 3627 This document uses URNs to describe XML namespaces and XML schemas 3628 [XMLschema] conforming to a registry mechanism described in 3629 [RFC3688]. 3631 Registration request for the iodef-rid namespace: 3633 URI: urn:ietf:params:xml:ns:iodef-rid-2.0 3635 Registrant Contact: IESG. 3637 XML: None. Namespace URIs do not represent an XML specification. 3639 Registration request for the iodef-rid XML schema: 3641 URI: urn:ietf:params:xml:schema:iodef-rid-2.0 3643 Registrant Contact: IESG. 3645 XML: See Section 8, "RID Schema Definition", of this document. 3647 Request for the specified registry to be created and managed by IANA: 3649 Name of the registry:"XML Schemas Exchanged via RID" 3651 Namespace details: A registry entry for an XML Schema Transferred 3652 via RID consists of: 3654 Schema Name: A short string that represents the schema 3655 referenced. This value is for reference only in the table. 3656 The version of the schema MUST be included in this string to 3657 allow for multiple versions of the same specification to be in 3658 the registry. 3660 Version: The version of the registered XML schema. The version 3661 is a string that SHOULD be formatted as numbers separated by a 3662 '.' (period) character. 3664 Namespace: The namespace of the referenced XML schema. This is 3665 represented in the RID ReportSchema class in the XMLSchemaID 3666 attribute as an enumerated value is represented by a URN or 3667 URI. 3669 Specification URI: A URI [RFC3986] from which the registered 3670 specification can be obtained. The specification MUST be 3671 publicly available from this URI. 3673 Information that must be provided to assign a new value: The above 3674 list of information. 3676 Fields to record in the registry: Schema Name/Version/Namespace/ 3677 Specification URI 3679 Initial registry contents: See section 5.5.1. 3681 Allocation Policy: Expert Review [RFC5226] and Specification 3682 Required [RFC5226]. 3684 The Designated Expert is expected to consult with the mile (Managed 3685 Incident Lightweight Exchange) working group or its successor if any 3686 such WG exists (e.g., via email to the working group's mailing list). 3687 The Designated Expert is expected to retrieve the XML schema 3688 specification from the provided URI in order to check the public 3689 availability of the specification and verify the correctness of the 3690 URI. An important responsibility of the Designated Expert is to 3691 ensure that the XML schema is appropriate for use in RID. 3693 Request for the specified registry to be created and managed by IANA: 3695 Name of the registry:"RID Enumeration List" 3697 The registry is intended to enable enumeration value additions to 3698 attributes in the iodef-rid XML schema. 3700 Fields to record in the registry: Attribute Name/Attribute Value/ 3701 Description 3703 Initial registry content: none. 3705 Allocation Policy: Expert Review [RFC5226] 3707 The Designated Expert is expected to consult with the mile (Managed 3708 Incident Lightweight Exchange) working group or its successor if any 3709 such WG exists (e.g., via email to the working group's mailing list). 3710 The Designated Expert is expected to review the request and validate 3711 the appropriateness of the enumeration for the attribute. If a draft 3712 specification is associated with the request, it MUST be reviewed by 3713 the Designated Expert. 3715 13. Summary 3717 Security incidents have always been difficult to trace as a result of 3718 the spoofed sources, resource limitations, and bandwidth utilization 3719 problems. Incident response is often slow even when the IP address 3720 is known to be valid because of the resources required to notify the 3721 responsible party of the attack and then to stop or mitigate the 3722 attack traffic. Methods to identify and trace attacks near real time 3723 are essential to thwarting attack attempts. SPs need policies and 3724 automated methods to combat the hacker's efforts. SPs need automated 3725 monitoring and response capabilities to identify and trace attacks 3726 quickly without resource-intensive side effects. Integration with a 3727 centralized communication system to coordinate the detection, 3728 tracing, and identification of attack sources on a single network is 3729 essential. RID provides a way to integrate SP resources for each 3730 aspect of attack detection, tracing, and source identification and 3731 extends the communication capabilities among SPs. The communication 3732 is accomplished through the use of flexible IODEF XML-based documents 3733 passed between IHSs or RID systems. A Request is communicated to an 3734 upstream SP and may result in an upstream trace or in an action to 3735 stop or mitigate the attack traffic. The messages are communicated 3736 among peers with security inherent to the RID messaging scheme 3737 provided through existing standards such as XML encryption and 3738 digital signatures. Policy information is carried in the RID message 3739 itself through the use of the RIDPolicy. RID provides the timely 3740 communication among SPs, which is essential for incident handling. 3742 14. References 3744 14.1. Normative References 3746 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3747 Requirement Levels", BCP 14, RFC 2119, March 1997. 3749 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 3750 Infrastructure Operational Protocols: FTP and HTTP", 3751 RFC 2585, May 1999. 3753 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 3754 Types", RFC 3023, January 2001. 3756 [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 3757 Language) XML-Signature Syntax and Processing", RFC 3275, 3758 March 2002. 3760 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 3761 for Internationalized Domain Names in Applications 3762 (IDNA)", RFC 3492, March 2003. 3764 [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for 3765 the Use of Extensible Markup Language (XML) 3766 within IETF Protocols", BCP 70, RFC 3470, January 2003. 3768 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3769 January 2004. 3771 [RFC4051] Eastlake, D., "Additional XML Security Uniform Resource 3772 Identifiers (URIs)", RFC 4051, April 2005. 3774 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 3775 for Transport Layer Security (TLS)", RFC 4279, 3776 December 2005. 3778 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 3779 Object Description Exchange Format", RFC 5070, 3780 December 2007. 3782 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3783 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3784 May 2008. 3786 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3787 Housley, R., and W. Polk, "Internet X.509 Public Key 3788 Infrastructure Certificate and Certificate Revocation List 3789 (CRL) Profile", RFC 5280, May 2008. 3791 [RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet 3792 Attribute Certificate Profile for Authorization", 3793 RFC 5755, January 2010. 3795 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 3796 Languages", BCP 47, RFC 5646, September 2009. 3798 [RFC5890] Klensin, J., "Internationalized Domain Names for 3799 Applications (IDNA): Definitions and Document Framework", 3800 RFC 5890, August 2010. 3802 [RFC5891] Klensin, J., "Internationalized Domain Names in 3803 Applications (IDNA): Protocol", RFC 5891, August 2010. 3805 [RFC6046-bis] 3806 Trammell, B., "Transport of Real-time Inter-network 3807 Defense (RID) Messages", January 2012, . 3810 [XML1.0] Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C., and 3811 F. Yergeau, "Extensible Markup Language (XML) 1.0", W3C 3812 Recommendation XML 1.0, November 2008, 3813 . 3815 [XMLCanon] 3816 Boyer, J., "Canonical XML 1.0", W3C Recommendation 1.0, 3817 December 2001, . 3819 [XMLencrypt] 3820 Imaura, T., Dillaway, B., and E. Simon, "XML Encryption 3821 Syntax and Processing", W3C Recommendation , 3822 December 2002, . 3824 [XMLPath] Berglund, A., Boag, S., Chamberlin, D., Fernandez, M., 3825 Kay, M., Robie, J., and J. Simeon, "XML Schema Part 1: 3826 Structures", W3C Recommendation Second Edition, 3827 December 2010, . 3829 [XMLschema] 3830 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 3831 "XML Schema Part 1: Structures", W3C Recommendation Second 3832 Edition, October 2004, 3833 . 3835 [XMLsig] Bartel, M., Boyer, J., Fox, B., LaMaccia, B., and E. 3836 Simon, "XML-Signature Syntax and Processing", W3C 3837 Recommendation Second Edition, June 2008, 3838 . 3840 [XMLSigBP] 3841 Hirsch, F. and P. Datta, "XML-Signature Best Practices", 3842 W3C Recommendation , August 2011, 3843 . 3845 14.2. Informative References 3847 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 3848 selection, and registration of an Autonomous System (AS)", 3849 BCP 6, RFC 1930, March 1996. 3851 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 3852 Wu, "Internet X.509 Public Key Infrastructure Certificate 3853 Policy and Certification Practices Framework", RFC 3647, 3854 November 2003. 3856 [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", 3857 RFC 3080, March 2001. 3859 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3860 Resource Identifier (URI): Generic Syntax", STD 66, 3861 RFC 3986, January 2005. 3863 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 3864 BCP 153, RFC 5735, January 2010. 3866 [RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)", 3867 RFC 6045, November 2010. 3869 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 3870 Considerations for the SHA-0 and SHA-1 Message-Digest 3871 Algorithms", RFC 6194, March 2011. 3873 [XMLNames] 3874 Bray, T., Hollander, D., Layman, A., Tobin, R., and H. 3875 Thomson, "Namespaces in XML 1.0 (Third Edition)", W3C 3876 Recommendation , December 2009, 3877 . 3879 Acknowledgements 3881 Many thanks to colleagues and the Internet community for reviewing 3882 and commenting on the document as well as providing recommendations 3883 to improve, simplify, and secure the protocol: Steve Bellovin, David 3884 Black, Harold Booth, Paul Cichonski, Robert K. Cunningham, Roman 3885 Danyliw, Yuri Demchenko, Sandra G. Dykes, Stephen Farrell, Katherine 3886 Goodier, Cynthia D. McLain, Thomas Millar, Jean-Francois Morfin, 3887 Stephen Northcutt, William Streilein, Damir Rajnovic, Tony Rutkowski, 3888 Peter Saint-Andre, Jeffrey Schiller, Robert Sparks, Richard Struse, 3889 Tony Tauber, Brian Trammell, Sean Turner, Iljitsch van Beijnum, and 3890 David Waltermire. 3892 Author's Address 3894 Kathleen M. Moriarty 3895 EMC Corporation 3896 176 South Street 3897 Hopkinton, MA 3898 United States 3900 Phone: 3901 Email: Kathleen.Moriarty@emc.com