idnits 2.17.1 draft-ietf-mile-rfc6045-bis-03.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 : ---------------------------------------------------------------------------- -- 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? -- The draft header indicates that this document obsoletes RFC6045, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 7, 2011) is 4524 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 5070 (Obsoleted by RFC 7970) ** Obsolete normative reference: RFC 6046 (Obsoleted by RFC 6546) -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLNames' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLencrypt' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLschema' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLsig' -- 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: 2 errors (**), 0 flaws (~~), 1 warning (==), 9 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) December 7, 2011 4 Intended status: Standards Track 5 Expires: June 9, 2012 7 Real-time Inter-network Defense (RID) 8 draft-ietf-mile-rfc6045-bis-03.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. 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 June 9, 2012. 45 Copyright Notice 47 Copyright (c) 2011 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. Normative and Informative . . . . . . . . . . . . . . . . 6 64 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 65 2. Characteristics of Incidents . . . . . . . . . . . . . . . . . 6 66 3. Communication between CSIRTs and Service Providers . . . . . . 8 67 3.1. Inter-network Provider RID Messaging . . . . . . . . . . . 10 68 3.2. RID Communication Topology . . . . . . . . . . . . . . . . 12 69 3.3. Message Formats . . . . . . . . . . . . . . . . . . . . . 13 70 3.4. RID Data Types . . . . . . . . . . . . . . . . . . . . . . 14 71 3.4.1. Boolean . . . . . . . . . . . . . . . . . . . . . . . 14 72 3.5. RID Message Types . . . . . . . . . . . . . . . . . . . . 14 73 4. IODEF-RID Schema . . . . . . . . . . . . . . . . . . . . . . . 15 74 4.1. RIDPolicy Class . . . . . . . . . . . . . . . . . . . . . 17 75 4.2. RequestStatus . . . . . . . . . . . . . . . . . . . . . . 23 76 4.3. IncidentSource . . . . . . . . . . . . . . . . . . . . . . 25 77 4.4. RID Name Spaces . . . . . . . . . . . . . . . . . . . . . 26 78 5. RID Messages . . . . . . . . . . . . . . . . . . . . . . . . . 26 79 5.1. TraceRequest . . . . . . . . . . . . . . . . . . . . . . . 26 80 5.2. RequestAuthorization . . . . . . . . . . . . . . . . . . . 28 81 5.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . . 28 82 5.4. Investigation Request . . . . . . . . . . . . . . . . . . 31 83 5.5. Report . . . . . . . . . . . . . . . . . . . . . . . . . . 32 84 5.6. IncidentQuery . . . . . . . . . . . . . . . . . . . . . . 33 85 6. RID Communication Exchanges . . . . . . . . . . . . . . . . . 35 86 6.1. Upstream Trace Communication Flow . . . . . . . . . . . . 35 87 6.1.1. RID TraceRequest Example . . . . . . . . . . . . . . . 37 88 6.1.2. RequestAuthorization Message Example . . . . . . . . . 41 89 6.1.3. Result Message Example . . . . . . . . . . . . . . . . 42 90 6.2. Investigation Request Communication Flow . . . . . . . . . 45 91 6.2.1. Investigation Request Example . . . . . . . . . . . . 46 92 6.2.2. RequestAuthorization Message Example . . . . . . . . . 48 93 6.3. Report Communication Flow . . . . . . . . . . . . . . . . 48 94 6.3.1. Report Example . . . . . . . . . . . . . . . . . . . . 49 96 6.4. IncidentQuery Communication Flow . . . . . . . . . . . . . 51 97 6.4.1. IncidentQuery Example . . . . . . . . . . . . . . . . 51 98 7. RID Schema Definition . . . . . . . . . . . . . . . . . . . . 52 99 8. Security Requirements . . . . . . . . . . . . . . . . . . . . 56 100 8.1. XML Digital Signatures and Encryption . . . . . . . . . . 56 101 8.2. Message Transport . . . . . . . . . . . . . . . . . . . . 59 102 8.3. Message Delivery Protocol - Integrity and 103 Authentication . . . . . . . . . . . . . . . . . . . . . . 60 104 8.4. Transport Communication . . . . . . . . . . . . . . . . . 61 105 8.5. Authentication of RID Protocol . . . . . . . . . . . . . . 62 106 8.5.1. Multi-Hop TraceRequest Authentication . . . . . . . . 63 107 8.6. Consortiums and Public Key Infrastructures . . . . . . . . 64 108 8.7. Privacy Concerns and System Use Guidelines . . . . . . . . 65 109 9. Security Considerations . . . . . . . . . . . . . . . . . . . 69 110 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70 111 11. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 71 113 12.1. Normative References . . . . . . . . . . . . . . . . . . . 71 114 12.2. Informative References . . . . . . . . . . . . . . . . . . 73 115 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 73 117 1. Introduction 119 This document moves Real-time Inter-network Defense (RID) [RFC6045] 120 to Historic status as it provides minor updates. Organizations 121 require help from other parties to identify incidents, mitigate 122 malicious activity targeting their computing resources, and to gain 123 insight into potential threats through the sharing of information. 124 This coordination might entail working with a service provider (SP) 125 to filter attack traffic, working with a SP to resolve a 126 configuration issue unintentionally causing problems, contacting a 127 remote site to take down a bot- network, or sharing watch-lists of 128 known malicious IP addresses in a consortium. 130 Incident handling involves the detection, reporting, identification, 131 and mitigation of an incident, whether it be a benign configuration 132 issue, IT incident, an infraction to a service level agreement (SLA), 133 system compromise, socially engineered phishing attack, or a denial- 134 of-service (DoS) attack, etc.. When an incident is detected, the 135 response may include simply filing a report, notification to the 136 source of the incident, a request to a SP for resolution/mitigation, 137 or a request to locate the source. One of the more difficult cases 138 is that in which the source of an attack is unknown, requiring the 139 ability to trace the attack traffic iteratively upstream through the 140 network for the possibility of any further actions to take place. In 141 cases when accurate records of an active session between the target 142 or victim system and the source or attacking system are available, 143 the source is easy to identify. 145 Real-time inter-network defense (RID) outlines a proactive inter- 146 network communication method to facilitate sharing incident handling 147 data while integrating existing detection, tracing, source 148 identification, and mitigation mechanisms for a complete incident 149 handling solution. RID provides a secure method to communicate 150 incident information, enabling the exchange of incident object 151 description and exchange format (IODEF) [RFC5070] extensible markup 152 language (XML) documents. RID considers security, policy, and 153 privacy issues related to the exchange of potentially sensitive 154 information, enabling service providers or organizations the options 155 to make appropriate decisions according to their policies. RID 156 includes provisions for confidentiality, integrity, and 157 authentication. 159 The data in RID messages is represented in an XML [XML1.0] document 160 using the IODEF and RID. By following this model, integration with 161 other aspects for incident handling is simplified. Methods are 162 incorporated into the communication system to indicate what actions 163 need to be taken closest to the source in order to halt or mitigate 164 the effects of the incident or attack at hand. RID is intended to 165 provide a method to communicate the relevant information between 166 computer security incident response teams (CSIRTs) while being 167 compatible with a variety of existing and possible future detection 168 tracing and response approaches. Incidents may be extended to 169 include Information Technology (IT) incidents, where RID enables the 170 communication between or within providers for non-security IT 171 incidents. 173 Security and privacy considerations are of high concern since 174 potentially sensitive information may be passed through RID messages. 175 RID messaging takes advantage of XML security, privacy, and policy 176 information set in the RID schema. The RID schema defines 177 communication specific metadata to support the communication of IODEF 178 documents for exchanging or tracing information regarding incidents. 179 RID messages are encapsulated for transport, which is defined in a 180 separate document [RFC6046-bis]. The authentication, integrity, and 181 authorization features RID and RID transport offer are used to 182 achieve a necessary level of security. 184 Coordinating with other CSIRTs is not strictly a technical problem. 185 There are numerous procedural, trust, and legal considerations that 186 might prevent an organization from sharing information. RID provides 187 information and options that can be used by organizations who must 188 then apply their own policies for sharing information. Organizations 189 must develop policies and procedures for the use of the RID protocol 190 and IODEF. 192 This specification updates [RFC6045]. Differences from [RFC6045] are 193 summarized below: 195 o Edits reflected in this updated version of RFC6045 are primarily 196 improvements to the informational descriptions. The descriptions 197 have been updated to clarify the use of IODEF and RID extend for 198 all types of incidents and are not limited to network security 199 incidents. The language has been updated to reduce a focus on 200 attacks and instead on incidents where appropriate. The term 201 network provider has been replaced with the more generic term of 202 service provider. Several introductory informational sections 203 have been removed as they are not necessary for the implementation 204 of the protocol. The sections include: 206 * 1.3. Attack Types and RID Messaging, 208 * 2. RID Integration with Network Provider Technologies, 210 * 3.1. Integrating Trace Approaches, and 211 * 3.2. Superset of Packet Information for Traces. 213 o An option for a star topology has been included in an 214 informational section to meet current use case requirements of 215 those who provide reports on incident information. 217 o The schema remains the same with the exception updates for 218 reported errata and an additional enumeration in the RIDPolicy 219 class for 'LawEnforcement'. Additional text has been provided to 220 clarify definitions of enumerated values for some attributes. 222 o Guidance has improved to ensure consistent implementations and use 223 of XML encryption to provide confidentiality based on data 224 markers, specifically the iodef:restriction attribute in the IODEF 225 and IODEF-RID schemas. The attribute may also be present in IODEF 226 extension schemas, where the guidance also applies. 228 o All of the normative text from the Security Considerations Section 229 has been moved to a new Section, Security Requirements. 231 o The order in which the RID Schema is presented in Section 4 has 232 been changed to match the order in the IODEF-RID schema. 234 o Additional text has been provided to explain the content and 235 interactions between entities in the examples. 237 1.1. Normative and Informative 239 The XML schema [XMLschema] and transport requirements contained in 240 this document are normative; all other information provided is 241 intended as informative. More specifically, the following sections 242 of this document are intended as informative: Sections 1, 2, and 9; 243 and the sub-sections of 3 including the introduction to 3, 3.1, and 244 3.2. The following sections of this document are normative: The sub- 245 sections of 3 including 3.3, 3.4, and 3.5; Sections 5, 6, 7, 8, 10, 246 and 11. 248 1.2. Terminology 250 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 251 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 252 document are to be interpreted as described in [RFC2119]. 254 2. Characteristics of Incidents 256 The goal of tracing a security incident may be to identify the source 257 or to find a point on the network as close to the origin of the 258 incident as possible. An incident may be defined as a benign 259 configuration issue, IT incident, an infraction to a service level 260 agreement (SLA), system compromise, a worm or Trojan infection, or a 261 single- or multiple-source denial-of-service attack. Incident 262 tracing can be used to identify the source(s) of an attack in order 263 to halt or mitigate the undesired behavior or to correct an 264 identified issue. RID messages can be communicated between entities 265 to report or investigate any type of incident and allows for actions 266 to be taken when the source of the incident or a point closer to the 267 source is known or has been identified. The purpose of tracing an 268 incident is to remedy the detected issue, halt, or mitigate the 269 effects of the incident. Methods to accomplish this may include 270 remediation of a configuration issue, filtering or rate-limiting the 271 traffic close to the source, or taking the host or network offline. 272 Care must also be taken to ensure that the systems involved in the 273 RID communications are not abused and to use proper analysis in 274 determining if attack traffic is, in fact, attack traffic at each SP 275 along the path of a trace. 277 Tracing security incidents can be a difficult task since attackers go 278 to great lengths to obscure their identity. In the case of a 279 security incident, the true source might be identified through an 280 existing established connection to the attacker's point of origin. 281 However, the attacker may not connect to the compromised system for a 282 long period of time after the initial compromise or may access the 283 system through a series of compromised hosts spread across the 284 network. Other methods of obscuring the source may include targeting 285 the host with the same attack from multiple sources using both valid 286 and spoofed source addresses. This tactic can be used to compromise 287 a machine and leave the difficult task of locating the true origin 288 for the administrators. Attackers use many techniques which can vary 289 between individuals or even organized groups of attackers. Through 290 analysis, the techniques may be grouped into indicators of compromise 291 to be shared via IODEF and RID, further assisting with the 292 improvement of detection capabilities. Security incidents, including 293 DDoS attacks, can be difficult or nearly impossible to trace because 294 of the nature of the attack. Some of the difficulties in 295 investigating attacks include the following: 297 o the incident or attack originates from multiple sources; 299 o the incident may leverage social engineering techniques or other 300 methods to gain access to resources and intellectual property 301 using what appears to be legitimate access methods such as 302 outbound web sessions from user systems; 304 o the attack may include various types of traffic meant to consume 305 server resources, such as a SYN flood attack without a significant 306 increase in bandwidth utilization; 308 o the type of traffic could include valid destination services, 309 which cannot be blocked since they are essential services to 310 business, such as DNS servers at an NP or HTTP requests sent to an 311 organization connected to the Internet; 313 o the attack may utilize varying types of packets including TCP, 314 UDP, ICMP, or other IP protocols; 316 o the attack may be from "zombies" or large "botnets", which then 317 require additional searches to locate a controlling server as the 318 true origin of the attack; 320 o the attack may use a very small number of packets from any 321 particular source, thus making a trace after the fact nearly 322 impossible; 324 o the indicators of a compromise may be difficult to detect. 326 If the source(s) of an incident cannot be determined from IP address 327 information it may be possible to trace the traffic based on 328 characteristics of the incident such as tracing the increased 329 bandwidth utilization or the type of packets seen by the client. In 330 the case of packets with spoofed source addresses, it is not a 331 trivial task to identify the source of an attack. 333 IODEF, any extensions to IODEF, and RID can be used to detail an 334 incident, characteristics of the incident (as it evolves), the 335 incident history, and communications of the incident to facilitate 336 the resolution and reporting of the incident. 338 3. Communication between CSIRTs and Service Providers 340 Note: The Introduction, and Sub-sections 3.1 and 3.2, are 341 informative, with the exception of references to IODEF/RID Transport 342 RFC6046-bis [RFC6046-bis]. Sub-sections 3.3, 3.4, and 3.5 are 343 normative. 345 Expediting the communication between CSIRTs and service providers 346 (SP) is essential when responding to a security-related incident, 347 which may cross network access points (Internet backbones or cloud 348 infrastructures) between service or network providers. As a result 349 of the urgency involved in this inter-service provider security 350 incident communication, there must be an effective system in place to 351 facilitate the interaction. This communication policy or method 352 should involve multiple means of communication to avoid a single 353 point of failure. Email is one way to transfer information about the 354 incident, packet traces, etc. However, email may not be received in 355 a timely fashion or be acted upon with the same urgency as a phone 356 call or other communication mechanism like RID. 358 A technical solution to trace traffic across a single service or 359 network provider may include homegrown or commercial systems for 360 which RID messaging must accommodate the input requirements. The 361 incident handling system used on the service or network provider's 362 backbone by the CSIRT to coordinate the trace across the single 363 network requires a method to accept and process and relay RID 364 messages to the system, as well as to wait for responses from the 365 system to continue the RID request process as appropriate. In this 366 scenario, each service provider maintains its own system capable of 367 communicating via RID and integrate with a management station used 368 for monitoring and analysis. An alternative for providers lacking 369 sufficient resources may be to have a neutral third party with access 370 to the provider's network resources who could be used to perform the 371 incident handling functions. This could be a function of a central 372 organization operating as a CSIRT for countries as a whole or within 373 a consortium that may be able to provide centralized resources. An 374 example of a consortium might include the cloud service providers. 376 Consortiums could consist of a group of service (network, cloud, 377 etc.) providers, CSIRTs, or other federation that agrees to 378 participate in the RID communication protocol with an agreed-upon 379 policy and communication protocol facilitating the secure transport 380 of IODEF/RID XML documents. Transport for RID messages is specified 381 in the IODEF/RID Transport [X.ridd] Recommendation. 383 One goal of RID is to prevent the need to permit access to other 384 networks' equipment through the use of a standard messaging mechanism 385 to enable the communication of incident handling information to other 386 providers in a consortium or in neighboring networks. The third 387 party mentioned above may be used in this technical solution to 388 assist in facilitating incident handling and possibly traceback 389 through smaller providers. The RID messaging mechanism may be a 390 logical or physical out-of-band network to ensure that the 391 communication is secure and unaffected by the state of the network 392 under attack. The two management methods would accommodate the needs 393 of larger providers to maintain full management of their network, and 394 the third-party option could be available to smaller providers who 395 lack the necessary human resources to perform incident handling 396 operations. The first method enables the individual providers to 397 involve their network operations staff to authorize the continuance 398 of a trace or other necessary response to a RID communication request 399 through their network via a notification and alerting system. 401 The network used for the communication should consist of out-of-band 402 or protected channels (direct communication links) or encrypted 403 channels dedicated to the transport of RID messages. The 404 communication links would be direct connections (virtual or physical) 405 between peers who have agreed-upon use and abuse policies through a 406 consortium. Consortiums might be linked through policy comparisons 407 and additional agreements to form a larger web or iterative network 408 of peers that correlates to the traffic paths available over the 409 larger web of networks or based on regions and logical groups. 410 Contact information, IP addresses of RID systems, and other 411 information must be coordinated between bilateral peers by a 412 consortium and may use existing databases, such as the routing 413 arbiter. The security, configuration, and confidence rating schemes 414 of the RID messaging peers must be negotiated by peers and must meet 415 certain overall requirements of the fully connected network 416 (Internet, government, education, etc.) through the peering and/or a 417 consortium-based agreement. 419 RID messaging established with clients of an provider may be 420 negotiated in a contract as part of a value-added service or through 421 a service level agreement (SLA). Further discussion is beyond the 422 scope of this document and may be more appropriately handled in 423 peering or service level agreements. 425 Procedures for incident handling need to be established and well 426 known by anyone that may be involved in incident response. The 427 procedures should also contain contact information for internal 428 escalation procedures, as well as for external assistance groups such 429 as a CSIRT, CERT Coordination Center (CERT/CC), Global Information 430 Assurance Certification (GIAC), and the FBI or other assisting 431 government organization in the country of the investigation. 433 3.1. Inter-network Provider RID Messaging 435 RID provides a standard protocol and format that is required to 436 ensure inter-operability between vendors for the implementation of an 437 incident messaging mechanism. The messages should meet several 438 requirements in order to be meaningful as they traverse multiple 439 networks. RID provides the framework necessary for communication 440 between networks involved in the incident handling, possible 441 traceback, and mitigation of a security incident. Several message 442 types described in Section 3.5 are necessary to facilitate the 443 handling of a security incident. The message types include the 444 Report, IncidentQuery, TraceRequest, RequestAuthorization, Result, 445 and the Investigation request message. 447 The Report message is used when an incident is to be filed on a RID 448 system or associated database, where no further action is required. 450 An IncidentQuery message is used to request information on a 451 particular incident. A TraceRequest message is used when the source 452 of the traffic may have been spoofed. In that case, each network 453 provider in the upstream path who receives a TraceRequest will issue 454 a trace across the network to determine the upstream source of the 455 traffic. The RequestAuthorization and Result messages are used to 456 communicate the status and result of a TraceRequest or Investigation 457 request. The Investigation request message only involves the systems 458 accepting RID communication along the path to the source of the 459 traffic and not the use of network trace systems. The Investigation 460 request leverages the bilateral relationships or a consortium's 461 interconnections to mitigate or stop problematic traffic close to the 462 source. Routes could determine the fastest path to a known source IP 463 address in the case of an Investigation request. A message sent 464 between RID systems for a TraceRequest or an Investigation request to 465 stop traffic at the source through a bordering network requires the 466 information enumerated below: 468 1. Enough information to enable the network administrators to make a 469 decision about the importance of continuing the trace. 471 2. The incident or IP packet information needed to carry out the 472 trace or investigation. 474 3. Contact information of the origin of the RID communication. The 475 contact information could be provided through the Autonomous 476 System Number (ASN) [RFC1930] or Network Information Center (NIC) 477 handle information listed in the Registry for Internet Numbers or 478 other Internet databases. 480 4. Network path information to help prevent any routing loops 481 through the network from perpetuating a trace. If a RID system 482 receives a TraceRequest containing its own information in the 483 path, the trace must cease and the RID system should generate an 484 alert to inform the network operations staff that a tracing loop 485 exists. 487 5. A unique identifier for a single attack. This identifier should 488 be used to correlate traces to multiple sources in a DDoS attack. 490 Use of the communication network and the RID protocol must be for 491 pre-approved, authorized purposes only. It is the responsibility of 492 each participating party to adhere to guidelines set forth in both a 493 global use policy established through the peering agreements for each 494 bilateral peer or agreed-upon consortium guidelines. The purpose of 495 such policies is to avoid abuse of the system; the policies shall be 496 developed by a consortium of participating entities. The global 497 policy may be dependent on the domain it operates under; for example, 498 a government network or a commercial network such as the Internet 499 would adhere to different guidelines to address the individual 500 concerns. Privacy issues must be considered in public networks such 501 as the Internet. Privacy issues are discussed in the Security 502 Requirements section, along with other requirements that must be 503 agreed upon by participating entities. 505 RID requests must be legitimate incidents and not used for purposes 506 such as sabotage or censorship. An example of such abuse of the 507 system includes a request to rate-limit legitimate traffic to prevent 508 information from being shared between users on the Internet 509 (restricting access to online versions of papers) or restricting 510 access from a competitor's product in order to sabotage a business. 512 The RID system should be configurable to either require user input or 513 automatically continue traces. This feature enables a network 514 manager to assess the available resources before continuing an 515 investigation or trace. If the Confidence rating (provided in IODEF) 516 is low, it may not be in the provider's best interest to continue the 517 investigation or trace. The Confidence ratings must adhere to the 518 specifications for selecting the percentage used to avoid abuse of 519 the system. TraceRequests must be issued by authorized individuals 520 from the initiating CSIRT, set forth in policy guidelines established 521 through peering or a SLA. 523 3.2. RID Communication Topology 525 The most basic topology for communicating RID systems is a direct 526 connection or a bilateral relationship as illustrated below. 528 ___________ __________ 529 | | | | 530 | RID |__________-------------___________| RID | 531 |_________| | SP Border | |________| 532 ------------- 534 Figure 1: Direct Peer Topology 536 Within the consortium model, several topologies might be agreed upon 537 and used. One would leverage bilateral network peering relationships 538 of the members of the consortium. The peers for RID would match that 539 of routing peers, and the logical network borders would be used. 540 This approach may be necessary for an iterative trace where the 541 source is unknown. The model looks like the above diagram; however, 542 there may be an extensive number of interconnections of bilateral 543 relationships formed. Also within a consortium model, it may be 544 useful to establish an integrated mesh of networks to pass RID 545 messages. This may be beneficial when the source address is known, 546 and an interconnection may provide a faster route to reach the 547 closest upstream peer to the source of the attack traffic if direct 548 communication between SPs is not possible. An example is illustrated 549 below. 551 _______ _______ _______ 552 | | | | | | 553 __| RID |____-------------____| RID |____-------------____| RID |__ 554 |_____| | SP Border | |_____| | SP Border | |_____| 555 | ------------- ------------- | 556 |_______________________________________________________| 558 Direct connection to network that is not an immediate network peer 560 Figure 2: Mesh Peer Topology 562 By using a fully meshed model in a consortium, broadcasting RID 563 requests would be possible, but not advisable. By broadcasting a 564 request, RID peers that may not have carried the attack traffic on 565 their network would be asked to perform a trace for the potential of 566 decreasing the time in which the true source was identified. As a 567 result, many networks would have utilized unnecessary resources for a 568 TraceRequest that may have also been unnecessary. 570 A star topology may be desirable in instances where a peer may be a 571 provider of incident information. This requires trust relationships 572 to be established between the provider of information and each of the 573 consumers of that information. Examples may include country level 574 CSIRTs or service providers distributing incident information to 575 organizations. 577 3.3. Message Formats 579 Section 3.5 describes the six RID message types, which leverage the 580 IODEF model [RFC5070]. The messages are generated and received on 581 designated systems for RID communication on the provider's network. 582 The messages may originate from IODEF documents from intrusion 583 detection servers, CSIRTs, analysts, etc. A RID message uses both 584 the IODEF document and RID document, which is encapsulated for 585 transport [RFC6046-bis]. Each RID message type, along with an 586 example, is described in the following sections. The IODEF-RID 587 schema is introduced in Section 4 to support the RID message types in 588 Section 3.5. The term service provider (SP), used in the following 589 sections should be interpreted as any type of service provider or 590 CSIRT that may be involved in RID communications. 592 3.4. RID Data Types 594 RID is derived from the IODEF data model and inherits all of the data 595 types defined in the IODEF model. One data type is added by RID: 596 BOOLEAN. 598 3.4.1. Boolean 600 A boolean value is represented by the BOOLEAN data type. 602 The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in 603 the schema. 605 3.5. RID Message Types 607 The six RID message types are as follows: 609 1. TraceRequest. This message is sent to the next provider in the 610 upstream trace. It is used to initiate a TraceRequest or to 611 continue a TraceRequest to an upstream provider closer to the 612 source address of the origin of the security incident. The 613 TraceRequest triggers a traceback on the network to locate the 614 source of the attack traffic. 616 2. RequestAuthorization. This message is sent to the initiating RID 617 system from each of the upstream providers' RID systems to 618 provide information on the request status in the current network. 620 3. Result. This message is sent to the initiating CSIRT through the 621 network of RID systems in the path of the trace as notification 622 that the source of the attack was located. The Result message is 623 also used to provide the notification of actions taken for an 624 Investigation request. 626 4. Investigation. This message type is used when the source of the 627 traffic is believed not to be spoofed. The purpose of the 628 Investigation request message is to leverage the existing peer 629 relationships in order to notify the network provider closest to 630 the source of the valid traffic of a security-related incident 631 for any necessary actions to be taken. 633 5. Report. This message is used to report a security incident, for 634 which no action is requested. This may be used for the purpose 635 of correlating attack information by CSIRTs, sharing incident 636 information, statistics and trending information, etc. 638 6. IncidentQuery. This message is used to request information about 639 an incident or incident type from a trusted system communicating 640 via RID. The response is provided through the Report message. 642 When an application receives a RID message, it must be able to 643 determine the type of message and parse it accordingly. The message 644 type is specified in the RIDPolicy class. The RIDPolicy class may 645 also be used by the transport protocol to facilitate the 646 communication of security incident data to trace, investigate, query, 647 or report information regarding security incidents. 649 4. IODEF-RID Schema 651 There are three classes included in the RID extension required to 652 facilitate RID communications. The RequestStatus class is used to 653 indicate the approval status of a TraceRequest or Investigation 654 request; the IncidentSource class is used to report whether or not a 655 source was found and to identify the source host(s) or network(s); 656 and the RIDPolicy class provides information on the agreed-upon 657 policies and specifies the type of communication message being used. 659 The RID schema defines communication specific metadata to support the 660 exchange of incident information in an IODEF document. The intent in 661 maintaining a separate schema and not using the AdditionalData 662 extension of IODEF is the flexibility of sending messages between RID 663 hosts. Since RID is a separate schema and RID messages include both 664 the RID and IODEF schemas, the RID message acts as an envelope in 665 that policy and security defined at the RID message layer are applied 666 to both documents. One reason for maintaining separate schemas is 667 for flexibility, where the RIDPolicy class can be easily extracted 668 for use in the RID message and by the transport protocol. 670 The security requirements of sending incident information across the 671 network include the use of encryption. The RIDPolicy information is 672 not required to be encrypted, so separating out this data from the 673 IODEF extension removes the need for decrypting and parsing the 674 entire IODEF and RID document to determine how it should be handled 675 at each RID host. 677 The purpose of the RIDPolicy class is to specify the message type for 678 the receiving host, facilitate the policy needs of RID, and provide 679 routing information in the form of an IP address of the destination 680 RID system. 682 The policy information and guidelines are discussed in Section 8.7. 683 The policy is defined between RID peers and within or between 684 consortiums. The RIDPolicy is meant to be a tool to facilitate the 685 defined policies. This MUST be used in accordance with policy set 686 between clients, peers, consortiums, and/or regions. Security, 687 privacy, and confidentiality MUST be considered as specified in this 688 document. 690 The RID schema is defined as follows: 692 +------------------+ 693 | RID | 694 +------------------+ 695 | ANY | 696 | |<>---{0..1}----[ RIDPolicy ] 697 | ENUM restriction | 698 | ENUM type |<>---{0..1}----[ RequestStatus ] 699 | STRING meaning | 700 | |<>---{0..1}----[ IncidentSource ] 701 +------------------+ 703 Figure 3: The RID Schema 705 The aggregate classes that constitute the RID schema in the iodef-rid 706 namespace are as follows: 708 RIDPolicy 710 Zero or One. The RIDPolicy class is used by all message types to 711 facilitate policy agreements between peers, consortiums, or 712 federations, as well as to properly route messages. 714 RequestStatus 716 Zero or One. The RequestStatus class is used only in 717 RequestAuthorization messages to report back to the CSIRT or SP 718 originating the RID trace will be continued by each RID system 719 that received a TraceRequest in the path to the source of the 720 traffic. 722 IncidentSource 724 Zero or One. The IncidentSource class is used in the Result 725 message only. The IncidentSource provides the information on the 726 identified source host or network of an attack trace or 727 investigation. 729 Each of the three listed classes may be the only class included in 730 the RID class, hence the option for zero or one. In some cases, 731 RIDPolicy MAY be the only class in the RID definition when used by 732 the transport protocol [RFC6046-bis], as that information should be 733 as small as possible and may not be encrypted. The RequestStatus 734 message MUST be able to stand alone without the need for an IODEF 735 document to facilitate the communication, limiting the data 736 transported to the required elements per [RFC6046-bis]. 738 4.1. RIDPolicy Class 740 The RIDPolicy class facilitates the delivery of RID messages and is 741 also referenced for transport in the transport document [RFC6046- 742 bis]. 744 +------------------------+ 745 | RIDPolicy | 746 +------------------------+ 747 | | 748 | ENUM restriction |<>-------------[ Node ] 749 | ENUM MsgType | 750 | ENUM MsgDestination |<>---{0..1}----[ IncidentID ] 751 | ENUM ext-MsgType | 752 | ENUM ext-MsgDestination|<>---{1..*}----[ PolicyRegion ] 753 | | 754 | |<>---{1..*}----[ TrafficType ] 755 | | 756 +------------------------+ 758 Figure 4: The RIDPolicy Class 760 The aggregate elements that constitute the RIDPolicy class are as 761 follows: 763 Node 765 One. The Node class is used to identify a host or network device, 766 in this case to identify the system communicating RID messages. 767 The base definition of this class is reused from the IODEF 768 specification [RFC5070], Section 3.16. 770 IncidentID 772 Zero or one. Global reference pointing back to the IncidentID 773 defined in the IODEF data model. The IncidentID includes the name 774 of the CSIRT, an incident number, and an instance of that 775 incident. The instance number is appended with a dash separating 776 the values and is used in cases for which it may be desirable to 777 group incidents. Examples of incidents that may be grouped 778 include botnets, polymorphic attacks, DDoS attacks, multiple hops 779 of compromised systems found during an investigation, etc. 781 PolicyRegion 782 One or many. REQUIRED. The values for the attribute "region" are 783 used to determine what policy area may require consideration 784 before a trace can be approved. The PolicyRegion may include 785 multiple selections from the attribute list in order to fit all 786 possible policy considerations when crossing regions, consortiums, 787 or networks. 789 region 791 Required. ENUM. The attribute region is used to identify the 792 expected sharing range of the incident information. The region 793 may be within a region or defined by existing relationships such 794 as those of a consortium or client to service provider. 796 1. ClientToSP. A client initiated the request to their service 797 provider (SP). A client may be an individual, enterprise, or 798 other type of entity (government, commercial, education, 799 etc.). A service provider may be a network, 800 telecommunications, cloud, infrastructure, or other type of 801 service provider where a client to vendor relationship has 802 been established. The client to vendor relationship will 803 typically have established contracts or agreements to define 804 expectations and trust relationships. 806 2. SPToClient. A service provider (SP) initiated a RID request 807 or report to a client. A client may be an individual, 808 enterprise, or other type of entity (government, commercial, 809 education, etc.). A service provider may be a network, 810 telecommunications, cloud, infrastructure, or other type of 811 service provider where a client to vendor relationship has 812 been established. The client to vendor relationship will 813 typically have established contracts or agreements to define 814 expectations and trust relationships. 816 3. IntraConsortium. Incident information that should have no 817 restrictions within the boundaries of a consortium with the 818 agreed-upon use and abuse guidelines. A consortium is a well 819 defined group with established members and trust relationships 820 specific to sharing within that group. A consortium would 821 typically define the types of data that can be shared in 822 advance, expectations on protecting that data, as well as 823 having established contractual agreements. Examples of 824 Consortiums may include industry focused sharing communities 825 (Financial, government, research and education, etc.) or cross 826 industry sharing communities (for instance, organizations 827 within local proximity that form a sharing group). 829 4. PeerToPeer. Incident information that should have no 830 restrictions between two peers but may require further 831 evaluation before continuance beyond that point with the 832 agreed-upon use and abuse guidelines. PeerToPeer 833 communications may involve any two individuals or entities 834 that decide to share information directly with each other. 836 5. BetweenConsortiums. Incident information that should have no 837 restrictions between consortiums that have established agreed- 838 upon use and abuse guidelines. BetweenConsortiums is used 839 when two Consortiums (as defined in IntraConsortium above) 840 share data. The types of data that can be shared 841 BetweenConsortiums should be identified in their agreements 842 and contracts along with expectations on how that data should 843 be handled and protected. 845 6. AcrossNationalBoundaries. This selection must be set if the 846 message type will cross national boundaries. 847 AcrossNationalBoundaries is used when data shared may have 848 additional restrictions for handling and protection based on 849 the type of data and where it resides. The IODEF document 850 included, as well as any extensions, with the RID message 851 should indicate the specific restrictions to be considered. 852 The national boundary may be defined by existing regulations 853 or other legal agreements specific to a defined region. The 854 use of this AcrossNationalBoundaries is not legally binding 855 unless contracts and agreements for entities who share data 856 have deemed it as such through additional definitions that may 857 include associated handling and protection requirements. 858 There could be instances of TraceRequest messages where that 859 may not be known in advance, but should be known at the 860 instance where boundaries are crossed during the 861 investigation. This must also be set if the security 862 requirements of the request is based upon regulations of a 863 specific nation that may not apply to all nations. The 864 stricter requirements should be upheld. This is different 865 from the "BetweenConsortiums" setting since it may be possible 866 to have multiple nations as members of the same consortium, 867 and this option must be selected if the traffic is of a type 868 that may have different restrictions in other nations. 870 7. LawEnforcement. This option is used when incident information 871 is exchanged with LawEnforcement, local government, or other 872 authorities assisting with an investigation. The usage of 873 this value is interpreted by the sender, and that 874 interpretation may vary in regions of the world. This value 875 is intentionally broad. More detailed information on the 876 receiving entity is maintained in the Contact class of the 877 IODEF document. If the law enforcement agency resides within 878 a different nation that the sending entity, the 879 "AcrossNationalBoundaries" enumeration MUST also be set. 881 8. ext-value. An escape value used to extend this attribute. 882 See IODEF [RFC5070], Section 5.1. 884 TrafficType 886 One or many. REQUIRED. The values for the attribute "type" are 887 meant to assist in determining if a trace is appropriate for the 888 SP (provider) receiving the request to continue the trace. 889 Multiple values may be selected for this element; however, where 890 possible, it should be restricted to one value that most 891 accurately describes the traffic type. 893 type 895 REQUIRED. ENUM. The attribute type is used to identify the type 896 of information included in the RID message or the type of 897 incident. 899 1. Attack. This option should only be selected if the traffic is 900 related to a information security incident or attack. The 901 type of attack MUST also be listed in more detail in the IODEF 902 Method and Impact classes for further clarification to assist 903 in determining if the trace can be continued ([RFC5070], 904 Sections 3.9 and 3.10.1). 906 2. Network. This option MUST only be selected when the trace is 907 related to network traffic or routing issues. 909 3. Content. This category MUST be used only in the case in which 910 the request is related to the content and regional 911 restrictions on accessing that type of content exist. This is 912 not malicious traffic but may include determining what sources 913 or destinations accessed certain materials available on the 914 Internet, including, but not limited to, news, technology, or 915 inappropriate content. 917 4. OfficialBusiness. This option MUST be used if the incident 918 information is requested by or affiliated with any government 919 or other official business request. This could be used during 920 an investigation by government authorities or other government 921 incident investigations to track suspected criminal or other 922 activities. 924 5. Other. If this option is selected, a description of the 925 traffic type MUST be provided so that policy decisions can be 926 made to continue or stop the investigation. The information 927 should be provided in the IODEF message in the Expectation 928 class or in the History class using a HistoryItem log. This 929 may also be used for incident types other than information 930 security related incidents. 932 6. ext-value. An escape value used to extend this attribute. 933 See IODEF [RFC5070], Section 5.1. 935 The RIDPolicy class has five attributes: 937 restriction 939 OPTIONAL. ENUM. This attribute indicates the disclosure 940 guidelines to which the sender expects the recipient to adhere. 941 This guideline provides no real security since it is the choice 942 of the recipient of the document to honor it. This attribute 943 follows the same guidelines as "restriction" used in IODEF. 945 MsgType 947 REQUIRED. ENUM. The type of RID message sent. The six types 948 of messages are described in Section 3.5 and can be noted as 949 one of the six selections below. 951 2. TraceRequest. This message may be used to initiate a 952 TraceRequest or to continue a TraceRequest to an upstream 953 network closer to the source address of the origin of the 954 security incident. 956 3. RequestAuthorization. This message is sent to the initiating 957 RID system from each of the upstream RID systems to provide 958 information on the request status in the current network. 960 4. Result. This message indicates that the source of the attack 961 was located and the message is sent to the initiating RID 962 system through the RID systems in the path of the trace. 964 5. Investigation. This message type is used when the source of 965 the traffic is believed to be valid. The purpose of the 966 Investigation request is to leverage the existing peer or 967 consortium relationships in order to notify the network or 968 service provider closest to the source of the valid traffic 969 that some event occurred, which may be a security-related 970 incident. 972 6. Report. This message is used to report a security incident, 973 for which no action is requested in the IODEF Expectation 974 class. This may be used for the purpose of correlating attack 975 information by CSIRTs, statistics and trending information, 976 etc. 978 7. IncidentQuery. This message is used to request information 979 from a trusted RID system about an incident or incident type. 981 Additionally, there is an extension attribute to add new 982 enumerated values: 984 ext-value. An escape value used to extend this attribute. See 985 IODEF [RFC5070], Section 5.1. 987 MsgDestination 989 REQUIRED. ENUM. The destination required at this level may 990 either be the RID messaging system intended to receive the 991 request, or, in the case of an Investigation request, the 992 source of the incident. In the case of an Investigation 993 request, the RID system that can help stop or mitigate the 994 traffic may not be known, and the message may have to traverse 995 RID messaging systems by following the routing path to the RID 996 system closest to the source of the attack traffic. The Node 997 element lists either the RID system or the IP address of the 998 source, and the meaning of the value in the Node element is 999 determined by the MsgDestination element. 1001 1. RIDSystem. The address listed in the Node element of the 1002 RIDPolicy class is the next upstream RID system that will 1003 receive the RID message. 1005 2. SourceOfIncident. The address listed in the Node element 1006 of the RIDPolicy class is the incident source. The IP 1007 address is used to determine the path of systems accepting 1008 RID communications that will be used to find the closest 1009 RID system to the source of an attack in which the IP 1010 address used by the source is believed to be valid and an 1011 Investigation request message is used. This is not to be 1012 confused with the IncidentSource class, as the defined 1013 value here is from an initial trace or Investigation 1014 request, not the source used in a Result message. 1016 3. ext-value. An escape value used to extend this attribute. 1017 See IODEF [RFC5070], Section 5.1. 1019 MsgType-ext 1021 OPTIONAL. STRING. A means by which to extend the MsgType 1022 attribute. See IODEF [RFC5070], Section 5.1. 1024 MsgDestination-ext 1026 OPTIONAL. STRING. A means by which to extend the 1027 MsgDestination attribute. See IODEF [RFC5070], Section 5.1 1029 4.2. RequestStatus 1031 The RequestStatus class is an aggregate class in the RID class. 1033 +--------------------------------+ 1034 | RequestStatus | 1035 +--------------------------------+ 1036 | | 1037 | ENUM restriction | 1038 | ENUM AuthorizationStatus | 1039 | ENUM Justification | 1040 | STRING ext-AuthorizationStatus | 1041 | STRING ext-Justification | 1042 | | 1043 +--------------------------------+ 1045 Figure 5: The RequestStatus Class 1047 The RequestStatus class has five attributes: 1049 restriction 1051 OPTIONAL. ENUM. This attribute indicates the disclosure 1052 guidelines to which the sender expects the recipient to adhere. 1053 This guideline provides no real security since it is the choice 1054 of the recipient of the document to honor it. This attribute 1055 follows the same guidelines as "restriction" used in IODEF. 1057 AuthorizationStatus 1059 REQUIRED. ENUM. The listed values are used to provide a 1060 response to the requesting CSIRT of the status of a 1061 TraceRequest in the current network. 1063 1. Approved. The trace was approved and will begin in the 1064 current SP. 1066 2. Denied. The trace was denied in the current SP. The next 1067 closest SP can use this message to filter traffic from the 1068 upstream SP using the example packet to help mitigate the 1069 effects of the attack as close to the source as possible. 1070 The RequestAuthorization message must be passed back to the 1071 originator and a Result message used from the closest SP to 1072 the source to indicate actions taken in the IODEF History 1073 class. 1075 3. Pending. Awaiting approval; a timeout period has been 1076 reached, which resulted in this Pending status and 1077 RequestAuthorization message being generated. 1079 4. ext-value. An escape value used to extend this attribute. 1080 See IODEF [RFC5070], Section 5.1. 1082 Justification 1084 OPTIONAL. ENUM. Provides a reason for a Denied or Pending 1085 message. 1087 2. SystemResource. A resource issue exists on the systems 1088 that would be involved in the request. 1090 3. Authentication. The enveloped digital signature [RFC3275] 1091 failed to validate. 1093 4. AuthenticationOrigin. The detached digital signature for 1094 the original requestor on the RecordItem entry failed to 1095 validate. 1097 5. Encryption. Unable to decrypt the request. 1099 6. Other. There were other reasons this request could not be 1100 processed. 1102 7. ext-value. An escape value used to extend this attribute. 1103 See IODEF [RFC5070], Section 5.1. 1105 AuthorizationStatus-ext 1107 OPTIONAL. STRING. A means by which to extend the 1108 AuthorizationStatus attribute. See IODEF [RFC5070], Section 1109 5.1. 1111 Justification-ext 1112 OPTIONAL. STRING. A means by which to extend the 1113 Justification attribute. See IODEF [RFC5070], Section 5.1. 1115 4.3. IncidentSource 1117 The IncidentSource class is an aggregate class in the RID class. 1119 +-------------------+ 1120 | IncidentSource | 1121 +-------------------+ 1122 | | 1123 | ENUM restriction | 1124 | |<>-------------[ SourceFound ] 1125 | | 1126 | |<>---{0..*}----[ Node ] 1127 | | 1128 +-------------------+ 1130 Figure 6: The IncidentSource Class 1132 The elements that constitute the IncidentSource class follow: 1134 SourceFound 1136 One. BOOLEAN. The Source class indicates if a source was 1137 identified. If the source was identified, it is listed in the 1138 Node element of this class. 1140 True. Source of incident was identified. 1142 False. Source of incident was not identified. 1144 Node 1146 One. The Node class is used to identify a host or network 1147 device, in this case to identify the system communicating RID 1148 messages. 1150 The base definition of this class is reused from the IODEF 1151 specification [RFC5070], Section 3.16. 1153 The IncidentSource class has one attribute: 1155 restriction 1157 OPTIONAL. ENUM. This attribute indicates the disclosure 1158 guidelines to which the sender expects the recipient to adhere. 1159 This guideline provides no real security since it is the choice 1160 of the recipient of the document to honor it. This attribute 1161 follows the same guidelines as "restriction" used in IODEF. 1163 4.4. RID Name Spaces 1165 The RID schema declares a namespace of "iodef-rid-1.1" and registers 1166 it per [XMLNames]. Each IODEF-RID document MUST use the 1167 "iodef-rid-1.1" namespace in the top-level element RID-Document. It 1168 can be referenced as follows: 1170 1175 5. RID Messages 1177 The IODEF model is followed as specified in [RFC5070] for each of the 1178 RID message types. The RID schema is used in combination with IODEF 1179 documents to facilitate RID communications. Each message type varies 1180 slightly in format and purpose; hence, the requirements vary and are 1181 specified for each. All classes, elements, attributes, etc., that 1182 are defined in the IODEF-Document are valid in the context of a RID 1183 message; however, some listed as optional in IODEF are mandatory for 1184 RID as listed for each message type. The IODEF model MUST be fully 1185 implemented to ensure proper parsing of all RID messages. 1187 Note: The implementation of RID may automate the ability to fill in 1188 the content required for each message type from packet input, 1189 incident data, situational awareness information, or default values 1190 such as that used in the EventData class. 1192 5.1. TraceRequest 1194 Description: This message or document is sent to the network 1195 management station next in the upstream trace once the upstream 1196 source of the traffic has been identified. The following information 1197 is required for TraceRequest messages and is provided through: 1199 RID Information: 1201 RIDPolicy 1203 RID message type, IncidentID, and destination policy 1204 information 1206 IODEF Information: 1208 Time Stamps (DetectTime, StartTime, EndTime, ReportTime). 1210 Incident Identifier (Incident class, IncidentID). 1212 Confidence rating of security incident (Impact and Confidence 1213 class). 1215 System class is used to list both the Source and Destination. 1217 Expectation class should be used to request any specific actions 1218 to be taken close to the source. 1220 Path information of nested RID systems, beginning with the request 1221 originator used in the trace using IODEF EventData with category 1222 set to "infrastructure". 1224 Event, Record, and RecordItem classes to include example packets 1225 and other information related to the incident. Note: Event 1226 information included here requires a second instance of EventData 1227 in addition to that used to convey service/network provider (SP) 1228 path contact information. 1230 Standards for encryption and digital signatures [RFC3275], [XMLsig]: 1232 Digital signature from initiating CSIRT or provider system sending 1233 the RID message, passed to all systems in upstream trace using a 1234 detached XML digital signature on a RecordItem entry. 1236 Digital signature of sending CSIRT or SP for authenticity of the 1237 RID message, from the CSIRT or provider creating this message 1238 using an enveloped XML digital signature on the IODEF document. 1240 XML encryption as required by policy, agreements, and data 1241 markers. 1243 A DDoS attack can have many sources, resulting in multiple traces to 1244 locate the sources of the attack. It may be valid to continue 1245 multiple traces for a single attack. The path information enables 1246 the administrators to determine if the exact trace had already passed 1247 through a single network. The Incident Identifier must also be used 1248 to identify multiple TraceRequests from a single incident. If a 1249 single TraceRequest results in divergent paths of TraceRequests, a 1250 separate instance number MUST be used under the same IncidentID. The 1251 IncidentID instance number of IODEF can be used to correlate related 1252 incident data that is part of a larger incident. 1254 5.2. RequestAuthorization 1256 Description: This message is sent to the initiating RID system from 1257 the next upstream provider's application or system designated for 1258 accepting RID communications to provide information on the request 1259 status in the current network. 1261 The following information is required for RequestAuthorization 1262 messages and is provided through: 1264 RID Information: 1266 RIDPolicy 1268 RID message type, IncidentID, and destination policy 1269 information 1271 RequestStatus class: 1273 Status of TraceRequest 1275 Standards for encryption and digital signatures [RFC3275], [XMLsig]: 1277 Digital signature of responding CSIRT or provider for authenticity 1278 of Trace Status Message, from the CSIRT or provider creating this 1279 message using an enveloped XML digital signature. 1281 XML encryption as required by policy, agreements, and data 1282 markers. 1284 A message is sent back to the initiating CSIRT or provider's system 1285 accepting RID communications of the trace as status notification. 1286 This message verifies that the next RID system in the path has 1287 received the message from the previous system in the path. This 1288 message also verifies that the trace is now continuing, has stopped, 1289 or is pending in the next upstream CSIRT or provider's RID system. 1290 The Pending status is automatically generated after a 2-minute 1291 timeout without system-predefined or administrator action taken to 1292 approve or disapprove the trace continuance. If a Request is denied, 1293 the originator and sending peer (if they are not the same) MUST both 1294 receive the message. This enables the sending peer the option to 1295 take action to stop or mitigate the traffic as close to the source as 1296 possible. 1298 5.3. Result 1300 Description: This message indicates that the trace or investigation 1301 has been completed and provides the result. The Result message 1302 includes information on whether or not a source was found and the 1303 source information through the IncidentSource class. The Result 1304 information MUST go back to the originating RID system that began the 1305 investigation or trace. An provider may use any number of incident 1306 handling data sources to ascertain the true source of an attack. All 1307 of the possible information sources may or may not be readily tied 1308 into the RID communications system. 1310 The following information is required for Result messages and will be 1311 provided through: 1313 RID Information: 1315 RIDPolicy 1317 RID message type, IncidentID, and destination policy 1318 information 1320 Incident Source 1322 The IncidentSource class of the RID schema is used to note 1323 if a source was identified and provide the source 1324 address(es). 1326 IODEF Information: 1328 Time Stamps (DetectTime, StartTime, EndTime, ReportTime). 1330 Incident Identifier (Incident class, IncidentID). 1332 Trace number - used for multiple traces of a single 1333 incident; must be noted. 1335 Confidence rating of security incident (Impact and Confidence 1336 class). 1338 System class is used to list both the Source and Destination 1339 Information used in the attack and must note if the traffic is 1340 spoofed, thus requiring an upstream TraceRequest in RID. 1342 History class "atype" attribute is used to note any actions 1343 taken. 1345 History class also notes any other background information 1346 including notes about the confidence level or rating of the 1347 result information. 1349 Path information of nested RID systems, beginning with the 1350 request originator used in the trace using IODEF EventData with 1351 category set to "infrastructure". The last SP listed is the SP 1352 that located the source of the traffic (the provider sending 1353 the Result message). 1355 Event, Record, and RecordItem classes to include example 1356 packets and other information related to the incident 1357 (optional). Note: Event information included here requires a 1358 second instance of EventData in addition to that used to convey 1359 SP path contact information. 1361 Standards for encryption and digital signatures [RFC3275]: 1363 Digital signature of source CSIRT or provider for authenticity 1364 of Result message, from the CSIRT or provider creating this 1365 message using an enveloped XML digital signature. 1367 XML encryption as required by policy, agreements, and data 1368 markers. 1370 A message is sent back to the initiating CSIRT or provider's RID 1371 system to notify the CSIRT that the source has been located. The 1372 actual source information may or may not be included, depending on 1373 the policy of the network in which the client or host is attached. 1374 Any action taken by the SP to act upon the discovery of the source of 1375 a trace should be included. The SP may be able to automate the 1376 adjustment of filters at their border router to block outbound access 1377 for the machine(s) discovered as a part of the attack. The filters 1378 may be comprehensive enough to block all Internet access until the 1379 host has taken the appropriate action to resolve any security issues 1380 or to rate-limit the ingress traffic as close to the source as 1381 possible. 1383 Security and privacy requirements discussed in Section 8 MUST be 1384 taken into account. 1386 Note: The History class has been expanded in IODEF to accommodate all 1387 of the possible actions taken as a result of a RID TraceRequest or 1388 Investigation request using the "iodef:atype", or action type, 1389 attribute. The History class should be used to note all actions 1390 taken close to the source of a trace or incident using the most 1391 appropriate option for the type of action along with a description. 1392 The "atype" attribute in the Expectation class can also be used to 1393 request an appropriate action when a TraceRequest or Investigation 1394 request is made. 1396 5.4. Investigation Request 1398 Description: This message type is used when the source of the traffic 1399 is believed not to be spoofed. The purpose of the Investigation 1400 request message is to leverage the existing bilateral peer 1401 relationships in order to notify the network provider closest to the 1402 source of the valid traffic that some event occurred, which may be a 1403 security-related incident. 1405 The following information is required for Investigation request 1406 messages and is provided through: 1408 RID Information: 1410 RID Policy 1412 RID message type, IncidentID, and destination policy 1413 information 1415 IODEF Information: 1417 Time Stamps (DetectTime, StartTime, EndTime, ReportTime). 1419 Incident Identifier (Incident class, IncidentID). 1421 Trace number - used for multiple traces of a single 1422 incident; must be noted. 1424 Confidence rating of security incident (Impact and Confidence 1425 class). 1427 System class is used to list both the Source and Destination 1428 Information used in the attack and must note if the traffic is 1429 spoofed, thus requiring an upstream TraceRequest in RID. 1431 Expectation class should be used to request any specific 1432 actions to be taken close to the source. 1434 Path information of nested systems communicating via RID 1435 messages, beginning with the request originator used in the 1436 trace using IODEF EventData with category set to 1437 "infrastructure". 1439 Event, Record, and RecordItem classes to include example 1440 packets and other information related to the incident. Note: 1441 Event information included here requires a second instance of 1442 EventData in addition to that used to convey SP path contact 1443 information. 1445 Standards for encryption and digital signatures [RFC3275]: 1447 Digital signature from initiating system sending the RID 1448 message, passed to all systems involved in the investigation 1449 using a detached XML digital signature on a RecordItem entry. 1451 Digital signature of sending CSIRT or SP for authenticity of 1452 the RID message, from the CSIRT or provider sending this 1453 message using an enveloped XML digital signature on the IODEF 1454 document. 1456 XML encryption as required by policy, agreements, and data 1457 markers. 1459 Security requirements include the ability to encrypt [XMLencrypt] the 1460 contents of the Investigation request message using the public key of 1461 the destination RID system. The incident number increases as if it 1462 were a TraceRequest message in order to ensure uniqueness within the 1463 system. The relaying peers also append their Autonomous System (AS) 1464 or RID system information as the request message was relayed along 1465 the web of network providers so that the Result message could utilize 1466 the same path as the set of trust relationships for the return 1467 message, thus indicating any actions taken. The request is recorded 1468 in the state tables of both the initiating and destination SP RID 1469 systems. The destination SP is responsible for any actions taken as 1470 a result of the request in adherence to any service level agreements 1471 or internal policies. The SP MUST confirm that the traffic actually 1472 originated from the suspected system before taking any action and 1473 confirm the reason for the request. The request may be sent directly 1474 to a known RID system or routed by the source address of the attack 1475 using the message destination of RIDPolicy, SourceOfIncident. Note: 1476 All intermediate parties MUST be able to view RIDPolicy information 1477 in order to properly direct RID messages. 1479 5.5. Report 1481 Description: This message or document is sent to a RID system to 1482 provide a report of a security incident. This message does not 1483 require any actions to be taken, except to file the report on the 1484 receiving RID system or associated database. 1486 The following information is required for Report messages and will be 1487 provided through: 1489 RID Information: 1491 RID Policy RID message type, IncidentID, and destination policy 1492 information 1494 The following data is recommended if available and can be provided 1495 through: 1497 IODEF Information: 1499 Time Stamps (DetectTime, StartTime, EndTime, ReportTime). 1501 Incident Identifier (Incident class, IncidentID). Trace number 1502 - used for multiple traces of a single incident; must be noted. 1504 Confidence rating of security incident (Impact and Confidence 1505 class). 1507 System class is used to list both the Source and Destination 1508 Information used in the attack. 1510 Event, Record, and RecordItem classes to include example 1511 packets and other information related to the incident 1512 (optional). 1514 Standards for encryption and digital signatures [RFC3275]: 1516 Digital signature from initiating RID system, passed to all 1517 systems receiving the report using an enveloped XML digital 1518 signature. 1520 XML encryption as required by policy, agreements, and data 1521 markers. 1523 Security requirements include the ability to encrypt [XMLencrypt] the 1524 contents of the Report message using the public key of the 1525 destination RID system. Senders of a Report message should note that 1526 the information may be used to correlate security incident 1527 information for the purpose of trending, pattern detection, etc., and 1528 may be shared with other parties unless otherwise agreed upon with 1529 the receiving RID system. Therefore, sending parties of a Report 1530 message may obfuscate or remove destination addresses or other 1531 sensitive information before sending a Report message. A Report 1532 message may be sent either to file an incident report or in response 1533 to an IncidentQuery, and data sensitivity must be considered in both 1534 cases. The SP path information is not necessary for this message, as 1535 it will be communicated directly between two trusted RID systems. 1537 5.6. IncidentQuery 1539 Description: The IncidentQuery message is used to request incident 1540 information from a trusted RID system. The request can include the 1541 incident number, if known, or detailed information about the 1542 incident. If the incident number is known, the Report message 1543 containing the incident information can easily be returned to the 1544 trusted requestor using automated methods. If an example packet or 1545 other unique information is included in the IncidentQuery, the return 1546 report may be automated; otherwise, analyst intervention may be 1547 required. 1549 The following information must be used for an IncidentQuery message 1550 and is provided through: 1552 RID Information: 1554 RID Policy 1556 RID message type, IncidentID, and destination policy 1557 information 1559 IODEF Information (optional): 1561 Time Stamps (DetectTime, StartTime, EndTime, ReportTime). 1563 Incident Identifier (Incident class, IncidentID). 1565 Trace number - used for multiple traces of a single 1566 incident; must be noted. 1568 Confidence rating of security incident (Impact and Confidence 1569 class). 1571 System class is used to list both the Source and Destination 1572 Information used in the attack. 1574 Event, Record, and RecordItem classes to include example 1575 packets and other information related to the incident 1576 (optional). 1578 Standards for encryption and digital signatures [RFC3275]: 1580 Digital signature from the CSIRT or SP initiating the RID 1581 message, passed to all systems receiving the IncidentQuery 1582 using an enveloped XML digital signature. 1584 XML encryption as required by policy, agreements, and data 1585 markers. 1587 The proper response to the IncidentQuery message is a Report message. 1588 Multiple incidents may be returned for a single query if an incident 1589 type is requested. In this case, the receiving system sends an IODEF 1590 document containing multiple incidents or all instances of an 1591 incident. The system sending the reply may pre-set a limit to the 1592 number of documents returned in one report. The recommended limit is 1593 5, to prevent the documents from becoming too large. Other transfer 1594 methods may be suited better than RID for large transfers of data. 1595 The Confidence rating may be used in the IncidentQuery message to 1596 select only incidents with an equal or higher Confidence rating than 1597 what is specified. This may be used for cases when information is 1598 gathered on a type of incident but not on specifics about a single 1599 incident. Source and Destination Information may not be needed if 1600 the IncidentQuery is intended to gather data about a specific type of 1601 incident as well. 1603 6. RID Communication Exchanges 1605 The following section outlines the communication flows for RID and 1606 also provides examples of messages. 1608 Note: For each example listed below, [RFC5735] addresses were used. 1609 Assume that each IP address listed is actually a separate network 1610 range held by different SPs. Addresses were used from /27 network 1611 ranges. 1613 6.1. Upstream Trace Communication Flow 1615 The diagram below outlines the RID TraceRequest communication flow 1616 between RID systems on different networks tracing an attack. SP-1, 1617 SP-2, SP-3 represent service or network providers that are involved 1618 in the example trace communication flow. 1620 Attack Dest SP-1 SP-2 SP-3 Attack Src 1622 1. Attack | Attack 1623 reported | detected 1625 2. Initiate trace 1627 3. Locate origin 1628 through 1629 upstream SP 1631 4. o---TraceRequest-----> 1633 5. Trace 1634 Initiated 1636 6. <-RequestAuthorization-o 1638 7. Locate origin 1639 through 1640 upstream SP 1642 8. o---TraceRequest---> 1644 9. Trace Initiated 1646 10. <----------RequestAuthorization----o 1647 <---RequestAuth---o 1649 11. Locate attack 1650 source on network X 1652 12. <------------Result----------------o 1654 Figure 7: TraceRequest Communication Flow 1656 Before a trace is initiated, the RID system should verify if an 1657 instance of the trace or a similar request is not active. The traces 1658 may be resource intensive; therefore, providers need to be able to 1659 detect potential abuse of the system or unintentional resource 1660 drains. Information such as the Source and Destination Information, 1661 associated packets, and the incident may be desirable to maintain for 1662 a period of time determined by administrators. 1664 The communication flow demonstrates that a RequestAuthorization 1665 message is sent to both the downstream peer and the original 1666 requestor. If a TraceRequest is denied, the downstream peer has the 1667 option to take an action and respond with a Result message. The 1668 originator of the request may follow up with the downstream peer of 1669 the SP involved using an Investigation request to ensure that an 1670 action is taken if no response is received. Nothing precludes the 1671 originator of the request from initiating a new TraceRequest 1672 bypassing the SP that denied the request, if a trace is needed beyond 1673 that point. Another option may be for the initiator to send an 1674 Investigation request to an SP upstream of the SP that denied the 1675 request if enough information was gathered to discern the true source 1676 of the attack traffic from the incident handling information. 1678 The proper response to a TraceRequest is a RequestAuthorization 1679 message. The RequestAuthorization message lets the requestor know if 1680 the trace will continue through the next upstream network. If there 1681 is a problem with the request, such as a failure to validate the 1682 digital signature or decrypt the request, a RequestAuthorization 1683 message MUST be sent to the requestor and the downstream peer (if 1684 they are not one and the same) providing the reason why the message 1685 could not be processed. Assuming that the trace continued, 1686 additional TraceRequests with the response of a RequestAuthorization 1687 message would occur passing the request upstream in the path to the 1688 source of the traffic related to the incident. Once a source is 1689 found, a Result message is sent to the originator of the trace, as 1690 determined by the SP path information provided through the document 1691 instance of EventData, where contact is set to "infrastructure". The 1692 SP path information is also used when sending the 1693 RequestAuthorization messages to the first entry (the trace 1694 originator) and the last nested entry (the downstream peer). The 1695 Result message is encrypted [XMLencrypt] for the originator providing 1696 information about the incident source and any actions taken. If the 1697 originator fails to decrypt or authenticate the Result message, a 1698 RequestAuthorization message is sent in response; otherwise, no 1699 return message is sent. If a RequestAuthorization message is sent 1700 with the RequestStatus set to Denied, a downstream peer receiving 1701 this message may choose to take action to stop or mitigate the 1702 traffic at that point in the network, as close to the source as 1703 possible. If the downstream peer chooses this option, it would send 1704 a Result message to the trace originator. 1706 6.1.1. RID TraceRequest Example 1708 The example listed is of a TraceRequest based on the incident report 1709 example from the IODEF document. The RID extension classes were 1710 included as appropriate for a TraceRequest message using the 1711 RIDPolicy class. The example given is that of a CSIRT reporting a 1712 DoS attack in progress to the upstream SP. The request asks the next 1713 SP to continue the trace and have the traffic mitigated closer to the 1714 source of the traffic. The example TraceRequest message is the first 1715 step of a TraceRequest as depicted in the previous diagram, where 1716 'Attack Dest' is represented by 192.0.2.67 (and SP-1). The "Attack 1717 Src' is later identified in the Result message example as 192.0.2.37 1718 and initially as tracing closer to 192.0.2.35. 'SP-1' is identified 1719 in the TraceRequest as CSIRT-FOR-OUR-DOMAIN, and 'SP-2' is identified 1720 in the RID document for the TraceRequest as the 'RIDSystem' in 1721 'MsgDestination' as 192.0.2.3 using the Node class. SP-3 is later 1722 used in the Result message and the administrator is identified as 1723 'Admin-contact@10.1.1.2' as they searched for 192.0.2.35, the 1724 administrator may be different than the constituency contact (an 1725 additional TraceRequest occurred between SP-2 to SP-3 that is not 1726 included). SP-3 is the service provider for 192.0.2.32/27 and was 1727 able to take the action to rate-limit their traffic. The SP-1, SP-2, 1728 and SP-3 information would be replaced with the appropriate (and 1729 valid) email and other contact information in real usages. The Node 1730 class allows for the use of a fully qualified domain or the IP 1731 address to be provided for the SP. Any mapping of existing 1732 relationships from the SP Node information to the name, contact, 1733 digital signature verification information and other identifying or 1734 trust information is provided at the application layer to support end 1735 users of the incident management system. A packet is provided in 1736 this example to enable any traces to be performed by SP-2 and SP-3 to 1737 perform traces to the attack source before taking the requested 1738 action to 'rate-limit' the traffic. The subnet of 192.0.2.0uses a 27 1739 bit mask in the examples below. 1741 In the following example, use of [XMLsig] to generate digital 1742 signatures used SHA-1 following the guidance of [XMLsig] 1.0. 1743 Version 1.1 of [XMLsig] supports additional digest algorithms. 1745 1747 1749 1750 1751 192.0.2.3 1752 1753 1754 1755 CERT-FOR-OUR-DOMAIN#207-1 1756 1757 1758 1760 1762 1764 1765 1766 CERT-FOR-OUR-DOMAIN#207-1 1767 1768 2004-02-02T22:49:24+00:00 1769 2004-02-02T22:19:24+00:00 1770 2004-02-02T23:20:24+00:00 1771 Host involved in DoS attack 1772 1773 1774 1775 1776 Constituency-contact for 192.0.2.35 1777 1778 Constituency-contact@192.0.2.35 1779 1780 1781 1782 1783 1784 192.0.2.35 1785 1786 1787 1788 38765 1789 1790 1791 1792 1793 192.0.2.67 1794 1795 1796 1797 80 1798 1799 1800 1801 1802 1803 Rate-limit traffic close to source 1804 1805 1806 1807 1808 1809 The IPv4 packet included was used in the described attack 1810 1811 450000522ad9 1812 0000ff06c41fc0a801020a010102976d0050103e020810d9 1813 4a1350021000ad6700005468616e6b20796f7520666f7220 1814 6361726566756c6c792072656164696e6720746869732052 1815 46432e0a 1816 1817 1818 1819 1820 1821 1822 2001-09-14T08:19:01+00:00 1823 1824 CSIRT-FOR-OUR-DOMAIN#207-1 1825 1826 1827 Notification sent to next upstream SP closer to 192.0.2.35 1828 1829 1830 1831 1832 1834 1836 1839 1840 1841 1842 1843 1844 450000522ad9 1845 0000ff06c41fc0a801020a010102976d0050103e020810d9 1846 4a1350021000ad6700005468616e6b20796f7520666f7220 1847 6361726566756c6c792072656164696e6720746869732052 1848 46432e0a 1849 1850 1851 1852 1853 1854 1855 1856 1857 1860 1862 1863 1864 1866 1867 1869 KiI5+6SnFAs429VNwsoJjHPplmo= 1870 1871 1872 1873 VvyXqCzjoW0m2NdxNeToXQcqcSM80W+JMW+Kn01cS3z3KQwCPeswzg== 1874 1875 1876 1877 1878

/KaCzo4Syrom78z3EQ5SbbB4sF7ey80etKII864WF64B81uRpH5t9j 1879 QTxeEu0ImbzRMqzVDZkVG9xD7nN1kuFw==

1880 li7dzDacuo67Jg7mtqEm2TRuOMU= 1881 Z4Rxsnqc9E7pGknFFH2xqaryRPBaQ01khpMdLRQnG541Awtx/XPaF5 1882 Bpsy4pNWMOHCBiNU0NogpsQW5QvnlMpA== 1883 VFWTD4I/aKni4YhDyYxAJozmj1iAzPLw9Wwd5B+Z9J5E7lHjcAJ+bs 1884 HifTyYdnj+roGzy4o09YntYD8zneQ7lw== 1885 1886 1887 1888 1889 1891 6.1.2. RequestAuthorization Message Example 1893 The example RequestAuthorization message is in response to the 1894 TraceRequest message listed above. The SP that received the request 1895 is responding to approve the trace continuance in their network. 1897 1899 1901 1902 1903 192.0.2.67 1904 1905 1906 1907 CERT-FOR-OUR-DOMAIN#207-1 1908 1909 1910 1911 1913 6.1.3. Result Message Example 1915 The example Result message is in response to the TraceRequest listed 1916 above. This message type only comes after a RequestAuthorization 1917 within the TraceRequest flow of messages. It may be a direct 1918 response to an Investigation request. This message provides 1919 information about the source of the attack and the actions taken to 1920 mitigate the traffic. 1922 1924 1926 1927 1928 192.0.2.67 1929 1930 1931 1932 CERT-FOR-OUR-DOMAIN#207-1 1933 1934 1935 1936 true 1937 1938 192.0.2.37 1939 1940 1941 1943 1944 1946 1947 1948 CERT-FOR-OUR-DOMAIN#207-1 1949 1950 2004-02-02T22:49:24+00:00 1951 2004-02-02T22:19:24+00:00 1952 2004-02-02T23:20:24+00:00 1953 Host involved in DoS attack 1954 1955 1956 1957 1958 Constituency-contact for 192.0.2.35 1959 1960 Constituency-contact@192.0.2.35 1961 1962 1963 1964 Admin-contact for 192.0.2.35 1965 1966 Admin-contact@10.1.1.2 1967 1968 1969 1970 1971 192.0.2.35 1972 1973 1974 1975 1976 1977 1978 Admin-contact for 192.0.2.3 1979 1980 Admin-contact@192.0.2.3 1981 1982 1983 1984 1985 192.0.2.3 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 192.0.2.35 1997 1998 1999 2000 38765 2001 2002 2003 2004 2005 192.0.2.67 2006 2007 2008 2009 80 2010 2011 2012 2013 2014 2015 Rate-limit traffic close to source 2016 2017 2018 2019 2020 2021 The IPv4 packet included was used in the described attack 2022 2023 450000522ad9 2024 0000ff06c41fc0a801020a010102976d0050103e020810d9 2025 4a1350021000ad6700005468616e6b20796f7520666f7220 2026 6361726566756c6c792072656164696e6720746869732052 2027 46432e0a 2028 2029 2030 2031 2032 2033 2034 2004-02-02T22:53:01+00:00 2035 2036 CSIRT-FOR-OUR-DOMAIN#207-1 2037 2038 2039 Notification sent to next upstream SP closer to 192.0.2.35 2041 2042 2043 2044 2004-02-02T23:07:21+00:00 2045 2046 CSIRT-FOR-SP3#3291-1 2047 2048 2049 Host rate-limited for 24 hours 2050 2051 2052 2053 2054 2056 6.2. Investigation Request Communication Flow 2058 The diagram below outlines the RID Investigation request 2059 communication flow between RID systems on different networks for a 2060 security incident with a known source address. The proper response 2061 to an Investigation request is a Result message. If there is a 2062 problem with the request, such as a failure to validate the digital 2063 signature or decrypt the request, a RequestAuthorization message is 2064 sent to the requestor. The RequestAuthorization message should 2065 provide the reason why the message could not be processed. 2067 Attack Dest SP-1 SP-2 Attack Src 2069 1. Attack | Attack 2070 reported | detected 2072 2. Determine source 2073 of security incident 2075 3. o---Investigation----> 2077 4. Research 2078 incident and 2079 determine appropriate 2080 actions to take 2082 5. <-------Result-------o 2084 Figure 8: Investigation Communication Flow 2086 6.2.1. Investigation Request Example 2088 The following example only includes the RID-specific details. The 2089 IODEF and security measures are similar to the TraceRequest 2090 information, with the exception that the source is known and the 2091 receiving RID system is known to be close to the source. The source 2092 known is indicated in the IODEF document, which allows for incident 2093 sources to be listed as spoofed, if appropriate. 2095 This flow does not include a Result message as the request is denied 2096 as shown in the RequestAuthorization response. 2098 SP-1 is represented by CERT-FOR-OUR-DOMAIN and 192.0.2.67. SP-2 is 2099 identified by 192,0.2.98. In this example SP-2 is the service 2100 provider for systems on the 192.0.2.32/27 subnet. The contact for 2101 the host 192.0.2.35 is known at the start of the request as 2102 'Constituency-contact@10.1.1.2'. 2104 2106 2108 2109 2110 192.0.2.98 2111 2112 2113 2114 CERT-FOR-OUR-DOMAIN#208-1 2115 2116 2117 2119 2121 2123 2124 2125 CERT-FOR-OUR-DOMAIN#208-1 2126 2127 2004-02-05T08:13:33+00:00 2128 2004-02-05T08:13:31+00:00 2129 2004-02-05T08:13:33+00:00 2130 2004-02-05T08:13:35+00:00 2131 Host involved in DoS attack 2132 2133 2135 2136 2137 Constituency-contact for 192.0.2.35 2138 2139 Constituency-contact@10.1.1.2 2140 2141 2142 2143 2144 2145 192.0.2.35 2146 2147 2148 2149 41421 2150 2151 2152 2153 2154 192.0.2.67 2155 2156 2157 2158 80 2159 2160 2161 2162 2163 2164 Investigate whether source has been compromised 2165 2166 2167 2168 2169 2170 2004-02-05T08:19:01+00:00 2171 2172 CSIRT-FOR-OUR-DOMAIN#208-1 2173 2174 2175 Investigation request sent to SP for 192.0.2.35 2176 2177 2178 2179 2180 2182 6.2.2. RequestAuthorization Message Example 2184 The example RequestAuthorization message is in response to the 2185 Investigation request listed above. The SP that received the request 2186 was unable to validate the digital signature used to authenticate the 2187 sending RID system. 2189 2191 2193 2194 2195 192.0.2.67 2196 2197 2198 2199 CERT-FOR-OUR-DOMAIN#208-1 2200 2201 2202 2204 2206 6.3. Report Communication Flow 2208 The diagram below outlines the RID Report communication flow between 2209 RID systems on different networks. 2211 SP-1 SP-2 2213 1. Generate incident information 2214 and prepare Report message 2216 2. o-------Report-------> 2218 3. File report in database 2220 Figure 9: Report Communication Flow 2222 The Report communication flow is used to provide information on 2223 specific incidents detected on the network. Incident information may 2224 be shared between CSIRTs or participating RID hosts using this 2225 format. When a report is received, the RID system must verify that 2226 the report has not already been filed. The incident number and 2227 incident data, such as the hexadecimal packet and incident class 2228 information, can be used to compare with existing database entries. 2230 The Report message typically does not have a response. If there is a 2231 problem with the Report message, such as a failure to validate the 2232 digital signature [RFC3275] or decrypt the request, a 2233 RequestAuthorization message is sent to the requestor. The 2234 RequestAuthorization message should provide the reason why the 2235 message could not be processed. 2237 6.3.1. Report Example 2239 The following example only includes the RID-specific details. This 2240 report is an unsolicited Report message that includes an IPv4 packet. 2241 The IODEF document and digital signature is similar to the 2242 TraceRequest information. 2244 This example is a message sent from SP-1, CERT-FOR-OUR-DOMAIN at 2245 192.0.2.67, to SP-2 at 192.0.2.130 for informational purposes on an 2246 attack that took place. 2248 2250 2251 2252 2253 192.0.2.130 2254 2255 2256 2257 CERT-FOR-OUR-DOMAIN#209-1 2258 2259 2260 2262 2264 2266 2267 2268 CERT-FOR-OUR-DOMAIN#209-1 2269 2270 2004-02-05T10:21:08+00:00 2271 2004-02-05T10:21:05+00:00 2272 2004-02-05T10:35:00+00:00 2273 2004-02-05T10:27:38+00:00 2274 Host illicitly accessed admin account 2275 2276 2277 2279 2280 2281 2282 Constituency-contact for 192.0.2.35 2283 2284 Constituency-contact@10.1.1.2 2285 2286 2287 2288 2289 2290 192.0.2.35 2291 2292 2293 2294 32821 2295 2296 2297 2298 2299 192.0.2.67 2300 2301 2302 2303 22 2304 2305 2306 2307 2308 2309 2310 2004-02-05T10:28:00+00:00 2311 2312 CSIRT-FOR-OUR-DOMAIN#209-1 2313 2314 2315 Incident report sent to SP for 192.0.2.35 2316 2317 2318 2319 2320 2322 6.4. IncidentQuery Communication Flow 2324 The diagram below outlines the RID IncidentQuery communication flow 2325 between RID systems on different networks. 2327 SP-1 SP-2 2329 1. Generate a request for 2330 information on a specific 2331 incident number or incident type 2333 2. o---IncidentQuery---> 2335 3. Verify policy information 2336 and determine if matches exist 2337 for requested information 2339 4. <-------Report------o 2341 5. Associate report to request 2342 by incident number or type 2343 and file report(s). 2345 Figure 10: IncidentQuery Communication Flow 2347 The IncidentQuery message communication receives a response of a 2348 Report message. If the Report message is empty, the responding host 2349 did not have information available to share with the requestor. The 2350 incident number and responding RID system, as well as the transport, 2351 assist in the association of the request and response since a report 2352 can be filed and is not always solicited. If there is a problem with 2353 the IncidentQuery message, such as a failure to validate the digital 2354 signature or decrypt the request, a RequestAuthorization message is 2355 sent to the requestor. The RequestAuthorization message should 2356 provide the reason why the message could not be processed. 2358 6.4.1. IncidentQuery Example 2360 The IncidentQuery request may be received in several formats as a 2361 result of the type of query being performed. If the incident number 2362 is the only information provided, the IODEF document and IP packet 2363 data may not be needed to complete the request. However, if a type 2364 of incident is requested, the incident number remains NULL, and the 2365 IP packet data will not be included in the IODEF RecordItem class; 2366 the other incident information is the main source for comparison. In 2367 the case in which an incident number may not be the same between 2368 CSIRTs, the incident number and/or IP packet information can be 2369 provided and used for comparison on the receiving RID system to 2370 generate (a) Report message(s). 2372 This query is sent to 192.0.2.3, inquiring about the incident with 2373 the identifier CERT-FOR-OUR-DOMAIN#210-1. The Report will be 2374 provided to the requestor identified and verified through the 2375 authentication and digital signature information provided in the RID 2376 message. An example Report is provided above. 2378 2380 2382 2383 2384 192.0.2.3 2385 2386 2387 2388 CERT-FOR-OUR-DOMAIN#210-1 2389 2390 2391 2393 7. RID Schema Definition 2395 2396 2402 2406 2410 2418 2420 2425 2426 XML Schema wrapper for IODEF 2427 2428 2429 2430 2431 2432 2433 2434 2435 2437 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2466 2467 2468 2470 2471 2473 2475 2476 2477 2478 2479 2481 2482 2483 2484 2486 2491 2492 RID Policy used for transport of 2493 messages 2494 2496 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2534 2535 2536 2537 2538 2539 2540 2541 2542 2543 2544 2545 2546 2547 2548 2549 2550 2551 2552 2554 2555 2556 2557 2558 2559 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 2571 2573 2574 2575 2576 2578 8. Security Requirements 2580 8.1. XML Digital Signatures and Encryption 2582 RID leverages existing security standards and data markings in 2583 RIDPolicy to achieve the required levels of security for the exchange 2584 of incident information. The use of standards include TLS and the 2585 XML security features of encryption [XMLencrypt] and digital 2586 signatures [RFC3275], [XMLsig]. The standards provide clear methods 2587 to ensure that messages are secure, authenticated, and authorized, 2588 and that the messages meet policy and privacy guidelines and maintain 2589 integrity. 2591 As specified in the relevant sections of this document, the XML 2592 digital signature [RFC3275] and XML encryption [XMLencrypt] are used 2593 in the following cases: 2595 XML Digital Signature 2597 o The originator of the TraceRequest or Investigation request MUST 2598 use a detached signature to sign at least one of the original 2599 elements contained in the RecordItem class to provide 2600 authentication to all upstream participants in the trace or those 2601 involved in the investigation. All instances of RecordItem 2602 provided by the originator may be individually signed, and 2603 additional RecordItem entries by upstream peers in the trace or 2604 investigation may be signed by the peer adding the data, while 2605 maintaining the original RecordItem entry(s) and detached 2606 signature(s) from the original requestor. It is important to note 2607 that the data is signed at the RecordItem level. Since multiple 2608 RecordItems may exist within an IODEF document and may originate 2609 from different sources, the signature is applied at the RecordItem 2610 level to enable the use of an XML detached signature. This 2611 signature MUST be passed to all recipients of the TraceRequest or 2612 Investigation request. 2614 o If an Investigation or TraceRequest does not include a RecordItem 2615 entry, an NTP timestamp may be used to ensure there is data to be 2616 signed for the multi-hop authentication use case. 2618 o For all message types, the full IODEF/RID document MUST be signed 2619 using an enveloped signature by the sending peer to provide 2620 authentication and integrity to the receiving RID system. 2622 o Optionally, nested enveloped signatures MAY be used when 2623 forwarding documents during an investigation. If this option is 2624 used, the implementation MUST follow the guidance specified in the 2625 XML Digital Signature [XMLsig] specification for two or more 2626 enveloped signatures. 2628 XML Encryption 2630 o The IODEF/RID document may be encrypted to provide an extra layer 2631 of security between peers so that the message is not only 2632 encrypted for the transport, but also while stored. This behavior 2633 would be agreed upon between peers or a consortium, or determined 2634 on a per-message basis, depending on security requirements. It 2635 should be noted that there are cases for transport where the 2636 RIDPolicy class needs to be presented in clear text, as detailed 2637 in the transport document [RFC6046-bis]. 2639 o An Investigation request, or any other message type that may be 2640 relayed through RID systems other than the intended destination as 2641 a result of trust relationships, may be encrypted for the intended 2642 recipient. This may be necessary if the RID network is being used 2643 for message transfer, the intermediate parties do not need to have 2644 knowledge of the request contents, and a direct communication path 2645 does not exist. In that case, the RIDPolicy class is used by 2646 intermediate parties and is maintained in clear text. 2648 o The action taken in the Result message may be encrypted using the 2649 key of the request originator. In that case, the intermediate 2650 parties can view the RIDPolicy information and know the trace has 2651 been completed and do not need to see the action. If the use of 2652 encryption were limited to sections of the message, the History 2653 class information would be encrypted. Otherwise, it is 2654 RECOMMENDED to encrypt the entire IODEF/RID document and use an 2655 enveloped signature, for the originator of the request. The 2656 existence of the Result message for an incident would tell any 2657 intermediate parties used in the path of the incident 2658 investigation that the incident handling has been completed. 2660 o The iodef:restriction attribute sets expectations for the privacy 2661 of an incident and is defined in section 3.2 of RFC5070. 2662 Following the guidance for XML encryption in the Security 2663 Requirements Section, the iodef:restriction attribute can be set 2664 in any of the RID classes to define restrictions and encryption 2665 requirements for the exchange of incident information. The 2666 restriction options enable encryption capabilities for the 2667 complete exchange of an IODEF document (including any extensions), 2668 within specific classes of IODEF, or IODEF extensions where more 2669 limited restrictions are desired. The restriction attribute is 2670 contained in each of the RID classes and MUST be used in 2671 accordance with confidentiality expectations for either sections 2672 of the IODEF document or the complete IODEF document. Consortiums 2673 and organizations should consider this guidance when creating 2674 exchange policies. 2676 o Expectations based on restriction setting: 2678 * If restriction is set to "private", the class or document MUST 2679 be encrypted for the recipient using XML encryption and the 2680 public key of the recipient. The use of PKI between entities 2681 SHOULD adhere to any applicable certificate policy and 2682 practices agreements for the use of RID. 2684 * If restriction is set to "need-to-know", the class or document 2685 MUST be encrypted to ensure only those with need-to-know access 2686 can decrypt the data. The document can either be encrypted for 2687 each individual for which access is intended or a single group 2688 key may be used. The method used SHOULD adhere to any 2689 certificate policy and practices agreements between entities 2690 for the use of RID. A group key in this instance refers to a 2691 single key (symmetric) that is used to encrypt the block of 2692 data. The users with need-to-know access privileges may be 2693 given access to the shared key via a secure distribution 2694 method, for example, providing access to the symmetric key 2695 encrypted with each of users public keys. 2697 * If restriction is set to "public", the class or document MUST 2698 be sent in clear text. This setting can be critical if certain 2699 sections of a document or an entire document are to be shared 2700 without restrictions. This provides flexibility within an 2701 incident to share out certain information freely where 2702 appropriate. 2704 * If restriction is set to "default", The information can be 2705 shared according to an information disclosure policy pre- 2706 arranged by the communicating parties. 2708 o Expectations based on placement of the restriction setting: 2710 * If restriction is set within one of the RID classes, the 2711 restriction applies to the entire IODEF document. 2713 * If restriction is set within individual IODEF classes, the 2714 restriction applies to the specific IODEF class and the 2715 children of that class. 2717 The formation of policies is a very important aspect of using a 2718 messaging system like RID to exchange potentially sensitive 2719 information. Many considerations should be involved for peering 2720 parties, and some guidelines to protect the data, systems, and 2721 transport are covered in this section. Policies established should 2722 provide guidelines for communication methods, security, and fall-back 2723 procedures. See sections 8.5 and 8.6 for additional information on 2724 consortiums and PKI considerations. 2726 The security considerations for the storage and exchange of 2727 information in RID messaging may include adherence to local, 2728 regional, or national regulations in addition to the obligations to 2729 protect client information during an investigation. RID Policy is a 2730 necessary tool for listing the requirements of messages to provide a 2731 method to categorize data elements for proper handling. Controls are 2732 also provided for the sending entity to protect messages from third 2733 parties through XML encryption. 2735 RID provides a method to exchange incident handling request and 2736 Report messages to peer networks. Administrators have the ability to 2737 base decisions on the available resources and other factors of their 2738 network and maintain control of incident investigations within their 2739 own network. Thus, RID provides the ability for participating 2740 networks to manage their own security controls, leveraging the 2741 information listed in RIDPolicy. 2743 8.2. Message Transport 2745 The transport specifications are fully defined in a separate document 2746 [RFC6046-bis]. The specified transport protocols MUST use encryption 2747 to provide an additional level of security and integrity, while 2748 supporting mutual authentication through bi-directional certificate 2749 usage. Any subsequent transport method defined should take advantage 2750 of existing standards for ease of implementation and integration of 2751 RID systems. Session encryption for the transport of RID messages is 2752 enforced in the transport specification. The privacy and security 2753 considerations are addressed fully in RID to protect sensitive 2754 portions of documents and provide a method to authenticate the 2755 messages. Therefore, RID messages do not rely on the security 2756 provided by the transport layer alone. The encryption requirements 2757 and considerations for RID are discussed in Section 8.1 of this 2758 document. 2760 XML security functions such as the digital signature [RFC3275] and 2761 encryption [XMLencrypt] provide a standards-based method to encrypt 2762 and digitally sign RID messages. RID messages specify system use and 2763 privacy guidelines through the RIDPolicy class. A public key 2764 infrastructure (PKI) provides the base for authentication and 2765 authorization, encryption, and digital signatures to establish trust 2766 relationships between members of a RID consortium or a peering 2767 consortium. 2769 XML security functions such as the digital signature [RFC3275] and 2770 encryption [XMLencrypt] can be used within the contents of the 2771 message for privacy and security in cases for which certain elements 2772 must remain encrypted or signed as they traverse the path of a trace. 2773 For example, the digital signature on a TraceRequest can be used to 2774 verify the identity of the trace originator. The use of the XML 2775 security features in RID messaging is in accordance with the 2776 specifications for the IODEF model; however, the use requirements may 2777 differ since RID also incorporates communication of security incident 2778 information. 2780 8.3. Message Delivery Protocol - Integrity and Authentication 2782 The RID protocol must be able to guarantee delivery and meet the 2783 necessary security requirements of a state-of-the-art protocol. In 2784 order to guarantee delivery, TCP should be considered as the 2785 underlying protocol within the current network standard practices. 2787 Security requirements must include the integrity, authentication, 2788 privacy, and authorization of the messages sent between systems 2789 communicating via RID. The communication between RID systems must be 2790 authenticated and encrypted to ensure the integrity of the messages 2791 and the RID systems involved in the trace. Another concern that 2792 needs to be addressed is authentication for a request that traverses 2793 multiple networks. In this scenario, systems in the path of the 2794 multi-hop TraceRequest need to authorize a trace from not only their 2795 neighbor network, but also from the initiating RID system as 2796 discussed in Section 8.5. Several methods can be used to ensure 2797 integrity and privacy of the communication. 2799 The transport mechanism selected MUST follow the defined transport 2800 protocol [RFC6046-bis] when using RID messaging to ensure consistency 2801 among the peers. Consortiums may vary their selected transport 2802 mechanisms and thus must decide upon a mutual protocol to use for 2803 transport when communicating with peers in a neighboring consortium 2804 using RID. RID systems MUST implement and deploy HTTPS as defined in 2805 the transport document [RFC6046-bis] and optionally support other 2806 protocols such as the Blocks Extensible Exchange Protocol (BEEP). 2807 RID, the XML security functions, and transport protocols must 2808 properly integrate with a public key infrastructure (PKI) managed by 2809 the consortium or one managed by a trusted entity. For the Internet, 2810 a few of examples of existing efforts that could be leveraged to 2811 provide the supporting PKI include the American Registry for Internet 2812 Numbers (ARIN) and the Regional Internet Registry's (RIR's) PKI 2813 hierarchy, vendor issued certificates, or approved issuers of 2814 Extended Validation (EV) Certificates. Security and privacy 2815 considerations related to consortiums are discussed in Sections 8.5 2816 and 8.6. 2818 8.4. Transport Communication 2820 Out-of-band communications dedicated to SP interaction for RID 2821 messaging would provide additional security as well as guaranteed 2822 bandwidth during a denial-of-service attack. For example, an out-of- 2823 band channel may consist of logical paths defined over the existing 2824 network. Out-of-band communications may not be practical or possible 2825 between service providers, but provisions should be considered to 2826 protect the incident management systems used for RID messaging. 2827 Methods to protect the data transport may also be provided through 2828 session encryption. 2830 In order to address the integrity and authenticity of messages, 2831 transport encryption MUST be used to secure the traffic sent between 2832 RID systems. Systems with predefined relationships for RID include 2833 those who peer within a consortium with agreed-upon appropriate use 2834 regulations and for peering consortiums. Trust relationships may 2835 also be defined through a bridged or hierarchical PKI in which both 2836 peers belong. 2838 Systems used to send authenticated RID messages between networks MUST 2839 use a secured system and interface to connect to a border network's 2840 RID systems. Each connection to a RID system MUST meet the security 2841 requirements agreed upon through the consortium regulations, peering, 2842 or SLAs. The RID system MUST only listen for and send RID messages 2843 on the designated port, which also MUST be over an encrypted tunnel 2844 meeting the minimum requirement of algorithms and key lengths 2845 established by the consortium, peering, or SLA. The selected 2846 cryptographic algorithms for symmetric encryption, digital 2847 signatures, and hash functions MUST meet minimum security levels of 2848 the times. The encryption strength MUST adhere to import and export 2849 regulations of the involved countries for data exchange. 2851 8.5. Authentication of RID Protocol 2853 In order to ensure the authenticity of the RID messages, a message 2854 authentication scheme is used to secure the protocol. XML security 2855 functions utilized in RID require a trust center such as a PKI for 2856 the distribution of credentials to provide the necessary level of 2857 security for this protocol. Layered transport protocols also utilize 2858 encryption and rely on a trust center. Public key certificate pairs 2859 issued by a trusted Certification Authority (CA) MAY be used to 2860 provide the necessary level of authentication and encryption for the 2861 RID protocol. The CA used for RID messaging must be trusted by all 2862 involved parties and may take advantage of similar efforts, such as 2863 the Internet2 federated PKI or the ARIN/RIR effort to provide a PKI 2864 to network providers. The PKI used for authentication also provides 2865 the necessary certificates needed for encryption used for the RID 2866 transport protocol [RFC6046-bis]. 2868 The use of pre-shared keys may be considered for authentication. If 2869 this option is selected, the specifications set forth in "Pre-Shared 2870 Key Ciphersuites for Transport Layer Security (TLS)" [RFC4279] MUST 2871 be followed. 2873 Hosts receiving a RID message MUST be able to verify that the sender 2874 of the request is valid and trusted. Using digital signatures on a 2875 hash of the RID message with an X.509 version 3 certificate issued by 2876 a trusted party MUST be used to authenticate the request. The X.509 2877 version 3 specifications as well as the digital signature 2878 specifications and path validation standards set forth in [RFC5280] 2879 MUST be followed in order to interoperate with a PKI designed for 2880 similar purposes. The IODEF specification MUST be followed for 2881 digital signatures to provide the authentication and integrity 2882 aspects required for secure messaging between network providers. The 2883 use of digital signatures in RID XML messages MUST follow the World 2884 Wide Web Consortium (W3C) recommendations for signature syntax and 2885 processing when either the XML encryption [XMLencrypt] or digital 2886 signature [XMLsig], [RFC3275] is used within a document. Transport 2887 specifications are detailed in a separate document [RFC6046-bis]. 2889 It might be helpful to define an extension to the authentication 2890 scheme that uses attribute certificates [RFC5755] in such a way that 2891 an application could automatically determine whether human 2892 intervention is needed to authorize a request; however, the 2893 specification of such an extension is out of scope for this document. 2895 8.5.1. Multi-Hop TraceRequest Authentication 2897 Bilateral trust relations between network providers ensure the 2898 authenticity of requests for TraceRequests from immediate peers in 2899 the web of networks formed to provide the traceback capability. A 2900 network provider several hops into the path of the RID trace must 2901 trust the information from its own trust relationships as well as the 2902 previous trust relationships in the downstream path. The use of 2903 multi-hop authentication in an Investigation request is used when an 2904 Investigation is sent to multiple entities or SPs in an iterative 2905 manner. For practical reasons, the SPs may want to prioritize 2906 incident handling events based upon the immediate peer for a 2907 TraceRequest, the originator of a request, and the listed Confidence 2908 rating for the incident. In order to provide a higher assurance 2909 level of the authenticity of the TraceRequest, the originating RID 2910 system is included in the TraceRequest along with contact information 2911 and the information of all RID systems in the path the trace has 2912 taken. This information is provided through the IODEF EventData 2913 class nesting the list of systems and contacts involved in a trace, 2914 while setting the category attribute to "infrastructure". 2916 A second measure MUST be taken to ensure the identity of the 2917 originating RID system. The originating RID system MUST include a 2918 digital signature in the TraceRequest sent to all systems in the 2919 upstream path. The digital signature from the RID system is 2920 performed on the RecordItem class of the IODEF following the XML 2921 digital signature specifications from W3C [XMLsig] using a detached 2922 signature. The signature MUST be passed to all parties that receive 2923 a TraceRequest, and each party MUST be able to perform full path 2924 validation on the digital signature [RFC5280]. Full path validation 2925 verifies the chaining relationship to a trusted root and also 2926 performs a certificate revocation check. In order to accommodate 2927 that requirement, the RecordItem data MUST remain unchanged as a 2928 request is passed along between providers and is the only element for 2929 which the signature is applied. If additional RecordItems are 2930 included in the document at upstream peers, the initial RecordItem 2931 entry MUST still remain with the detached signature. The subsequent 2932 RecordItem elements may be signed by the peer adding the incident 2933 information for the investigation. A second benefit to this 2934 requirement is that the integrity of the filter used is ensured as it 2935 is passed to subsequent SPs in the upstream trace of the incident. 2936 The trusted PKI also provides the keys used to digitally sign the 2937 RecordItem class for TraceRequest or Investigation to meet the 2938 requirement of authenticating the original request. Any host in the 2939 path of the trace should be able to verify the digital signature 2940 using the trusted PKI. 2942 In the case in which an enterprise network using RID sends a 2943 TraceRequest to its provider, the signature from the enterprise 2944 network MUST be included in the initial request. The SP may generate 2945 a new request to send upstream to members of the SP consortium to 2946 continue the investigation. If the original request is sent, the 2947 originating SP, acting on behalf of the enterprise network under 2948 attack, MUST also digitally sign, with an enveloped signature, the 2949 full IODEF document to assure the authenticity of the TraceRequest. 2950 An SP that offers RID as a service may be using its own PKI to secure 2951 RID communications between its RID system and the attached enterprise 2952 networks. SPs participating in the trace MUST be able to determine 2953 the authenticity of RID requests. 2955 8.6. Consortiums and Public Key Infrastructures 2957 Consortiums of SPs are an ideal way to establish a communication web 2958 of trust for RID messaging. It should be noted that direct 2959 relationships may be ideal for some communications, such as those 2960 between a provider of incident information and a subscriber of the 2961 incident reports. The consortium could provide centralized 2962 resources, such as a PKI, and established guidelines for use of the 2963 RID protocol. The consortium may assist in establishing trust 2964 relationships between the participating SPs to achieve the necessary 2965 level of cooperation and experience-sharing among the consortium 2966 entities. This may be established through PKI certificate policy 2967 [RFC3647] reviews to determine the appropriate trust levels between 2968 organizations or entities. The consortium may also be used for other 2969 purposes to better facilitate communication among SPs in a common 2970 area (Internet, region, government, education, private networks, 2971 etc.). 2973 Using a PKI to distribute certificates used by RID systems provides 2974 an already established method to link trust relationships between SPs 2975 of consortiums that peer with SPs belonging to a separate consortium. 2976 In other words, consortiums could peer with other consortiums to 2977 enable communication of RID messages between the participating SPs. 2978 The PKI along with Memorandums of Agreement could be used to link 2979 border directories to share public key information in a bridge, a 2980 hierarchy, or a single cross-certification relationship. 2982 Consortiums also need to establish guidelines for each participating 2983 SP to adhere to. The RECOMMENDED guidelines include: 2985 o Physical and logical practices to protect RID systems; 2987 o Network and application layer protection for RID systems and 2988 communications; 2990 o Proper use guidelines for RID systems, messages, and requests; and 2992 o A PKI and policy to provide authentication, integrity, and 2993 privacy. 2995 The functions described for a consortium's role parallel that of a 2996 PKI federation. The PKI federations that currently exist are 2997 responsible for establishing security guidelines and PKI trust 2998 models. The trust models are used to support applications to share 2999 information using trusted methods and protocols. 3001 A PKI can also provide the same level of security for communication 3002 between an end entity (enterprise, educational, or government 3003 customer network) and the SP. The PKI may be a subordinate CA or in 3004 the CA hierarchy from the SP's consortium to establish the trust 3005 relationships necessary as the request is made to other connected 3006 networks. 3008 8.7. Privacy Concerns and System Use Guidelines 3010 Privacy issues raise many concerns when information-sharing is 3011 required to achieve the goal of stopping or mitigating the effects of 3012 a security incident. The RIDPolicy class is used to automate the 3013 enforcement of the privacy concerns listed within this document. The 3014 privacy and system use concerns that MUST be addressed in the RID 3015 system and other integrated components include the following: 3017 Network Provider Concerns: 3019 o Privacy of data monitored and/or stored on IDSs for attack 3020 detection. 3022 o Privacy of data monitored and stored on systems used to trace 3023 traffic across a single network. 3025 Customer Attached Networks Participating in RID with SP: 3027 o Customer networks may include an enterprise, educational, 3028 government, or other attached networks to an SP participating in 3029 RID and MUST be made fully aware of the security and privacy 3030 considerations for using RID. 3032 o Customers MUST know the security and privacy considerations in 3033 place by their SP and the consortium of which the SP is a member. 3035 o Customers MUST understand that their data can and will be sent to 3036 other SPs in order to complete a trace unless an agreement stating 3037 otherwise is made in the service level agreements between the 3038 customer and SP. 3040 Parties Involved in the Attack: 3042 o Privacy of the identity of a host involved in an attack. 3044 o Privacy of information such as the source and destination used for 3045 communication purposes over the monitored or RID connected 3046 network(s). 3048 o Protection of data from being viewed by intermediate parties in 3049 the path of an Investigation request MUST be considered. 3051 Consortium Considerations: 3053 o System use restricted to security incident handling within the 3054 local region's definitions of appropriate traffic for the network 3055 monitored and linked via RID in a single consortium also abiding 3056 by the consortium's use guidelines. 3058 o System use prohibiting the consortium's participating SPs from 3059 inappropriately tracing non-attack traffic to locate sources or 3060 mitigate traffic unlawfully within the jurisdiction or region. 3062 Inter-Consortium Considerations: 3064 o System use between peering consortiums MUST also adhere to any 3065 government communication regulations that apply between those two 3066 regions, such as encryption export and import restrictions. This 3067 may include consortiums that are categorized as 3068 "BetweenConsortiums" or "AcrossNationalBoundaries". 3070 o System use between consortiums MUST NOT request traffic traces and 3071 actions beyond the scope intended and permitted by law or inter- 3072 consortium agreements. 3074 o System use between consortiums classified as 3075 "AcrossNationalBoundaries" MUST respect national boundary issues 3076 and limit requests to appropriate system use and not to achieve 3077 their own agenda to limit or restrict traffic that is otherwise 3078 permitted within the country in which the peering consortium 3079 resides. 3081 The security and privacy considerations listed above are for the 3082 consortiums, SPs, and enterprises to agree upon. The agreed-upon 3083 policies may be facilitated through use of the RIDPolicy class. Some 3084 privacy considerations are addressed through the RID guidelines for 3085 encryption and digital signatures as described in Section 8.1. 3087 RID is useful in determining the true source of an incident that 3088 traverses multiple networks or to communicate security incidents and 3089 automate the response. The information obtained from the 3090 investigation may determine the identity of the source host or the 3091 network provider used by the source of the traffic. It should be 3092 noted that the trace mechanism used across a single-network provider 3093 may also raise privacy concerns for the clients of the network. 3094 Methods that may raise concern include those that involve storing 3095 packets for some length of time in order to trace packets after the 3096 fact. Monitoring networks for intrusions and for tracing 3097 capabilities also raises concerns for potentially sensitive valid 3098 traffic that may be traversing the monitored network. IDSs and 3099 single-network tracing are outside of the scope of this document, but 3100 the concern should be noted and addressed within the use guidelines 3101 of the network. Some IDSs and single-network trace mechanisms 3102 attempt to properly address these issues. RID is designed to provide 3103 the information needed by any single-network trace mechanism. The 3104 provider's choice of a single trace mechanism depends on resources, 3105 existing solutions, and local legislation. Privacy concerns in 3106 regard to the single-network trace must be dealt with at the client- 3107 to-SP level and are out of scope for RID messaging. 3109 The identity of the true source of an attack being traced through RID 3110 could be sensitive. The true identity listed in a Result message can 3111 be protected through the use of encryption [XMLencrypt] enveloping 3112 the IODEF document and RID Result information, using the public 3113 encryption key of the originating SP. Alternatively, the action 3114 taken may be listed without the identity being revealed to the 3115 originating SP. The ultimate goal of the RID communication system is 3116 to stop or mitigate attack traffic, not to ensure that the identity 3117 of the attack traffic is known to involved parties. The SP that 3118 identifies the source should deal directly with the involved parties 3119 and proper authorities in order to determine the guidelines for the 3120 release of such information, if it is regarded as sensitive. In some 3121 situations, systems used in attacks are compromised by an unknown 3122 source and, in turn, are used to attack other systems. In that 3123 situation, the reputation of a business or organization may be at 3124 stake, and the action taken may be the only additional information 3125 reported in the Result message to the originating system. If the 3126 security incident is a minor incident, such as a zombie system used 3127 in part of a large-scale DDoS attack, ensuring the system is taken 3128 off the network until it has been fixed may be sufficient. The 3129 decision is left to the system users and consortiums to determine 3130 appropriate data to be shared given that the goal of the 3131 specification is to provide the appropriate technical options to 3132 remain compliant. The textual descriptions should include details of 3133 the incident in order to protect the reputation of the unknowing 3134 attacker and prevent the need for additional investigation. Local, 3135 state, or national laws may dictate the appropriate reporting action 3136 for specific security incidents. 3138 Privacy becomes an issue whenever sensitive data traverses a network. 3139 For example, if an attack occurred between a specific source and 3140 destination, then every network provider in the path of the trace 3141 becomes aware that the cyber attack occurred. In a targeted attack, 3142 it may not be desirable that information about two nation states that 3143 are battling a cyber war would become general knowledge to all 3144 intermediate parties. However, it is important to allow the traces 3145 to take place in order to halt the activity since the health of the 3146 networks in the path could also be at stake during the attack. This 3147 provides a second argument for allowing the Result message to only 3148 include an action taken and not the identity of the offending host. 3149 In the case of an Investigation request, where the originating SP is 3150 aware of the SP that will receive the request for processing, the 3151 free-form text areas of the document could be encrypted [XMLencrypt] 3152 using the public key of the destination SP to ensure that no other SP 3153 in the path can read the contents. The encryption is accomplished 3154 through the W3C [XMLencrypt] specification for encrypting an element. 3156 In some situations, all network traffic of a nation may be granted 3157 through a single network provider. In that situation, options must 3158 support sending Result messages from a downstream peer of that 3159 network provider. That option provides an additional level of 3160 abstraction to hide the identity and the SP of the identified source 3161 of the traffic. Legal action may override this technical decision 3162 after the trace has taken place, but that is out of the technical 3163 scope of this document. 3165 Privacy concerns when using an Investigation message to request 3166 action close to the source of valid attack traffic needs to be 3167 considered. Although the intermediate SPs may relay the request if 3168 there is no direct trust relationship to the closest SP to the 3169 source, the intermediate SPs do not require the ability to see the 3170 contents of the packet or the text description field(s) in the 3171 request. This message type does not require any action by the 3172 intermediate RID systems, except to relay the packet to the next SP 3173 in the path. Therefore, the contents of the request may be encrypted 3174 for the destination system. The intermediate SPs only needs to know 3175 how to direct the request to the manager of the ASN in which the 3176 source IP address belongs. 3178 Traces must be legitimate security-related incidents and not used for 3179 purposes such as sabotage or censorship. An example of such abuse of 3180 the system includes a request to block or rate-limit legitimate 3181 traffic to prevent information from being shared between users on the 3182 Internet (restricting access to online versions of papers) or 3183 restricting access from a competitor's product in order to sabotage a 3184 business. 3186 Intra-consortium RID communications raise additional issues, 3187 especially when the peering consortiums reside in different regions 3188 or nations. TraceRequests, Investigation requests, and requested 3189 actions to mitigate or stop traffic must adhere to the appropriate 3190 use guidelines and yet prevent abuse of the system. First, the 3191 peering consortiums MUST identify the types of traffic that can be 3192 traced between the borders of the participating SPs of each 3193 consortium. The traffic traced should be limited to security- 3194 incident-related traffic. Second, the traces permitted within one 3195 consortium if passed to a peering consortium may infringe upon the 3196 peering consortium's freedom of information laws. An example would 3197 be a consortium in one country permitting a trace of traffic 3198 containing objectionable material, outlawed within that country. The 3199 RID trace may be a valid use of the system within the confines of 3200 that country's network border; however, it may not be permitted to 3201 continue across network boundaries where such content is permitted 3202 under law. By continuing the trace in another country's network, the 3203 trace and response could have the effect of improperly restricting 3204 access to data. A continued trace into a second country may break 3205 the laws and regulations of that nation. Any such traces MUST cease 3206 at the country's border. 3208 The privacy concerns listed in this section address issues among the 3209 trusted parties involved in a trace within an SP, a RID consortium, 3210 and peering RID consortiums. Data used for RID communications must 3211 also be protected from parties that are not trusted. This protection 3212 is provided through the authentication and encryption of documents as 3213 they traverse the path of trusted servers. Each RID system MUST 3214 perform a bi-directional authentication when sending a RID message 3215 and use the public encryption key of the upstream or downstream peer 3216 to send a message or document over the network. This means that the 3217 document is decrypted and re-encrypted at each RID system via TLS 3218 over the transport protocol [RFC6046-bis]. The RID messages may be 3219 decrypted at each RID system in order to properly process the request 3220 or relay the information. Today's processing power is more than 3221 sufficient to handle the minimal burden of encrypting and decrypting 3222 relatively small typical RID messages. 3224 9. Security Considerations 3226 RID has many security requirements and considerations built into the 3227 design of the protocol, several of which are described in the 3228 Security Requirements section. For a complete view of security, 3229 considerations include the availability, confidentiality, and 3230 integrity concerns for the transport, storage, and exchange of 3231 information. 3233 Authenticated encrypted tunnels between systems accepting RID 3234 communications are used to provide confidentiality, integrity, 3235 authenticity, and privacy for the data at the transport layer. 3236 Encryption and digital signatures are also used at the IODEF document 3237 level through RID options to provide confidentiality, integrity, 3238 authenticity, privacy and traceability of the document contents. 3239 Trust relationships are based on consortiums and established trust 3240 relationships of public key infrastructure (PKI) cross-certifications 3241 of consortiums. Trust levels can be established in cross- 3242 certification processes where entities compare PKI policies that 3243 include the specific management and handling of an entity's PKI and 3244 certificates issued under that policy. [RFC3647] defines an Internet 3245 X.509 Public Key Infrastructure Certificate Policy and Certification 3246 Practices Framework that may be used in the comparison of policies to 3247 establish trust levels and agreements between entities, an entity and 3248 a consortium, and consortia. The agreements SHOULD consider key 3249 management practices including the ability to perform path validation 3250 on certificates [RFC5280], key distribution techniques [RFC2585], 3251 Certificate Authority and Registration Authority management 3252 practices. 3254 The agreements between entities SHOULD also include a common 3255 understanding of the usage of RID security, policy, and privacy 3256 options discussed in this section. The formality, requirements, and 3257 complexity of the agreements for the certificate policy, practices, 3258 and the use of RID options SHOULD be decided by the entities or 3259 consortiums creating those agreements. 3261 10. IANA Considerations 3263 This document uses URNs to describe XML namespaces and XML schemas 3264 [XMLschema] conforming to a registry mechanism described in 3265 [RFC3688]. 3267 Registration request for the iodef-rid namespace: 3269 URI: urn:ietf:params:xml:ns:iodef-rid-1.1 3271 Registrant Contact: See the "Author's Address" section of this 3272 document. 3274 XML: None. Namespace URIs do not represent an XML specification. 3276 Registration request for the iodef-rid XML schema: 3278 URI: urn:ietf:params:xml:schema:iodef-rid-1.1 3280 Registrant Contact: See the "Author's Address" section of this 3281 document. 3283 XML: See Section 7, "RID Schema Definition", of this document. 3285 11. Summary 3287 Security incidents have always been difficult to trace as a result of 3288 the spoofed sources, resource limitations, and bandwidth utilization 3289 problems. Incident response is often slow even when the IP address 3290 is known to be valid because of the resources required to notify the 3291 responsible party of the attack and then to stop or mitigate the 3292 attack traffic. Methods to identify and trace attacks near real time 3293 are essential to thwarting attack attempts. Network providers need 3294 policies and automated methods to combat the hacker's efforts. SPs 3295 need automated monitoring and response capabilities to identify and 3296 trace attacks quickly without resource-intensive side effects. 3297 Integration with a centralized communication system to coordinate the 3298 detection, tracing, and identification of attack sources on a single 3299 network is essential. RID provides a way to integrate SP resources 3300 for each aspect of attack detection, tracing, and source 3301 identification and extends the communication capabilities among 3302 network providers. The communication is accomplished through the use 3303 of flexible IODEF XML-based documents passed between IHSs or RID 3304 systems. A TraceRequest or Investigation request is communicated to 3305 an upstream SP and may result in an upstream trace or in an action to 3306 stop or mitigate the attack traffic. The messages are communicated 3307 among peers with security inherent to the RID messaging scheme 3308 provided through existing standards such as XML encryption and 3309 digital signatures. Policy information is carried in the RID message 3310 itself through the use of the RIDPolicy. RID provides the timely 3311 communication among SPs, which is essential for incident handling. 3313 12. References 3315 12.1. Normative References 3317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3318 Requirement Levels", BCP 14, RFC 2119, March 1997. 3320 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 3321 Infrastructure Operational Protocols: FTP and HTTP", 3322 RFC 2585, May 1999. 3324 [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 3325 Language) XML-Signature Syntax and Processing", RFC 3275, 3326 March 2002. 3328 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3329 January 2004. 3331 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 3332 for Transport Layer Security (TLS)", RFC 4279, 3333 December 2005. 3335 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 3336 Object Description Exchange Format", RFC 5070, 3337 December 2007. 3339 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3340 Housley, R., and W. Polk, "Internet X.509 Public Key 3341 Infrastructure Certificate and Certificate Revocation List 3342 (CRL) Profile", RFC 5280, May 2008. 3344 [RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet 3345 Attribute Certificate Profile for Authorization", 3346 RFC 5755, January 2010. 3348 [RFC6046-bis] 3349 Trammell, B., "Transport of Real-time Inter-network 3350 Defense (RID) Messages", December 2011, . 3353 [XML1.0] Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C., and 3354 F. Yergeau, "Extensible Markup Language (XML) 1.0", W3C 3355 Recommendation XML 1.0, November 2008, 3356 . 3358 [XMLNames] 3359 Bray, T., Hollander, D., Layman, A., Tobin, R., and H. 3360 Thomson, "Namespaces in XML 1.0 (Third Edition)", W3C 3361 Recommendation , December 2009, 3362 . 3364 [XMLencrypt] 3365 Imaura, T., Dillaway, B., and E. Simon, "XML Encryption 3366 Syntax and Processing", W3C Recommendation , 3367 December 2002, . 3369 [XMLschema] 3370 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 3371 "XML Schema Part 1: Structures", W3C Recommendation Second 3372 Edition, October 2004, 3373 . 3375 [XMLsig] Bartel, M., Boyer, J., Fox, B., LaMaccia, B., and E. 3376 Simon, "XML-Signature Syntax and Processing", W3C 3377 Recommendation Second Edition, June 2008, 3378 . 3380 12.2. Informative References 3382 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 3383 selection, and registration of an Autonomous System (AS)", 3384 BCP 6, RFC 1930, March 1996. 3386 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 3387 Wu, "Internet X.509 Public Key Infrastructure Certificate 3388 Policy and Certification Practices Framework", RFC 3647, 3389 November 2003. 3391 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 3392 BCP 153, RFC 5735, January 2010. 3394 [RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)", 3395 RFC 6045, November 2010. 3397 Acknowledgements 3399 Many thanks to colleagues and the Internet community for reviewing 3400 and commenting on the document as well as providing recommendations 3401 to simplify and secure the protocol: Robert K. Cunningham, Ph.D, 3402 Cynthia D. McLain, Dr. William Streilein, Iljitsch van Beijnum, Steve 3403 Bellovin, Yuri Demchenko, Jean-Francois Morfin, Stephen Northcutt, 3404 Jeffrey Schiller, Brian Trammell, Roman Danyliw, Tony Tauber, Sandra 3405 G. Dykes, Ph.D., Katherine Goodier, Ph.D., Tony Rutkowski, Damir 3406 Rajnovic, David Black, and Paul Cichonski. 3408 Author's Address 3410 Kathleen M. Moriarty 3411 EMC Corporation 3412 176 South Street 3413 Hopkinton, MA 3414 United States 3416 Phone: 3417 Email: Kathleen.Moriarty@emc.com