idnits 2.17.1 draft-ietf-mile-rfc6045-bis-01.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 updates 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 (Using the creation date from RFC6045, updated by this document, for RFC5378 checks: 2006-11-15) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 17, 2011) is 4544 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 (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MILE Working Group K. Moriarty 2 Internet-Draft EMC 3 Updates: 6045 (if approved) November 17, 2011 4 Intended status: Standards Track 5 Expires: May 20, 2012 7 Real-time Inter-network Defense (RID) 8 draft-ietf-mile-rfc6045-bis-01.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 May 20, 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 . . . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . 22 76 4.3. IncidentSource . . . . . . . . . . . . . . . . . . . . . . 23 77 4.4. RID Name Spaces . . . . . . . . . . . . . . . . . . . . . 25 78 5. RID Messages . . . . . . . . . . . . . . . . . . . . . . . . . 25 79 5.1. TraceRequest . . . . . . . . . . . . . . . . . . . . . . . 25 80 5.2. RequestAuthorization . . . . . . . . . . . . . . . . . . . 26 81 5.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . . 27 82 5.4. Investigation Request . . . . . . . . . . . . . . . . . . 29 83 5.5. Report . . . . . . . . . . . . . . . . . . . . . . . . . . 31 84 5.6. IncidentQuery . . . . . . . . . . . . . . . . . . . . . . 32 85 6. RID Communication Exchanges . . . . . . . . . . . . . . . . . 34 86 6.1. Upstream Trace Communication Flow . . . . . . . . . . . . 34 87 6.1.1. RID TraceRequest Example . . . . . . . . . . . . . . . 36 88 6.1.2. RequestAuthorization Message Example . . . . . . . . . 40 89 6.1.3. Result Message Example . . . . . . . . . . . . . . . . 40 90 6.2. Investigation Request Communication Flow . . . . . . . . . 43 91 6.2.1. Investigation Request Example . . . . . . . . . . . . 44 92 6.2.2. RequestAuthorization Message Example . . . . . . . . . 46 93 6.3. Report Communication Flow . . . . . . . . . . . . . . . . 46 94 6.3.1. Report Example . . . . . . . . . . . . . . . . . . . . 47 96 6.4. IncidentQuery Communication Flow . . . . . . . . . . . . . 49 97 6.4.1. IncidentQuery Example . . . . . . . . . . . . . . . . 49 98 7. RID Schema Definition . . . . . . . . . . . . . . . . . . . . 50 99 8. Security Requirements . . . . . . . . . . . . . . . . . . . . 54 100 8.1. XML Digital Signatures and Encryption . . . . . . . . . . 54 101 8.2. Message Transport . . . . . . . . . . . . . . . . . . . . 57 102 8.3. Message Delivery Protocol - Integrity and 103 Authentication . . . . . . . . . . . . . . . . . . . . . . 58 104 8.4. Transport Communication . . . . . . . . . . . . . . . . . 59 105 8.5. Authentication of RID Protocol . . . . . . . . . . . . . . 59 106 8.5.1. Multi-Hop TraceRequest Authentication . . . . . . . . 60 107 8.6. Consortiums and Public Key Infrastructures . . . . . . . . 62 108 8.7. Privacy Concerns and System Use Guidelines . . . . . . . . 63 109 9. Security Considerations . . . . . . . . . . . . . . . . . . . 67 110 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 68 111 11. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69 113 12.1. Normative References . . . . . . . . . . . . . . . . . . . 69 114 12.2. Informative References . . . . . . . . . . . . . . . . . . 71 115 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 71 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 and privacy policy 176 information set in the RID schema. The RID schema acts as an XML 177 envelope to support the communication of IODEF documents for 178 exchanging or tracing information regarding incidents. RID messages 179 are encapsulated for transport, which is defined in a separate 180 document [RFC6046-bis] [RFC6046-bis]. The authentication, integrity, 181 and 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'. 221 o Guidance has improved to ensure consistent implementations and use 222 of XML encryption to provide confidentiality based on data 223 markers, specifically the iodef:restriction attribute in the IODEF 224 and IODEF-RID schemas. The attribute may also be present in IODEF 225 extension schemas, where the guidance also applies. 227 o All of the normative text from the Security Considerations Section 228 has been moved to a new Section, Security Requirements. 230 o The order in which the RID Schema is presented in Section 4 has 231 been changed to match the order in the IODEF-RID schema. 233 1.1. Normative and Informative 235 The XML schema [XMLschema] and transport requirements contained in 236 this document are normative; all other information provided is 237 intended as informative. More specifically, the following sections 238 of this document are intended as informative: Sections 1 and 2; and 239 the sub-sections of 3 including the introduction to 3, 3.1, and 3.2. 240 The following sections of this document are normative: The sub- 241 sections of 3 including 3.3, 3.4, and 3.5; Sections 5, 6, 7, and 8. 243 1.2. Terminology 245 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 246 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 247 document are to be interpreted as described in [RFC2119]. 249 2. Characteristics of Incidents 251 The goal of tracing a security incident may be to identify the source 252 or to find a point on the network as close to the origin of the 253 incident as possible. An incident may be defined as a benign 254 configuration issue, IT incident, an infraction to a service level 255 agreement (SLA), system compromise, a worm or Trojan infection, or a 256 single- or multiple-source denial-of-service attack. Incident 257 tracing can be used to identify the source(s) of an attack in order 258 to halt or mitigate the undesired behavior or to correct an 259 identified issue. RID messages can be communicated between entities 260 to report or investigate any type of incident and allows for actions 261 to be taken when the source of the incident or a point closer to the 262 source is known or has been identified. The purpose of tracing an 263 incident is to remedy the detected issue, halt, or mitigate the 264 effects of the incident. Methods to accomplish this may include 265 remediation of a configuration issue, filtering or rate-limiting the 266 traffic close to the source, or taking the host or network offline. 267 Care must also be taken to ensure that the systems involved in the 268 RID communications are not abused and to use proper analysis in 269 determining if attack traffic is, in fact, attack traffic at each SP 270 along the path of a trace. 272 Tracing security incidents can be a difficult task since attackers go 273 to great lengths to obscure their identity. In the case of a 274 security incident, the true source might be identified through an 275 existing established connection to the attacker's point of origin. 276 However, the attacker may not connect to the compromised system for a 277 long period of time after the initial compromise or may access the 278 system through a series of compromised hosts spread across the 279 network. Other methods of obscuring the source may include targeting 280 the host with the same attack from multiple sources using both valid 281 and spoofed source addresses. This tactic can be used to compromise 282 a machine and leave the difficult task of locating the true origin 283 for the administrators. Attackers use many techniques which can vary 284 between individuals or even organized groups of attackers. Through 285 analysis, the techniques may be grouped into indicators of compromise 286 to be shared via IODEF and RID, further assisting with the 287 improvement of detection capabilities. Security incidents, including 288 DDoS attacks, can be difficult or nearly impossible to trace because 289 of the nature of the attack. Some of the difficulties in 290 investigating attacks include the following: 292 o the incident or attack originates from multiple sources; 294 o the incident may leverage social engineering techniques or other 295 methods to gain access to resources and intellectual property 296 using what appears to be legitimate access methods such as 297 outbound web sessions from user systems; 299 o the attack may include various types of traffic meant to consume 300 server resources, such as a SYN flood attack without a significant 301 increase in bandwidth utilization; 303 o the type of traffic could include valid destination services, 304 which cannot be blocked since they are essential services to 305 business, such as DNS servers at an NP or HTTP requests sent to an 306 organization connected to the Internet; 308 o the attack may utilize varying types of packets including TCP, 309 UDP, ICMP, or other IP protocols; 311 o the attack may be from "zombies" or large "botnets", which then 312 require additional searches to locate a controlling server as the 313 true origin of the attack; 315 o the attack may use a very small number of packets from any 316 particular source, thus making a trace after the fact nearly 317 impossible; 319 o the indicators of a compromise may be difficult to detect. 321 If the source(s) of an incident cannot be determined from IP address 322 information it may be possible to trace the traffic based on 323 characteristics of the incident such as tracing the increased 324 bandwidth utilization or the type of packets seen by the client. In 325 the case of packets with spoofed source addresses, it is not a 326 trivial task to identify the source of an attack. 328 IODEF, any extensions to IODEF, and RID can be used to detail an 329 incident, characteristics of the incident (as it evolves), the 330 incident history, and communications of the incident to facilitate 331 the resolution and reporting of the incident. 333 3. Communication between CSIRTs and Service Providers 335 Note: The Introduction, and Sub-sections 3.1 and 3.2, are 336 informative, with the exception of references to IODEF/RID Transport 337 RFC6046-bis [RFC6046-bis]. Sub-sections 3.3, 3.4, and 3.5 are 338 normative. 340 Expediting the communication between CSIRTs and service providers 341 (SP) is essential when responding to a security-related incident, 342 which may cross network access points (Internet backbones or cloud 343 infrastructures) between service or network providers. As a result 344 of the urgency involved in this inter-service provider security 345 incident communication, there must be an effective system in place to 346 facilitate the interaction. This communication policy or method 347 should involve multiple means of communication to avoid a single 348 point of failure. Email is one way to transfer information about the 349 incident, packet traces, etc. However, email may not be received in 350 a timely fashion or be acted upon with the same urgency as a phone 351 call or other communication mechanism like RID. 353 A technical solution to trace traffic across a single service or 354 network provider may include homegrown or commercial systems for 355 which RID messaging must accommodate the input requirements. The 356 incident handling system used on the service or network provider's 357 backbone by the CSIRT to coordinate the trace across the single 358 network requires a method to accept and process and relay RID 359 messages to the system, as well as to wait for responses from the 360 system to continue the RID request process as appropriate. In this 361 scenario, each service provider maintains its own system capable of 362 communicating via RID and integrate with a management station used 363 for monitoring and analysis. An alternative for providers lacking 364 sufficient resources may be to have a neutral third party with access 365 to the provider's network resources who could be used to perform the 366 incident handling functions. This could be a function of a central 367 organization operating as a CSIRT for countries as a whole or within 368 a consortium that may be able to provide centralized resources. An 369 example of a consortium might include the cloud service providers. 371 Consortiums could consist of a group of service (network, cloud, 372 etc.) providers, CSIRTs, or other federation that agrees to 373 participate in the RID communication protocol with an agreed-upon 374 policy and communication protocol facilitating the secure transport 375 of IODEF/RID XML documents. Transport for RID messages is specified 376 in the IODEF/RID Transport [X.ridd] Recommendation. 378 One goal of RID is to prevent the need to permit access to other 379 networks' equipment through the use of a standard messaging mechanism 380 to enable the communication of incident handling information to other 381 providers in a consortium or in neighboring networks. The third 382 party mentioned above may be used in this technical solution to 383 assist in facilitating incident handling and possibly traceback 384 through smaller providers. The RID messaging mechanism may be a 385 logical or physical out-of-band network to ensure that the 386 communication is secure and unaffected by the state of the network 387 under attack. The two management methods would accommodate the needs 388 of larger providers to maintain full management of their network, and 389 the third-party option could be available to smaller providers who 390 lack the necessary human resources to perform incident handling 391 operations. The first method enables the individual providers to 392 involve their network operations staff to authorize the continuance 393 of a trace or other necessary response to a RID communication request 394 through their network via a notification and alerting system. 396 The network used for the communication should consist of out-of-band 397 or protected channels (direct communication links) or encrypted 398 channels dedicated to the transport of RID messages. The 399 communication links would be direct connections (virtual or physical) 400 between peers who have agreed-upon use and abuse policies through a 401 consortium. Consortiums might be linked through policy comparisons 402 and additional agreements to form a larger web or iterative network 403 of peers that correlates to the traffic paths available over the 404 larger web of networks or based on regions and logical groups. 405 Contact information, IP addresses of RID systems, and other 406 information must be coordinated between bilateral peers by a 407 consortium and may use existing databases, such as the routing 408 arbiter. The security, configuration, and confidence rating schemes 409 of the RID messaging peers must be negotiated by peers and must meet 410 certain overall requirements of the fully connected network 411 (Internet, government, education, etc.) through the peering and/or a 412 consortium-based agreement. 414 RID messaging established with clients of an provider may be 415 negotiated in a contract as part of a value-added service or through 416 a service level agreement (SLA). Further discussion is beyond the 417 scope of this document and may be more appropriately handled in 418 peering or service level agreements. 420 Procedures for incident handling need to be established and well 421 known by anyone that may be involved in incident response. The 422 procedures should also contain contact information for internal 423 escalation procedures, as well as for external assistance groups such 424 as a CSIRT, CERT Coordination Center (CERT/CC), Global Information 425 Assurance Certification (GIAC), and the FBI or other assisting 426 government organization in the country of the investigation. 428 3.1. Inter-network Provider RID Messaging 430 RID provides a standard protocol and format is required to ensure 431 inter-operability between vendors for the implementation of an 432 incident messaging mechanism. The messages should meet several 433 requirements in order to be meaningful as they traverse multiple 434 networks. RID provides the framework necessary for communication 435 between networks involved in the incident handling, possible 436 traceback, and mitigation of a security incident. Several message 437 types described in Section 3.5 are necessary to facilitate the 438 handling of a security incident. The message types include the 439 Report, IncidentQuery, TraceRequest, RequestAuthorization, Result, 440 and the Investigation request message. 442 The Report message is used when an incident is to be filed on a RID 443 system or associated database, where no further action is required. 444 An IncidentQuery message is used to request information on a 445 particular incident. A TraceRequest message is used when the source 446 of the traffic may have been spoofed. In that case, each network 447 provider in the upstream path who receives a TraceRequest will issue 448 a trace across the network to determine the upstream source of the 449 traffic. The RequestAuthorization and Result messages are used to 450 communicate the status and result of a TraceRequest or Investigation 451 request. The Investigation request message only involves the systems 452 accepting RID communication along the path to the source of the 453 traffic and not the use of network trace systems. The Investigation 454 request leverages the bilateral relationships or a consortium's 455 interconnections to mitigate or stop problematic traffic close to the 456 source. Routes could determine the fastest path to a known source IP 457 address in the case of an Investigation request. A message sent 458 between RID systems for a TraceRequest or an Investigation request to 459 stop traffic at the source through a bordering network requires the 460 information enumerated below: 462 1. Enough information to enable the network administrators to make a 463 decision about the importance of continuing the trace. 465 2. The incident or IP packet information needed to carry out the 466 trace or investigation. 468 3. Contact information of the origin of the RID communication. The 469 contact information could be provided through the Autonomous 470 System Number (ASN) [RFC1930] or Network Information Center (NIC) 471 handle information listed in the Registry for Internet Numbers or 472 other Internet databases. 474 4. Network path information to help prevent any routing loops 475 through the network from perpetuating a trace. If a RID system 476 receives a TraceRequest containing its own information in the 477 path, the trace must cease and the RID system should generate an 478 alert to inform the network operations staff that a tracing loop 479 exists. 481 5. A unique identifier for a single attack. This identifier should 482 be used to correlate traces to multiple sources in a DDoS attack. 484 Use of the communication network and the RID protocol must be for 485 pre-approved, authorized purposes only. It is the responsibility of 486 each participating party to adhere to guidelines set forth in both a 487 global use policy established through the peering agreements for each 488 bilateral peer or agreed-upon consortium guidelines. The purpose of 489 such policies is to avoid abuse of the system; the policies shall be 490 developed by a consortium of participating entities. The global 491 policy may be dependent on the domain it operates under; for example, 492 a government network or a commercial network such as the Internet 493 would adhere to different guidelines to address the individual 494 concerns. Privacy issues must be considered in public networks such 495 as the Internet. Privacy issues are discussed in the Security 496 Requirements section, along with other requirements that must be 497 agreed upon by participating entities. 499 RID requests must be legitimate incidents and not used for purposes 500 such as sabotage or censorship. An example of such abuse of the 501 system includes a request to rate-limit legitimate traffic to prevent 502 information from being shared between users on the Internet 503 (restricting access to online versions of papers) or restricting 504 access from a competitor's product in order to sabotage a business. 506 The RID system should be configurable to either require user input or 507 automatically continue traces. This feature enables a network 508 manager to assess the available resources before continuing an 509 investigation or trace. If the Confidence rating (provided in IODEF) 510 is low, it may not be in the provider's best interest to continue the 511 investigation or trace. The Confidence ratings must adhere to the 512 specifications for selecting the percentage used to avoid abuse of 513 the system. TraceRequests must be issued by authorized individuals 514 from the initiating CSIRT, set forth in policy guidelines established 515 through peering or a SLA. 517 3.2. RID Communication Topology 519 The most basic topology for communicating RID systems is a direct 520 connection or a bilateral relationship as illustrated below. 522 ___________ __________ 523 | | | | 524 | RID |__________-------------___________| RID | 525 |_________| | SP Border | |________| 526 ------------- 528 Figure 1: Direct Peer Topology 530 Within the consortium model, several topologies might be agreed upon 531 and used. One would leverage bilateral network peering relationships 532 of the members of the consortium. The peers for RID would match that 533 of routing peers, and the logical network borders would be used. 534 This approach may be necessary for an iterative trace where the 535 source is unknown. The model looks like the above diagram; however, 536 there may be an extensive number of interconnections of bilateral 537 relationships formed. Also within a consortium model, it may be 538 useful to establish an integrated mesh of networks to pass RID 539 messages. This may be beneficial when the source address is known, 540 and an interconnection may provide a faster route to reach the 541 closest upstream peer to the source of the attack traffic if direct 542 communication between SPs is not possible. An example is illustrated 543 below. 545 _______ _______ _______ 546 | | | | | | 547 __| RID |____-------------____| RID |____-------------____| RID |__ 548 |_____| | SP Border | |_____| | SP Border | |_____| 549 | ------------- ------------- | 550 |_______________________________________________________| 552 Direct connection to network that is not an immediate network peer 554 Figure 2: Mesh Peer Topology 556 By using a fully meshed model in a consortium, broadcasting RID 557 requests would be possible, but not advisable. By broadcasting a 558 request, RID peers that may not have carried the attack traffic on 559 their network would be asked to perform a trace for the potential of 560 decreasing the time in which the true source was identified. As a 561 result, many networks would have utilized unnecessary resources for a 562 TraceRequest that may have also been unnecessary. 564 A star topology may be desirable in instances where a peer may be a 565 provider of incident information. This requires trust relationships 566 to be established between the provider of information and each of the 567 consumers of that information. Examples may include country level 568 CSIRTs or service providers distributing incident information to 569 organizations. 571 3.3. Message Formats 573 Section 3.5 describes the six RID message types, which leverage the 574 IODEF model [RFC5070]. The messages are generated and received on 575 designated systems for RID communication on the provider's network. 576 The messages may originate from IODEF documents from intrusion 577 detection servers, CSIRTs, analysts, etc. A RID message uses the 578 IODEF document with the RID extension, which is encapsulated for 579 transport [RFC6046-bis]. Each RID message type, along with an 580 example, is described in the following sections. The IODEF-RID 581 schema is introduced in Section 4 to support the RID message types in 582 Section 3.5. The term service provider (SP), used in the following 583 sections should be interpreted as any type of service provider or 584 CSIRT that may be involved in RID communications. 586 3.4. RID Data Types 588 RID is derived from the IODEF data model and inherits all of the data 589 types defined in the IODEF model. One data type is added by RID: 590 BOOLEAN. 592 3.4.1. Boolean 594 A boolean value is represented by the BOOLEAN data type. 596 The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in 597 the schema. 599 3.5. RID Message Types 601 The six RID message types are as follows: 603 1. TraceRequest. This message is sent to the next provider in the 604 upstream trace. It is used to initiate a TraceRequest or to 605 continue a TraceRequest to an upstream provider closer to the 606 source address of the origin of the security incident. The 607 TraceRequest triggers a traceback on the network to locate the 608 source of the attack traffic. 610 2. RequestAuthorization. This message is sent to the initiating RID 611 system from each of the upstream providers' RID systems to 612 provide information on the request status in the current network. 614 3. Result. This message is sent to the initiating CSIRT through the 615 network of RID systems in the path of the trace as notification 616 that the source of the attack was located. The Result message is 617 also used to provide the notification of actions taken for an 618 Investigation request. 620 4. Investigation. This message type is used when the source of the 621 traffic is believed not to be spoofed. The purpose of the 622 Investigation request message is to leverage the existing peer 623 relationships in order to notify the network provider closest to 624 the source of the valid traffic of a security-related incident 625 for any necessary actions to be taken. 627 5. Report. This message is used to report a security incident, for 628 which no action is requested. This may be used for the purpose 629 of correlating attack information by CSIRTs, sharing incident 630 information, statistics and trending information, etc. 632 6. IncidentQuery. This message is used to request information about 633 an incident or incident type from a trusted system communicating 634 via RID. The response is provided through the Report message. 636 When an application receives a RID message, it must be able to 637 determine the type of message and parse it accordingly. The message 638 type is specified in the RIDPolicy class. The RIDPolicy class may 639 also be used by the transport protocol to facilitate the 640 communication of security incident data to trace, investigate, query, 641 or report information regarding security incidents. 643 4. IODEF-RID Schema 645 There are three classes included in the RID extension required to 646 facilitate RID communications. The RequestStatus class is used to 647 indicate the approval status of a TraceRequest or Investigation 648 request; the IncidentSource class is used to report whether or not a 649 source was found and to identify the source host(s) or network(s); 650 and the RIDPolicy class provides information on the agreed-upon 651 policies and specifies the type of communication message being used. 653 The RID schema acts as an envelope for the IODEF schema to facilitate 654 RID communications. The intent in maintaining a separate schema and 655 not using the AdditionalData extension of IODEF is the flexibility of 656 sending messages between RID hosts. Since RID is a separate schema 657 that includes the IODEF schema, the RID information acts as an 658 envelope, and then the RIDPolicy class can be easily extracted for 659 use by the transport protocol. 661 The security requirements of sending incident information across the 662 network include the use of encryption. The RIDPolicy information is 663 not required to be encrypted, so separating out this data from the 664 IODEF extension removes the need for decrypting and parsing the 665 entire IODEF and RID document to determine how it should be handled 666 at each RID host. 668 The purpose of the RIDPolicy class is to specify the message type for 669 the receiving host, facilitate the policy needs of RID, and provide 670 routing information in the form of an IP address of the destination 671 RID system. 673 The policy information and guidelines are discussed in Section 8.7. 674 The policy is defined between RID peers and within or between 675 consortiums. The RIDPolicy is meant to be a tool to facilitate the 676 defined policies. This MUST be used in accordance with policy set 677 between clients, peers, consortiums, and/or regions. Security, 678 privacy, and confidentiality MUST be considered as specified in this 679 document. 681 The RID schema is defined as follows: 683 +------------------+ 684 | RID | 685 +------------------+ 686 | ANY | 687 | |<>---{0..1}----[ RIDPolicy ] 688 | ENUM restriction | 689 | ENUM type |<>---{0..1}----[ RequestStatus ] 690 | STRING meaning | 691 | |<>---{0..1}----[ IncidentSource ] 692 +------------------+ 694 Figure 3: The RID Schema 696 The aggregate classes that constitute the RID schema in the iodef-rid 697 namespace are as follows: 699 RIDPolicy 701 Zero or One. The RIDPolicy class is used by all message types to 702 facilitate policy agreements between peers, consortiums, or 703 federations, as well as to properly route messages. 705 RequestStatus 707 Zero or One. The RequestStatus class is used only in 708 RequestAuthorization messages to report back to the CSIRT or SP 709 originating the RID trace will be continued by each RID system 710 that received a TraceRequest in the path to the source of the 711 traffic. 713 IncidentSource 715 Zero or One. The IncidentSource class is used in the Result 716 message only. The IncidentSource provides the information on the 717 identified source host or network of an attack trace or 718 investigation. 720 Each of the three listed classes may be the only class included in 721 the RID class, hence the option for zero or one. In some cases, 722 RIDPolicy MAY be the only class in the RID definition when used by 723 the transport protocol [RFC6046-bis], as that information should be 724 as small as possible and may not be encrypted. The RequestStatus 725 message MUST be able to stand alone without the need for an IODEF 726 document to facilitate the communication, limiting the data 727 transported to the required elements per [RFC6046-bis]. 729 4.1. RIDPolicy Class 731 The RIDPolicy class facilitates the delivery of RID messages and is 732 also referenced for transport in the transport document [RFC6046- 733 bis]. 735 +------------------------+ 736 | RIDPolicy | 737 +------------------------+ 738 | | 739 | ENUM restriction |<>-------------[ Node ] 740 | ENUM MsgType | 741 | ENUM MsgDestination |<>---{0..1}----[ IncidentID ] 742 | ENUM ext-MsgType | 743 | ENUM ext-MsgDestination|<>---{1..*}----[ PolicyRegion ] 744 | | 745 | |<>---{1..*}----[ TrafficType ] 746 | | 747 +------------------------+ 749 Figure 4: The RIDPolicy Class 751 The aggregate elements that constitute the RIDPolicy class are as 752 follows: 754 Node 756 One. The Node class is used to identify a host or network device, 757 in this case to identify the system communicating RID messages. 758 The base definition of this class is reused from the IODEF 759 specification [RFC5070], Section 3.16. 761 IncidentID 763 Zero or one. Global reference pointing back to the IncidentID 764 defined in the IODEF data model. The IncidentID includes the name 765 of the CSIRT, an incident number, and an instance of that 766 incident. The instance number is appended with a dash separating 767 the values and is used in cases for which it may be desirable to 768 group incidents. Examples of incidents that may be grouped 769 include botnets, polymorphic attacks, DDoS attacks, multiple hops 770 of compromised systems found during an investigation, etc. 772 PolicyRegion 774 One or many. REQUIRED. The values for the attribute "region" are 775 used to determine what policy area may require consideration 776 before a trace can be approved. The PolicyRegion may include 777 multiple selections from the attribute list in order to fit all 778 possible policy considerations when crossing regions, consortiums, 779 or networks. 781 region 783 One. ENUM. 785 1. ClientToSP. An enterprise initiated the request to their 786 service provider. 788 2. SPToClient. An service provider passed a RID request or 789 report to a client or an enterprise based on requested 790 services or service level agreements. 792 3. IntraConsortium. Incident information that should have no 793 restrictions within the boundaries of a consortium with the 794 agreed-upon use and abuse guidelines. 796 4. PeerToPeer. Incident information that should have no 797 restrictions between two peers but may require further 798 evaluation before continuance beyond that point with the 799 agreed-upon use and abuse guidelines. 801 5. BetweenConsortiums. Incident information that should have no 802 restrictions between consortiums that have established agreed- 803 upon use and abuse guidelines. 805 6. AcrossNationalBoundaries. This selection must be set if the 806 message type will cross national boundaries. There could be 807 instances of TraceRequest messages where that may not be known 808 in advance, but should be known at the instance where 809 boundaries are crossed during the investigation. This must 810 also be set if the security requirements of the request is 811 based upon regulations of a specific nation that may not apply 812 to all nations. The stricter requirements should be upheld. 813 This is different from the "BetweenConsortiums" setting since 814 it may be possible to have multiple nations as members of the 815 same consortium, and this option must be selected if the 816 traffic is of a type that may have different restrictions in 817 other nations. 819 7. LawEnforcement. This option is used when incident information 820 is exchanged with LawEnforcement, local government, or other 821 authorities assisting with an investigation. If the law 822 enforcement agency resides within a different nation that the 823 sending entity, the "AcrossNationalBoundaries" enumeration 824 MUST also be set. 826 8. ext-value. An escape value used to extend this attribute. 827 See IODEF [RFC5070], Section 5.1. 829 TrafficType 831 One or many. REQUIRED. The values for the attribute "type" are 832 meant to assist in determining if a trace is appropriate for the 833 SP (provider) receiving the request to continue the trace. 834 Multiple values may be selected for this element; however, where 835 possible, it should be restricted to one value that most 836 accurately describes the traffic type. 838 type 840 One. ENUM. 842 1. Attack. This option should only be selected if the traffic is 843 related to a network-based attack. The type of attack MUST 844 also be listed in more detail in the IODEF Method and Impact 845 classes for further clarification to assist in determining if 846 the trace can be continued ([RFC5070], Sections 3.9 and 847 3.10.1). 849 2. Network. This option MUST only be selected when the trace is 850 related to network traffic or routing issues. 852 3. Content. This category MUST be used only in the case in which 853 the request is related to the content and regional 854 restrictions on accessing that type of content exist. This is 855 not malicious traffic but may include determining what sources 856 or destinations accessed certain materials available on the 857 Internet, including, but not limited to, news, technology, or 858 inappropriate content. 860 4. OfficialBusiness. This option MUST be used if the incident 861 information is requested by or affiliated with any government 862 or other official business request. This could be used during 863 an investigation by government authorities or other government 864 incident investigations to track suspected criminal or other 865 activities. 867 5. Other. If this option is selected, a description of the 868 traffic type MUST be provided so that policy decisions can be 869 made to continue or stop the investigation. The information 870 should be provided in the IODEF message in the Expectation 871 class or in the History class using a HistoryItem log. 873 6. ext-value. An escape value used to extend this attribute. 874 See IODEF [RFC5070], Section 5.1. 876 The RIDPolicy class has five attributes: 878 restriction 880 OPTIONAL. ENUM. This attribute indicates the disclosure 881 guidelines to which the sender expects the recipient to adhere. 882 This guideline provides no real security since it is the choice 883 of the recipient of the document to honor it. This attribute 884 follows the same guidelines as "restriction" used in IODEF. 886 MsgType 888 REQUIRED. ENUM. The type of RID message sent. The six types 889 of messages are described in Section 3.5 and can be noted as 890 one of the six selections below. 892 2. TraceRequest. This message may be used to initiate a 893 TraceRequest or to continue a TraceRequest to an upstream 894 network closer to the source address of the origin of the 895 security incident. 897 3. RequestAuthorization. This message is sent to the initiating 898 RID system from each of the upstream RID systems to provide 899 information on the request status in the current network. 901 4. Result. This message indicates that the source of the attack 902 was located and the message is sent to the initiating RID 903 system through the RID systems in the path of the trace. 905 5. Investigation. This message type is used when the source of 906 the traffic is believed to be valid. The purpose of the 907 Investigation request is to leverage the existing peer or 908 consortium relationships in order to notify the network or 909 service provider closest to the source of the valid traffic 910 that some event occurred, which may be a security-related 911 incident. 913 6. Report. This message is used to report a security incident, 914 for which no action is requested in the IODEF Expectation 915 class. This may be used for the purpose of correlating attack 916 information by CSIRTs, statistics and trending information, 917 etc. 919 7. IncidentQuery. This message is used to request information 920 from a trusted RID system about an incident or incident type. 922 Additionally, there is an extension attribute to add new 923 enumerated values: 925 ext-value. An escape value used to extend this attribute. See 926 IODEF [RFC5070], Section 5.1. 928 MsgDestination 930 REQUIRED. ENUM. The destination required at this level may 931 either be the RID messaging system intended to receive the 932 request, or, in the case of an Investigation request, the 933 source of the incident. In the case of an Investigation 934 request, the RID system that can help stop or mitigate the 935 traffic may not be known, and the message may have to traverse 936 RID messaging systems by following the routing path to the RID 937 system closest to the source of the attack traffic. The Node 938 element lists either the RID system or the IP address of the 939 source, and the meaning of the value in the Node element is 940 determined by the MsgDestination element. 942 1. RIDSystem. The address listed in the Node element of the 943 RIDPolicy class is the next upstream RID system that will 944 receive the RID message. 946 2. SourceOfIncident. The address listed in the Node element 947 of the RIDPolicy class is the incident source. The IP 948 address is used to determine the path of systems accepting 949 RID communications that will be used to find the closest 950 RID system to the source of an attack in which the IP 951 address used by the source is believed to be valid and an 952 Investigation request message is used. This is not to be 953 confused with the IncidentSource class, as the defined 954 value here is from an initial trace or Investigation 955 request, not the source used in a Result message. 957 3. ext-value. An escape value used to extend this attribute. 958 See IODEF [RFC5070], Section 5.1. 960 MsgType-ext 962 OPTIONAL. STRING. A means by which to extend the MsgType 963 attribute. See IODEF [RFC5070], Section 5.1. 965 MsgDestination-ext 967 OPTIONAL. STRING. A means by which to extend the 968 MsgDestination attribute. See IODEF [RFC5070], Section 5.1 970 4.2. RequestStatus 972 The RequestStatus class is an aggregate class in the RID class. 974 +--------------------------------+ 975 | RequestStatus | 976 +--------------------------------+ 977 | | 978 | ENUM restriction | 979 | ENUM AuthorizationStatus | 980 | ENUM Justification | 981 | STRING ext-AuthorizationStatus | 982 | STRING ext-Justification | 983 | | 984 +--------------------------------+ 986 Figure 5: The RequestStatus Class 988 The RequestStatus class has five attributes: 990 restriction 992 OPTIONAL. ENUM. This attribute indicates the disclosure 993 guidelines to which the sender expects the recipient to adhere. 994 This guideline provides no real security since it is the choice 995 of the recipient of the document to honor it. This attribute 996 follows the same guidelines as "restriction" used in IODEF. 998 AuthorizationStatus 1000 REQUIRED. ENUM. The listed values are used to provide a 1001 response to the requesting CSIRT of the status of a 1002 TraceRequest in the current network. 1004 1. Approved. The trace was approved and will begin in the 1005 current SP. 1007 2. Denied. The trace was denied in the current SP. The next 1008 closest SP can use this message to filter traffic from the 1009 upstream SP using the example packet to help mitigate the 1010 effects of the attack as close to the source as possible. 1011 The RequestAuthorization message must be passed back to the 1012 originator and a Result message used from the closest SP to 1013 the source to indicate actions taken in the IODEF History 1014 class. 1016 3. Pending. Awaiting approval; a timeout period has been 1017 reached, which resulted in this Pending status and 1018 RequestAuthorization message being generated. 1020 4. ext-value. An escape value used to extend this attribute. 1021 See IODEF [RFC5070], Section 5.1. 1023 Justification 1025 OPTIONAL. ENUM. Provides a reason for a Denied or Pending 1026 message. 1028 2. SystemResource. A resource issue exists on the systems 1029 that would be involved in the request. 1031 3. Authentication. The enveloped digital signature [RFC3275] 1032 failed to validate. 1034 4. AuthenticationOrigin. The detached digital signature for 1035 the original requestor on the RecordItem entry failed to 1036 validate. 1038 5. Encryption. Unable to decrypt the request. 1040 6. Other. There were other reasons this request could not be 1041 processed. 1043 7. ext-value. An escape value used to extend this attribute. 1044 See IODEF [RFC5070], Section 5.1. 1046 AuthorizationStatus-ext 1048 OPTIONAL. STRING. A means by which to extend the 1049 AuthorizationStatus attribute. See IODEF [RFC5070], Section 1050 5.1. 1052 Justification-ext 1054 OPTIONAL. STRING. A means by which to extend the 1055 Justification attribute. See IODEF [RFC5070], Section 5.1. 1057 4.3. IncidentSource 1059 The IncidentSource class is an aggregate class in the RID class. 1061 +-------------------+ 1062 | IncidentSource | 1063 +-------------------+ 1064 | | 1065 | ENUM restriction | 1066 | |<>-------------[ SourceFound ] 1067 | | 1068 | |<>---{0..*}----[ Node ] 1069 | | 1070 +-------------------+ 1072 Figure 6: The IncidentSource Class 1074 The elements that constitute the IncidentSource class follow: 1076 SourceFound 1078 One. BOOLEAN. The Source class indicates if a source was 1079 identified. If the source was identified, it is listed in the 1080 Node element of this class. 1082 True. Source of incident was identified. 1084 False. Source of incident was not identified. 1086 Node 1088 One. The Node class is used to identify a host or network 1089 device, in this case to identify the system communicating RID 1090 messages. 1092 The base definition of this class is reused from the IODEF 1093 specification [RFC5070], Section 3.16. 1095 The IncidentSource class has one attribute: 1097 restriction 1099 OPTIONAL. ENUM. This attribute indicates the disclosure 1100 guidelines to which the sender expects the recipient to adhere. 1101 This guideline provides no real security since it is the choice 1102 of the recipient of the document to honor it. This attribute 1103 follows the same guidelines as "restriction" used in IODEF. 1105 4.4. RID Name Spaces 1107 The RID schema declares a namespace of "iodef-rid-1.1" and registers 1108 it per [XMLNames]. Each IODEF-RID document MUST use the 1109 "iodef-rid-1.1" namespace in the top-level element RID-Document. It 1110 can be referenced as follows: 1112 1117 5. RID Messages 1119 The IODEF model is followed as specified in [RFC5070] for each of the 1120 RID message types. The RID schema is used in combination with IODEF 1121 documents to facilitate RID communications. Each message type varies 1122 slightly in format and purpose; hence, the requirements vary and are 1123 specified for each. All classes, elements, attributes, etc., that 1124 are defined in the IODEF-Document are valid in the context of a RID 1125 message; however, some listed as optional in IODEF are mandatory for 1126 RID as listed for each message type. The IODEF model MUST be fully 1127 implemented to ensure proper parsing of all RID messages. 1129 Note: The implementation of RID may automate the ability to fill in 1130 the content required for each message type from packet input, 1131 incident data, situational awareness information, or default values 1132 such as that used in the EventData class. 1134 5.1. TraceRequest 1136 Description: This message or document is sent to the network 1137 management station next in the upstream trace once the upstream 1138 source of the traffic has been identified. The following information 1139 is required for TraceRequest messages and is provided through: 1141 RID Information: 1143 RIDPolicy 1145 RID message type, IncidentID, and destination policy 1146 information 1148 IODEF Information: 1150 Time Stamps (DetectTime, StartTime, EndTime, ReportTime). 1152 Incident Identifier (Incident class, IncidentID). 1154 Confidence rating of security incident (Impact and Confidence 1155 class). 1157 System class is used to list both the Source and Destination. 1159 Expectation class should be used to request any specific actions 1160 to be taken close to the source. 1162 Path information of nested RID systems, beginning with the request 1163 originator used in the trace using IODEF EventData with category 1164 set to "infrastructure". 1166 Event, Record, and RecordItem classes to include example packets 1167 and other information related to the incident. Note: Event 1168 information included here requires a second instance of EventData 1169 in addition to that used to convey service/network provider (SP) 1170 path contact information. 1172 Standards for encryption and digital signatures [RFC3275], [XMLsig]: 1174 Digital signature from initiating CSIRT or provider system sending 1175 the RID message, passed to all systems in upstream trace using a 1176 detached XML digital signature on a RecordItem entry. 1178 Digital signature of sending CSIRT or SP for authenticity of the 1179 RID message, from the CSIRT or provider creating this message 1180 using an enveloped XML digital signature on the IODEF document. 1182 XML encryption as required by policy, agreements, and data 1183 markers. 1185 A DDoS attack can have many sources, resulting in multiple traces to 1186 locate the sources of the attack. It may be valid to continue 1187 multiple traces for a single attack. The path information enables 1188 the administrators to determine if the exact trace had already passed 1189 through a single network. The Incident Identifier must also be used 1190 to identify multiple TraceRequests from a single incident. If a 1191 single TraceRequest results in divergent paths of TraceRequests, a 1192 separate instance number MUST be used under the same IncidentID. The 1193 IncidentID instance number of IODEF can be used to correlate related 1194 incident data that is part of a larger incident. 1196 5.2. RequestAuthorization 1198 Description: This message is sent to the initiating RID system from 1199 the next upstream provider's application or system designated for 1200 accepting RID communications to provide information on the request 1201 status in the current network. 1203 The following information is required for RequestAuthorization 1204 messages and is provided through: 1206 RID Information: 1208 RIDPolicy 1210 RID message type, IncidentID, and destination policy 1211 information 1213 RequestStatus class: 1215 Status of TraceRequest 1217 Standards for encryption and digital signatures [RFC3275], [XMLsig]: 1219 Digital signature of responding CSIRT or provider for authenticity 1220 of Trace Status Message, from the CSIRT or provider creating this 1221 message using an enveloped XML digital signature. 1223 XML encryption as required by policy, agreements, and data 1224 markers. 1226 A message is sent back to the initiating CSIRT or provider's system 1227 accepting RID communications of the trace as status notification. 1228 This message verifies that the next RID system in the path has 1229 received the message from the previous system in the path. This 1230 message also verifies that the trace is now continuing, has stopped, 1231 or is pending in the next upstream CSIRT or provider's RID system. 1232 The Pending status is automatically generated after a 2-minute 1233 timeout without system-predefined or administrator action taken to 1234 approve or disapprove the trace continuance. If a Request is denied, 1235 the originator and sending peer (if they are not the same) MUST both 1236 receive the message. This enables the sending peer the option to 1237 take action to stop or mitigate the traffic as close to the source as 1238 possible. 1240 5.3. Result 1242 Description: This message indicates that the trace or investigation 1243 has been completed and provides the result. The Result message 1244 includes information on whether or not a source was found and the 1245 source information through the IncidentSource class. The Result 1246 information MUST go back to the originating RID system that began the 1247 investigation or trace. An provider may use any number of incident 1248 handling data sources to ascertain the true source of an attack. All 1249 of the possible information sources may or may not be readily tied 1250 into the RID communications system. 1252 The following information is required for Result messages and will be 1253 provided through: 1255 RID Information: 1257 RIDPolicy 1259 RID message type, IncidentID, and destination policy 1260 information 1262 Incident Source 1264 The IncidentSource class of the RID schema is used to note 1265 if a source was identified and provide the source 1266 address(es). 1268 IODEF Information: 1270 Time Stamps (DetectTime, StartTime, EndTime, ReportTime). 1272 Incident Identifier (Incident class, IncidentID). 1274 Trace number - used for multiple traces of a single 1275 incident; must be noted. 1277 Confidence rating of security incident (Impact and Confidence 1278 class). 1280 System class is used to list both the Source and Destination 1281 Information used in the attack and must note if the traffic is 1282 spoofed, thus requiring an upstream TraceRequest in RID. 1284 History class "atype" attribute is used to note any actions 1285 taken. 1287 History class also notes any other background information 1288 including notes about the confidence level or rating of the 1289 result information. 1291 Path information of nested RID systems, beginning with the 1292 request originator used in the trace using IODEF EventData with 1293 category set to "infrastructure". The last SP listed is the SP 1294 that located the source of the traffic (the provider sending 1295 the Result message). 1297 Event, Record, and RecordItem classes to include example 1298 packets and other information related to the incident 1299 (optional). Note: Event information included here requires a 1300 second instance of EventData in addition to that used to convey 1301 SP path contact information. 1303 Standards for encryption and digital signatures [RFC3275]: 1305 Digital signature of source CSIRT or provider for authenticity 1306 of Result message, from the CSIRT or provider creating this 1307 message using an enveloped XML digital signature. 1309 XML encryption as required by policy, agreements, and data 1310 markers. 1312 A message is sent back to the initiating CSIRT or provider's RID 1313 system to notify the CSIRT that the source has been located. The 1314 actual source information may or may not be included, depending on 1315 the policy of the network in which the client or host is attached. 1316 Any action taken by the SP to act upon the discovery of the source of 1317 a trace should be included. The SP may be able to automate the 1318 adjustment of filters at their border router to block outbound access 1319 for the machine(s) discovered as a part of the attack. The filters 1320 may be comprehensive enough to block all Internet access until the 1321 host has taken the appropriate action to resolve any security issues 1322 or to rate-limit the ingress traffic as close to the source as 1323 possible. 1325 Security and privacy requirements discussed in Section 8 MUST be 1326 taken into account. 1328 Note: The History class has been expanded in IODEF to accommodate all 1329 of the possible actions taken as a result of a RID TraceRequest or 1330 Investigation request using the "iodef:atype", or action type, 1331 attribute. The History class should be used to note all actions 1332 taken close to the source of a trace or incident using the most 1333 appropriate option for the type of action along with a description. 1334 The "atype" attribute in the Expectation class can also be used to 1335 request an appropriate action when a TraceRequest or Investigation 1336 request is made. 1338 5.4. Investigation Request 1340 Description: This message type is used when the source of the traffic 1341 is believed not to be spoofed. The purpose of the Investigation 1342 request message is to leverage the existing bilateral peer 1343 relationships in order to notify the network provider closest to the 1344 source of the valid traffic that some event occurred, which may be a 1345 security-related incident. 1347 The following information is required for Investigation request 1348 messages and is provided through: 1350 RID Information: 1352 RID Policy 1354 RID message type, IncidentID, and destination policy 1355 information 1357 IODEF Information: 1359 Time Stamps (DetectTime, StartTime, EndTime, ReportTime). 1361 Incident Identifier (Incident class, IncidentID). 1363 Trace number - used for multiple traces of a single 1364 incident; must be noted. 1366 Confidence rating of security incident (Impact and Confidence 1367 class). 1369 System class is used to list both the Source and Destination 1370 Information used in the attack and must note if the traffic is 1371 spoofed, thus requiring an upstream TraceRequest in RID. 1373 Expectation class should be used to request any specific 1374 actions to be taken close to the source. 1376 Path information of nested systems communicating via RID 1377 messages, beginning with the request originator used in the 1378 trace using IODEF EventData with category set to 1379 "infrastructure". 1381 Event, Record, and RecordItem classes to include example 1382 packets and other information related to the incident. Note: 1383 Event information included here requires a second instance of 1384 EventData in addition to that used to convey SP path contact 1385 information. 1387 Standards for encryption and digital signatures [RFC3275]: 1389 Digital signature from initiating system sending the RID 1390 message, passed to all systems involved in the investigation 1391 using a detached XML digital signature on a RecordItem entry. 1393 Digital signature of sending CSIRT or SP for authenticity of 1394 the RID message, from the CSIRT or provider sending this 1395 message using an enveloped XML digital signature on the IODEF 1396 document. 1398 XML encryption as required by policy, agreements, and data 1399 markers. 1401 Security requirements include the ability to encrypt [XMLencrypt] the 1402 contents of the Investigation request message using the public key of 1403 the destination RID system. The incident number increases as if it 1404 were a TraceRequest message in order to ensure uniqueness within the 1405 system. The relaying peers also append their Autonomous System (AS) 1406 or RID system information as the request message was relayed along 1407 the web of network providers so that the Result message could utilize 1408 the same path as the set of trust relationships for the return 1409 message, thus indicating any actions taken. The request is recorded 1410 in the state tables of both the initiating and destination SP RID 1411 systems. The destination SP is responsible for any actions taken as 1412 a result of the request in adherence to any service level agreements 1413 or internal policies. The SP MUST confirm that the traffic actually 1414 originated from the suspected system before taking any action and 1415 confirm the reason for the request. The request may be sent directly 1416 to a known RID system or routed by the source address of the attack 1417 using the message destination of RIDPolicy, SourceOfIncident. Note: 1418 All intermediate parties MUST be able to view RIDPolicy information 1419 in order to properly direct RID messages. 1421 5.5. Report 1423 Description: This message or document is sent to a RID system to 1424 provide a report of a security incident. This message does not 1425 require any actions to be taken, except to file the report on the 1426 receiving RID system or associated database. 1428 The following information is required for Report messages and will be 1429 provided through: 1431 RID Information: 1433 RID Policy RID message type, IncidentID, and destination policy 1434 information 1436 The following data is recommended if available and can be provided 1437 through: 1439 IODEF Information: 1441 Time Stamps (DetectTime, StartTime, EndTime, ReportTime). 1443 Incident Identifier (Incident class, IncidentID). Trace number 1444 - used for multiple traces of a single incident; must be noted. 1446 Confidence rating of security incident (Impact and Confidence 1447 class). 1449 System class is used to list both the Source and Destination 1450 Information used in the attack. 1452 Event, Record, and RecordItem classes to include example 1453 packets and other information related to the incident 1454 (optional). 1456 Standards for encryption and digital signatures [RFC3275]: 1458 Digital signature from initiating RID system, passed to all 1459 systems receiving the report using an enveloped XML digital 1460 signature. 1462 XML encryption as required by policy, agreements, and data 1463 markers. 1465 Security requirements include the ability to encrypt [XMLencrypt] the 1466 contents of the Report message using the public key of the 1467 destination RID system. Senders of a Report message should note that 1468 the information may be used to correlate security incident 1469 information for the purpose of trending, pattern detection, etc., and 1470 may be shared with other parties unless otherwise agreed upon with 1471 the receiving RID system. Therefore, sending parties of a Report 1472 message may obfuscate or remove destination addresses or other 1473 sensitive information before sending a Report message. A Report 1474 message may be sent either to file an incident report or in response 1475 to an IncidentQuery, and data sensitivity must be considered in both 1476 cases. The SP path information is not necessary for this message, as 1477 it will be communicated directly between two trusted RID systems. 1479 5.6. IncidentQuery 1481 Description: The IncidentQuery message is used to request incident 1482 information from a trusted RID system. The request can include the 1483 incident number, if known, or detailed information about the 1484 incident. If the incident number is known, the Report message 1485 containing the incident information can easily be returned to the 1486 trusted requestor using automated methods. If an example packet or 1487 other unique information is included in the IncidentQuery, the return 1488 report may be automated; otherwise, analyst intervention may be 1489 required. 1491 The following information must be used for an IncidentQuery message 1492 and is provided through: 1494 RID Information: 1496 RID Policy 1498 RID message type, IncidentID, and destination policy 1499 information 1501 IODEF Information (optional): 1503 Time Stamps (DetectTime, StartTime, EndTime, ReportTime). 1505 Incident Identifier (Incident class, IncidentID). 1507 Trace number - used for multiple traces of a single 1508 incident; must be noted. 1510 Confidence rating of security incident (Impact and Confidence 1511 class). 1513 System class is used to list both the Source and Destination 1514 Information used in the attack. 1516 Event, Record, and RecordItem classes to include example 1517 packets and other information related to the incident 1518 (optional). 1520 Standards for encryption and digital signatures [RFC3275]: 1522 Digital signature from the CSIRT or SP initiating the RID 1523 message, passed to all systems receiving the IncidentQuery 1524 using an enveloped XML digital signature. 1526 XML encryption as required by policy, agreements, and data 1527 markers. 1529 The proper response to the IncidentQuery message is a Report message. 1530 Multiple incidents may be returned for a single query if an incident 1531 type is requested. In this case, the receiving system sends an IODEF 1532 document containing multiple incidents or all instances of an 1533 incident. The system sending the reply may pre-set a limit to the 1534 number of documents returned in one report. The recommended limit is 1535 5, to prevent the documents from becoming too large. Other transfer 1536 methods may be suited better than RID for large transfers of data. 1538 The Confidence rating may be used in the IncidentQuery message to 1539 select only incidents with an equal or higher Confidence rating than 1540 what is specified. This may be used for cases when information is 1541 gathered on a type of incident but not on specifics about a single 1542 incident. Source and Destination Information may not be needed if 1543 the IncidentQuery is intended to gather data about a specific type of 1544 incident as well. 1546 6. RID Communication Exchanges 1548 The following section outlines the communication flows for RID and 1549 also provides examples of messages. 1551 Note: For each example listed below, [RFC5735] addresses were used. 1552 Assume that each IP address listed is actually a separate network 1553 range held by different SPs. Addresses were used from /27 network 1554 ranges. 1556 6.1. Upstream Trace Communication Flow 1558 The diagram below outlines the RID TraceRequest communication flow 1559 between RID systems on different networks tracing an attack. SP-1, 1560 SP-2, SP-3 represent service or network providers that are involved 1561 in the example trace communication flow. 1563 Attack Dest SP-1 SP-2 SP-3 Attack Src 1565 1. Attack | Attack 1566 reported | detected 1568 2. Initiate trace 1570 3. Locate origin 1571 through 1572 upstream SP 1574 4. o---TraceRequest-----> 1576 5. Trace 1577 Initiated 1579 6. <-RequestAuthorization-o 1581 7. Locate origin 1582 through 1583 upstream SP 1585 8. o---TraceRequest---> 1587 9. Trace Initiated 1589 10. <----------RequestAuthorization----o 1590 <---RequestAuth---o 1592 11. Locate attack 1593 source on network X 1595 12. <------------Result----------------o 1597 Figure 7: TraceRequest Communication Flow 1599 Before a trace is initiated, the RID system should verify if an 1600 instance of the trace or a similar request is not active. The traces 1601 may be resource intensive; therefore, providers need to be able to 1602 detect potential abuse of the system or unintentional resource 1603 drains. Information such as the Source and Destination Information, 1604 associated packets, and the incident may be desirable to maintain for 1605 a period of time determined by administrators. 1607 The communication flow demonstrates that a RequestAuthorization 1608 message is sent to both the downstream peer and the original 1609 requestor. If a TraceRequest is denied, the downstream peer has the 1610 option to take an action and respond with a Result message. The 1611 originator of the request may follow up with the downstream peer of 1612 the SP involved using an Investigation request to ensure that an 1613 action is taken if no response is received. Nothing precludes the 1614 originator of the request from initiating a new TraceRequest 1615 bypassing the SP that denied the request, if a trace is needed beyond 1616 that point. Another option may be for the initiator to send an 1617 Investigation request to an SP upstream of the SP that denied the 1618 request if enough information was gathered to discern the true source 1619 of the attack traffic from the incident handling information. 1621 The proper response to a TraceRequest is a RequestAuthorization 1622 message. The RequestAuthorization message lets the requestor know if 1623 the trace will continue through the next upstream network. If there 1624 is a problem with the request, such as a failure to validate the 1625 digital signature or decrypt the request, a RequestAuthorization 1626 message MUST be sent to the requestor and the downstream peer (if 1627 they are not one and the same) providing the reason why the message 1628 could not be processed. Assuming that the trace continued, 1629 additional TraceRequests with the response of a RequestAuthorization 1630 message would occur passing the request upstream in the path to the 1631 source of the traffic related to the incident. Once a source is 1632 found, a Result message is sent to the originator of the trace, as 1633 determined by the SP path information provided through the document 1634 instance of EventData, where contact is set to "infrastructure". The 1635 SP path information is also used when sending the 1636 RequestAuthorization messages to the first entry (the trace 1637 originator) and the last nested entry (the downstream peer). The 1638 Result message is encrypted [XMLencrypt] for the originator providing 1639 information about the incident source and any actions taken. If the 1640 originator fails to decrypt or authenticate the Result message, a 1641 RequestAuthorization message is sent in response; otherwise, no 1642 return message is sent. If a RequestAuthorization message is sent 1643 with the RequestStatus set to Denied, a downstream peer receiving 1644 this message may choose to take action to stop or mitigate the 1645 traffic at that point in the network, as close to the source as 1646 possible. If the downstream peer chooses this option, it would send 1647 a Result message to the trace originator. 1649 6.1.1. RID TraceRequest Example 1651 The example listed is of a TraceRequest based on the incident report 1652 example from the IODEF document. The RID extension classes were 1653 included as appropriate for a TraceRequest message using the 1654 RIDPolicy class. The example given is that of a CSIRT reporting a 1655 DoS attack in progress to the upstream SP. The request asks the next 1656 SP to continue the trace and have the traffic mitigated closer to the 1657 source of the traffic. 1659 In the following example, use of [XMLsig] to generate digital 1660 signatures used SHA-1 following the guidance of [XMLsig] 1.0. 1661 Version 1.1 of [XMLsig] supports additional digest algorithms. 1663 1665 1667 1668 1669 192.0.2.3 1670 1671 1672 1673 CERT-FOR-OUR-DOMAIN#207-1 1674 1675 1676 1678 1680 1682 1683 1684 CERT-FOR-OUR-DOMAIN#207-1 1685 1686 2004-02-02T22:49:24+00:00 1687 2004-02-02T22:19:24+00:00 1688 2004-02-02T23:20:24+00:00 1689 Host involved in DoS attack 1690 1691 1692 1693 1694 Constituency-contact for 192.0.2.35 1695 1696 Constituency-contact@192.0.2.35 1697 1698 1699 1700 1701 1702 192.0.2.35 1703 1704 1705 1706 38765 1707 1708 1709 1710 1711 192.0.2.67 1712 1713 1714 1715 80 1716 1717 1718 1719 1720 1721 Rate-limit traffic close to source 1722 1723 1724 1725 1726 1727 The IPv4 packet included was used in the described attack 1728 1729 450000522ad9 1730 0000ff06c41fc0a801020a010102976d0050103e020810d9 1731 4a1350021000ad6700005468616e6b20796f7520666f7220 1732 6361726566756c6c792072656164696e6720746869732052 1733 46432e0a 1734 1735 1736 1737 1738 1739 1740 2001-09-14T08:19:01+00:00 1741 1742 CSIRT-FOR-OUR-DOMAIN#207-1 1743 1744 1745 Notification sent to next upstream SP closer to 192.0.2.35 1746 1747 1748 1749 1750 1752 1753 1756 1757 1758 1759 1760 1761 450000522ad9 1762 0000ff06c41fc0a801020a010102976d0050103e020810d9 1763 4a1350021000ad6700005468616e6b20796f7520666f7220 1764 6361726566756c6c792072656164696e6720746869732052 1765 46432e0a 1766 1767 1768 1769 1770 1771 1772 1773 1774 1777 1779 1780 1781 1783 1784 1786 KiI5+6SnFAs429VNwsoJjHPplmo= 1787 1788 1789 1790 VvyXqCzjoW0m2NdxNeToXQcqcSM80W+JMW+Kn01cS3z3KQwCPeswzg== 1791 1792 1793 1794 1795

/KaCzo4Syrom78z3EQ5SbbB4sF7ey80etKII864WF64B81uRpH5t9j 1796 QTxeEu0ImbzRMqzVDZkVG9xD7nN1kuFw==

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