idnits 2.17.1 draft-ietf-inch-rid-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3323. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3295. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3302. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3308. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 15 instances of lines with control characters in the document. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 685: '... header MUST be provided so that al...' RFC 2119 keyword, line 998: '... The IODEF model MUST be fully impleme...' RFC 2119 keyword, line 1039: '... policies. This MUST be used in accor...' RFC 2119 keyword, line 1041: '... confidentiality MUST be considered as...' RFC 2119 keyword, line 1368: '...based attack. The type of attack MUST...' (34 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o System use between peering consortiums MUST also adhere to any government communication regulations that apply between those two regions, such as encryption export and import restrictions. o System use between consortiums MUST not request traffic traces and actions beyond the scope intended and permitted by law or inter-consortium agreements. o System use between consortiums MUST respect national boundary issues and limit requests to appropriate system use and not to achieve their own agenda to limit or restrict traffic that is otherwise permitted within the country in which the peering consortium resides. -- 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 (August 21, 2006) is 6458 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) == Unused Reference: 'RFC791' is defined on line 3122, but no explicit reference was found in the text == Unused Reference: 'RFC1213' is defined on line 3126, but no explicit reference was found in the text == Unused Reference: 'RFC1215' is defined on line 3130, but no explicit reference was found in the text == Unused Reference: 'RFC2246' is defined on line 3136, but no explicit reference was found in the text == Unused Reference: 'RFC2256' is defined on line 3139, but no explicit reference was found in the text == Unused Reference: 'RFC2459' is defined on line 3142, but no explicit reference was found in the text == Unused Reference: 'RFC2527' is defined on line 3146, but no explicit reference was found in the text == Unused Reference: 'RFC2528' is defined on line 3150, but no explicit reference was found in the text == Unused Reference: 'RFC2723' is defined on line 3161, but no explicit reference was found in the text == Unused Reference: 'RFC2827' is defined on line 3164, but no explicit reference was found in the text == Unused Reference: 'RFC3821' is defined on line 3171, but no explicit reference was found in the text == Unused Reference: 'RFCXXXX' is defined on line 3179, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 3187, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 3190, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 3194, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 3201, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 3203, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 3206, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 3223, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 3227, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 3239, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 3243, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 3246, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 3250, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 3254, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 3259, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1215 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2256 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) ** Obsolete normative reference: RFC 2527 (Obsoleted by RFC 3647) ** Downref: Normative reference to an Informational RFC: RFC 2528 ** Downref: Normative reference to an Informational RFC: RFC 2723 -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCXXXX' -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- No information found for draft-saas-paper03 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' -- Possible downref: Non-RFC (?) normative reference: ref. '20' -- Possible downref: Non-RFC (?) normative reference: ref. '21' -- Possible downref: Non-RFC (?) normative reference: ref. '22' Summary: 15 errors (**), 0 flaws (~~), 30 warnings (==), 31 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Extended Incident Handling Working Group Kathleen M. Moriarty 2 draft-ietf-inch-rid-08.txt MIT Lincoln Laboratory 3 Expires: February 21, 2007 August 21, 2006 5 Incident Handling: 6 Real-time Inter-network Defense 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 Months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright (C) The Internet Society (2006). 33 Abstract 34 Network security incidents, such as system compromises, worms, 35 viruses, phishing incidents, and denial of service (DoS), typically 36 result in the loss of service, data, and resources both human and 37 system. Network Providers (NPs) need to be equipped and ready to 38 assist in communicating and tracing security incidents with tools 39 and procedures in place before the occurrence of an attack. This 40 paper outlines a proactive inter-network communication method to 41 facilitate sharing incident handling data and integrate existing 42 tracing mechanisms across NP boundaries to identify the source(s) 43 of an attack. The various methods implemented to detect and trace 44 attacks must be coordinated on the NPs' network as well as provide 45 a communication mechanism across network borders. It is imperative 46 that NPs have quick communication methods defined to enable 47 neighboring NPs to assist in reporting or tracking a security 48 incident across networks. A complete solution integrating incident 49 detection, source identification, reporting and communication 50 capabilities, and methods to stop attack traffic is necessary to 51 attain higher security levels on networks. Policy guidelines for 52 handling incidents are recommended and can be agreed upon by a 53 consortium using the security recommendations and considerations. 55 TABLE OF CONTENTS 57 Status of this Memo ................................................ 1 59 Abstract ........................................................... 1 61 1. Introduction .................................................... 4 62 1.1 Overview of Attack Types ................................... 5 64 2. Recommended Network Provider (NP) Technologies .................. 7 66 3. Characteristics of Attacks ...................................... 8 67 3.1 Tracing a Distributed Attack ............................... 10 68 3.1.1 Tracing Security Incidents ........................... 10 69 3.2 Trace Approaches ........................................... 11 70 3.2.1 Trace Approach via Traffic Flow Analysis ............. 11 71 3.2.2 Trace Approach via Hash-Based IP Traceback ........... 12 72 3.2.3 IP Marking ........................................... 13 73 3.2.4 Superset of Packet Information for Traces ............ 14 75 4. Communication Between Network Providers ......................... 15 76 4.1 Inter-Network Provider RID Messaging ....................... 16 77 4.2 RID Network Topology ....................................... 18 78 4.3 Message Formats ............................................ 19 79 4.3.1 RID Messages and Transport ........................... 19 80 4.3.2 RID Data Types ....................................... 20 81 4.3.3 IODEF-Document ...................................... 20 82 4.3.4 IODEF-RID Schema ..................................... 20 83 4.3.4.1 NPPath Class ................................... 23 84 4.3.4.2 TraceStatus Class .............................. 24 85 4.3.4.3 IncidentSource Class ........................... 25 86 4.3.4.4 RIDPolicy ..................................... 26 87 4.4 RID Documents Defined by Message Type Derived from IODEF ... 29 88 4.4.1 TraceRequest ......................................... 32 89 4.4.2 TraceAuthorization Message ........................... 32 90 4.4.3 Result Message ....................................... 33 91 4.4.4 Investigation Message Request ........................ 35 92 4.4.5 Report Message ....................................... 36 93 4.4.6 IncidentQuery ........................................ 37 94 4.5 RID Communication Exchanges ................................ 38 95 4.5.1 Upstream Trace Communication Flow .................... 38 96 4.5.1.1 RID TraceRequest Example ....................... 39 97 4.5.2 Investigation Request Communication Flow ............. 43 98 4.5.2.1 Example Investigation Request .................. 44 99 4.5.3 Report Communication ................................. 45 100 4.5.3.1 Report Example ................................. 45 101 4.5.4 IncidentQuery Communication Flow ..................... 46 102 4.5.4.1 IncidentQuery Example .......................... 46 104 5. RID Schema Definition ........................................... 48 105 6. Message Transport ............................................... 52 106 6.1 Message Delivery Protocol - Integrity and Authentication ... 52 107 6.2 Transport Communication .................................... 53 108 6.3 Authentication of RID Protocol ............................. 53 109 6.4 Authentication Considerations for a Multi-hop TraceRequest . 54 110 6.4.1 Public Key Infrastructures and Consortiums ........... 55 111 6.5 Privacy Concerns and System Use Guidelines ................. 56 113 7. Security Considerations ......................................... 60 115 8. IANA Considerations ............................................. 62 117 9. Summary ......................................................... 62 119 10. References ..................................................... 64 120 10.1 Acknowledgements .......................................... 67 121 10.2 Author Information ........................................ 67 123 Intellectual Property Statement .................................... 67 125 Disclaimer of Validity ............................................. 68 127 Copyright Statement ................................................ 68 129 Sponsor Information ................................................ 68 130 1. Introduction 132 Incident handling involves the detection and identification of the 133 source of an attack, whether it be a system compromise, socially 134 engineered phishing attack, or a denial of service attack. In 135 order to identify the source of an attack, there must be a way to 136 trace the attack traffic iteratively upstream through the network 137 to the source. In cases in which accurate records of an active 138 session between the victim system and the attacker or source 139 system are available, the source is easy to identify. The problem 140 of tracing incidents becomes more difficult when the source is 141 obscured or spoofed, logs are deleted, and the number of sources 142 is overwhelming. 144 Current approaches to mitigating the effects of security incidents 145 are aimed at identifying and filtering or rate-limiting packets 146 from attackers who seek to hide the origin of their attack by 147 source address spoofing from multiple locations. Measures can be 148 taken at network provider (NP) edge routers providing ingress, 149 egress, and broadcast filtering as a recommended best practice in 150 RFC2827. 152 Network providers have devised solutions, in-house or commercial, 153 to trace attacks across their backbone infrastructure to either 154 identify the source on their network or on the next upstream 155 network in the path to the source. Techniques, such as collecting 156 packets as traffic traverses the network, have been implemented to 157 provide the capability to trace attack traffic after an incident 158 has occurred. Other methods use packet-marking techniques or flow- 159 based traffic analysis to trace traffic across the network in real 160 time. The single-network trace mechanisms use similar information 161 across the individual networks to trace traffic. Problems may 162 arise when an attempt is made to have a trace continued through the 163 next upstream network since the trace mechanism and management may 164 vary. 166 In the case in which the traffic traverses multiple networks, there 167 is currently no established communication mechanism for continuing 168 the trace. If the next upstream network has been identified, a 169 phone call might be placed to contact the network administrators in 170 an attempt to have them continue the trace. A communication 171 mechanism is needed to facilitate the transfer of information to 172 continue traces accurately and efficiently to upstream networks. 173 The communication mechanism described in this paper, Real-time 174 Inter-network Defense (RID), takes into consideration the 175 information needed by various single network trace implementations 176 and the requirement for network providers to decide if a trace 177 request should be permitted to continue. The data in RID messages 178 will be represented in an Extensible Markup Language (XML) document 179 and is an extension of the Incident Data Exchange Format (IODEF) 180 model. By following this model, integration with other aspects of 181 the network for incident handling is simplified. Finally, methods 182 are incorporated into the communication system to indicate what 183 actions need to be taken closest to the source in order to halt or 184 mitigate the effects of the attack at hand. RID is intended to 185 provide a method to communicate the relevant information between 186 NPs while being compatible with a variety of existing and possible 187 future detection tracing and response approaches. 189 Security and privacy considerations are of high concern since 190 potentially sensitive information may be passed through RID 191 messages. RID messaging will take advantage of XML security, 192 security, and privacy policy information set in the RID schema. The 193 RID schema acts as an XML envelope to support the communication of 194 IODEF documents for exchanging or tracing information security 195 incidents. RID messages will be encapsulated in a SOAP wrapper. 196 The authentication, integrity, and authorization features each 197 layer has to offer will be used to achieve the level of security 198 that is necessary. SOAP is used as a message wrapper to direct 199 messages appropriately, and the SOAP binding will be used with a 200 specific transport protocol with HTTPS set as the mandatory to 201 implement protocol and others are optional such as BEEP, S/MIME, 202 XML SNMP, and others. 204 1.1 Overview of Attack Types 206 RID messaging is intended for use in coordinating incident handling 207 to locate the source of an attack and stop or mitigate the effects 208 of the attack. The attack types include system or network 209 compromises, denial of service attacks, or other malicious network 210 traffic. RID is essentially a messaging system coordinating attack 211 detection, tracing mechanisms, and the incident handling responses 212 to locate the source of traffic. If a source address is spoofed, a 213 more detailed trace of a packet (RID TraceRequest) would be 215 required to locate the true source. If the source address is 216 valid, the incident handling may only involve the use of routing 217 information to determine what network provider is closest to the 218 source (RID Investigation request) and can assist with the 219 remediation. The type of RID message used to locate a source is 220 determined by the validity of the source address. RID message 221 types are discussed in section 4.3. 223 The CERT Coordination Center published a paper in October 2001 224 entitled, "Trends in Denial of Service Attack Technology"[19]. The 225 paper outlined the behavior of denial-of-service attacks of both 226 single-source and multiple-source origins. Denial-of-service (DoS) 227 attacks attempt to consume bandwidth, processing power, or system 228 resources for the purposes of denying use by normal users. 229 Bandwidth or processing power-based attacks may use variations on 230 these packets, such as altering the source address, port numbers, 231 or TCP options. 233 DoS attacks are characterized by large amounts of traffic destined 234 for particular Internet locations and can originate from a single 235 or multiple sources. An attack from multiple sources is known as a 236 distributed denial-of-service attack (DDoS). Because DDoS attacks 237 can originate from multiple sources, tracing such an attack can be 238 extremely difficult or nearly impossible. Many TraceRequests may 239 be required to accomplish the task and may require the use of 240 dedicated network resources to communicate incident handling 241 information to prevent a DoS against the RID system and network 242 used for tracing and remediation. Provisions are suggested to 243 reduce the load and prevent the same trace from occurring twice on 244 a single-network backbone discussed in section 4 on communication 245 between NPs. The attacks can be launched from systems across the 246 Internet unified in their efforts or by compromised systems 247 enlisted as "zombies" that are controlled by servers, thereby 248 providing anonymity to the controlling server of the attack. This 249 scenario may require multiple RID traces, one to locate the zombies 250 and an additional one to locate the controlling server. DDoS 251 attacks do not necessarily spoof the source of an attack since 252 there are a large number of source addresses, which make it 253 difficult to trace anyway. DDoS attacks can also originate from a 254 single system or a subset of systems that spoof the source address 255 in packet headers in order to mask the identity of the attack 256 source. In this case, an iterative trace through the upstream 257 networks in the path of the attack traffic may be required. 259 RID traces may also be used to locate a system used in an attack 260 to compromise another system. Compromising a system can be 261 accomplished through one of many attack vectors, using various 262 techniques from a remote host or through local privilege 263 escalation attempts. The attack may exploit a system or 264 application level vulnerability that may be the result of a design 265 flaw or a configuration issue. A compromised system, as described 266 above, can be used to later attack other systems. A single RID 267 Investigation Request may be used in this case since it is probable 268 that the source address is valid. Identifying the sources of 269 system compromises may be difficult since an attacker may access 270 the compromised system from various sources. The attacker may also 271 take measures to hide their tracks by deleting log files or by 272 accessing the system through a series of compromised hosts. 273 Iterative RID traces may be required for each of the compromised 274 systems used to obscure the source of the attack. If the source 275 address is valid, an Investigation request may be used in lieu of a 276 full RID TraceRequest. 278 System compromises may result from other security incident types 279 such as worms, Trojans, or viruses. It is often the case that an 280 incident goes unreported even if valid source address information 281 is available because it is difficult to take any action to mitigate 282 or stop the attack. Incident handling is a difficult task for an 283 NP and even at some client locations due to network size and 284 resource limitations. 286 2. Recommended Network Provider (NP) Technologies 288 For the purpose of this document, a network provider (NP) shall be 289 defined as a backbone infrastructure manager of a network. The 290 network provider's Computer Security Incident Response Team shall 291 be referred to as the CSIRT. The backbone may be that of an 292 organization providing network (Internet or private) access to 293 commercial, personal, government, or educational institutions, or 294 the backbone provider of the connected network. The connected 295 network provider is an extension meant to include Intranet and 296 Extranet providers as well as instances such as a business or 297 educational institute's private network. 299 NPs typically manage and monitor their networks through a 300 centralized network management system (NMS). The acronym NMS will 301 be used to generically represent management servers on a network 302 used for the management of network resources and the integration of 303 RID messaging with other components of the network. This system 304 may provide functions such as trend analysis for bandwidth 305 utilization, report communication problems, and trigger a RID trace 306 across the network or communicate with a RID system that can 307 initiate a trace. The RID messaging system may be the same or a 308 system separate from the NMS that communicates with various aspects 309 of the network to coordinate incident response. The components of 310 the network that may be integrated through the RID messaging system 311 include attack or event detection, network tracing, and network 312 devices to stop the effects of an attack. 314 The detection of security incidents may rely on manual reporting, 315 automated intrusion detection tools, and variations in traffic 316 types or levels on a network. Intrusion detection systems (IDS) 317 may be integrated into the incident-handling systems to create 318 IODEF documents or RID messages to facilitate security incident 319 handling. IDSs monitor network traffic, analyzing packets to 320 determine if the traffic might be classified as malicious. If an 321 IDS detects malicious traffic, an analyst would determine the 322 validity and severity of the attack traffic and if a trace is 323 necessary. If the analyst determines a trace should be initiated, 324 an IODEF document with RID extensions could be created or the 325 necessary information sent to the RID messaging system in order to 326 create and track the attack traffic. Detection of a security 327 incident is outside the scope of this paper; however, it should be 328 possible to integrate detection methods with RID messaging. 330 Once a security incident has been identified, the information is 331 put into a RID message to integrate with the NP's single network 332 trace mechanism. RID messaging is intended to be flexible in order 333 to accommodate various trace systems currently in use as well as 334 those that may evolve with technology. RID is intended to 335 communicate the necessary information needed by a trace mechanism 336 to the next upstream NP in the path of a trace. Therefore, a RID 337 message must carry the superset of data required for all tracing 338 systems. If possible, the trace may need to inspect packets to 339 determine a pattern, which could assist reverse path 340 identification. This may be accomplished by inspecting packet 341 header information such as the source and destination IP addresses, 342 ports, and protocol flags to determine if there is a way to 343 distinguish the packets being traced from other packets. A 344 description of the incident along with any available automated 345 trace data should trigger an alert to the NP's security team for 346 further investigation. The various technologies used to trace 347 traffic across a network are described in section 3.2. 349 Another area of integration is the ability to mitigate or stop 350 attack traffic once a source has been located. Any automated 351 solution should consider the possible side effects to the network. 352 A change control process or a central point for configuration 353 management might be used to ensure that the security of the network 354 and necessary functionality are maintained and that equipment 355 configuration changes are documented. Automated solutions may 356 depend upon the capabilities and current configuration management 357 solutions on a particular network. The solutions may be based on 358 authenticated and encrypted Simple Network Management Protocol 359 (SNMP) or Network Configuration Protocol (NETConf) access to 360 devices over an out-of-band connection or other similar 361 technologies. 363 3. Characteristics of Attacks 365 The goal of tracing a security incident may be to identify the 366 source or to find a point on the network as close to the origin of 367 the incident as possible. A security incident may be defined as a 368 system compromise, a worm or Trojan infection, or a single- or 369 multiple-source denial-of-service attack. Incident tracing can be 370 used to identify the source(s) of an attack in order to halt or 371 mitigate the undesired behavior. The communication system, 372 RID, described in this paper can be used to trace any type of 373 security incident and allows for actions to be taken when the 374 source of the attack or a point closer to the source has been 375 identified. The purpose of tracing an attack would be to halt or 376 mitigate the affects of the attack through methods such as 377 filtering or rate-limiting the traffic close to the source or 378 by using methods such as taking the host or network offline. 379 Care must also be taken to ensure the system is not abused and to 380 use proper analysis in determining if attack traffic is, in fact, 381 attack traffic at each NP along the path of a trace. 383 Tracing security incidents can be a difficult task since attackers 384 go to great lengths to obscure their identity. In the case of a 385 security incident, the true source might be identified through an 386 existing established connection to the attacker's point of origin. 387 However, the attacker may not connect to the compromised system for 388 a long period of time after the initial compromise or may access 389 the system through a series of compromised hosts spread across the 390 network. Other methods of obscuring the source may include 391 targeting the host with the same attack from multiple sources using 392 both valid and spoofed source addresses. This tactic can be used 393 to compromise a machine and leave a difficult task of locating the 394 true origin for the administrators. DDoS attacks are also 395 difficult or nearly impossible to trace because of the nature of 396 the attack. Some of the difficulties in tracing these attacks 397 include the following: 399 O the attack originates from multiple sources; 401 O the attack may include various types of traffic meant to 402 consume server resources, such as a SYN flood attack without a 403 significant increase in bandwidth utilization; 405 O the type of traffic could include valid destination services, 406 which cannot be blocked since they are essential services to 407 business, such as DNS servers at an NP or HTTP requests sent to 408 an organization connected to the Internet; 410 O the attack may utilize varying types of packets including TCP, 411 UDP, ICMP, or other IP protocols; 413 O the attack may use a very small number of packets from any 414 particular source, thus making a trace after the fact nearly 415 impossible. 417 If the source(s) of the attack cannot be determined from IP address 418 information or tracing the increased bandwidth utilization, it may 419 be possible to trace the traffic based on the type of packets seen 420 by the client. In the case of packets with spoofed source 421 addresses, it is no longer a trivial task to identify the source of 422 an attack. In the case of an attack using valid source addresses, 423 methods such as the traceroute utility can be used to fairly 424 accurately identify the path of the traffic between the source and 425 destination of an attack. If the true source has been identified, 426 actions should be taken to halt or mitigate the effects of the 427 attack by reporting the incident to the NP or the upstream NP 428 closest to the source. In the case of a spoofed source address, 429 other methods can be used to trace back to the source of an attack. 430 The methods include packet filtering, packet hash comparisons, IP 431 marking techniques, ICMP traceback, and packet flow analysis. As 432 in the case of attack detection, tracing traffic across a single 433 network is a function that can be used with RID in order to provide 434 the networked ability to trace spoofed traffic to the source, while 435 RID provides all the necessary information to accommodate the 436 approach used on any single network to accomplish this task. RID 437 can also be used to report attack traffic close to the source where 438 the IP address used was determined to be valid. 440 3.1 Tracing a Distributed Attack 442 Tracing a DDoS attack is a very difficult problem. Since DDoS 443 attacks may involve multiple sources with spoofed addresses, there 444 may only be a small amount of traffic from each of the originating 445 hosts. This makes it difficult to trace back to the sources. The 446 sources may also alternate the type of traffic and the master may 447 vary the sources from within the pool of sources launching the 448 attack. Because of the dynamic nature of the DDos attack, 449 immediate action would need to be taken to have any hope of 450 locating the origin(s) of the attack with a near real-time trace. 452 In order to identify a DoS attack or DDoS, a client may notify its 453 NP that it is currently under attack. Automated methods might 454 include statistical traffic analysis, which looks for 455 unexpected fluctuations in bandwidth or in the size and types of 456 packets sent between networks, hosts, or an IDS. There is 457 ongoing research in the area of detecting DoS and DDoS, and any 458 effective techniques could be integrated with the tracing 459 techniques described in this paper. Some research approaches 460 include methods that detect backscatter traffic [9], using a data 461 structure for bandwidth attack detection [10], and monitoring 462 congestion through packet retransmission information [11]. 464 Once an attack is suspected, traces would have to quickly identify 465 the various sources of the attack. A generalized approach should 466 be used to trace back connections using packet header information 467 such as the destination IP address and any distinguishing header 468 values of the traffic seen during the attack. The information 469 collected, along with an example packet, would be used in a RID 470 message to communicate incident handling information between NPs. 472 3.1.1 Tracing Security Incidents 474 If a trace can identify the sources of a distributed attack, 475 blocking the sources at the NP level close to the attacker could 476 be an immediate action to stop the attack. In the case of a DDoS 477 attack, further information may be obtained from the attacking 478 computers as to the controller of the attack sending the zombies' 479 control information to carry out the attack. A similar example of 480 attack traffic with the possibility of multiple traces required 481 would be one in which an attacker compromised a series of systems 482 and accomplished hiding their source by logging into a string of 483 systems to launch the attack. This additional trace is beyond the 484 scope of this paper, but may use additional tracing mechanisms such 485 as sniffing the network to locate the controllers of the attack. 487 Finding a faster and more efficient way to trace multiple sources 488 of an attack is essential to mitigating DDoS attacks. The ability 489 to quickly relay and act upon the trace information gathered is 490 imperative to stopping attack traffic. Tracing multiple attack 491 paths can also cause additional stress on the network and does not 492 scale well. 494 A CSIRT report might be generated in the form of an IODEF document 495 and then fed into a RID message or document to facilitate a trace 496 or multiple traces of attack traffic. 498 3.2 Trace Approaches 500 There have been many separate research initiatives to solve the 501 problem of tracing upstream packets to detect the true source of 502 attack traffic. Upstream packet tracing is currently confined to 503 the borders of a network or an NP's network. Traces require access 504 to network equipment and resources, thus potentially limiting a 505 trace to a specific network. Once a trace reaches the boundaries 506 of a network, the network manager or NP adjacent in the upstream 507 trace must be contacted in order to continue the trace. NPs have 508 been working on individual solutions to accomplish upstream tracing 509 within their own network environments. The tracing mechanisms 510 implemented thus far have included proprietary or custom solutions 511 requiring specific information such as IP packet header data, hash 512 values of the attack packets, or marked packets. Hash values are 513 used to compare a packet against a database of packets that have 514 passed through the network in the case of "Hash Based IP 515 Traceback"[7]. Other research solutions involve marking packets as 516 explained in "ICMP Traceback Messages"[8], "Practical Support for 517 IP Traceback" [14], and IP Marking [1]. The following sections 518 outline some available solutions for implementing traceback within 519 the confines of a network managed by a single entity. The single 520 network traceback solutions are discussed to determine the 521 information needed to accomplish an inter-network trace where 522 different solutions may be in place. 524 3.2.1 Trace Approach via Traffic Flow Analysis 526 Traffic flow analysis is used to monitor individual network traffic 527 streams, such as a single TCP session beginning with the SYN packet 528 and ending with the final FIN ACK in a session. There have been a 529 few efforts to standardize flow analysis for network management, 530 one through the traffic flow management MIB and another through 531 the IP Flow Information eXport (IPFIX) protocol. The "Traffic Flow 532 Management" RFC [RFC2720] was designed to provide management 533 information such as behavior models, capacity planning, network 534 performance, quality of service, and attribution of network usage 535 to system administrators. IPFIX is an IETF standard intended to 536 provide a uniform method of extracting flow information from 537 network devices. There are several competing standardized methods 538 for flow analysis; however, since they differ from each other, it 539 is difficult to generate standardized analysis tools. NetFlow 540 from Cisco [5] provides similar capabilities to the traffic flow 541 mib, except that it is specific to IP traffic and has already been 542 implemented for traffic management in commercial-off-the-shelf 543 equipment. Although NetFlow was developed by Cisco, it is also an 544 open standard. The flow analysis in both implementations can 545 monitor with a capture filter on source and destination addresses 546 the number of packets and the count of bytes in each flow, the 547 originating interface of the traffic, and the upstream peer 548 information. The upstream peer information is essential to tracing 549 a spoofed packet back to the true origin. 551 There are several differences in the implementations and the 552 monitor and capture capabilities of the two flow analysis 553 implementations. NetFlow collects all packets and maintains the 554 following information on packet flows for later analysis: 556 O Source and destination IP address 557 O Source and destination TCP/User Datagram Protocol (UDP) ports 558 O Type of service (ToS) 559 O Packet and byte counts 560 O Start and end timestamps 561 O Input and output interface numbers 562 O TCP flags and encapsulated protocol (TCP/UDP) 563 O Routing information (next-hop address, source autonomous system 564 (AS) number, destination AS number, source prefix mask, 565 destination prefix mask) 567 Based on the information listed above, a spoofed packet can be 568 traced upstream through a network to either identify the true 569 source or the upstream peer. Various flow-based solutions have 570 been developed and implemented for use on a single backbone based 571 on flow analysis, and RID messaging must be able to support 572 existing and future solutions to trace attacks across multiple 573 networks. The AS number listed associated with a source IP address 574 is only valid if the source IP address is valid. The AS number in 575 this case cannot be trusted until the true source has been 576 identified. 578 3.2.2 Trace Approach via Hash-Based IP Traceback 580 BBN implemented a traceback solution that collects hashes of IP 581 packets across the network. The Hash-Based IP Traceback was 582 designed specifically to trace attack traffic and achieve the 583 following objectives: 585 O Trace attacks after specific flows of the attack have completed 586 O Reduce storage requirements needed to save traceable packet data 587 O Provide a secure method to store packet captures on the Internet 589 Hash-based IP traceback is another solution to provide the ability 590 to trace attack traffic. By capturing all packets across the 591 network and saving hash values for the IP header information that 592 does not get altered as it traverses the network, attacks can be 593 traced after the fact. Since hashes of IP header information are 594 stored instead of the actual header information, privacy 595 concerns are no longer an issue as might be the case with packet 596 captures across the Internet. If a system used to store the 597 packet captures was compromised, the data could not be used to 598 identify which entities are "talking" to each other on the 599 Internet. 601 BBN also considered how traces could be performed across a single 602 network, for example an NP's backbone. The solution divides the 603 network up into regions, each with its own collection station. 604 The trace might be initiated at a particular collection station 605 where data for a specific router is stored. When the collection 606 station traces through its database for the matches of particular 607 hashes of IP packets, it follows the trace through the network 608 equipment for its own region. The collection station then 609 determines which bordering region was the next upstream source of 610 the attack, and the trace is continued at the next collection 611 agent. The trace continues until the source is identified or a 612 neighboring network is identified as the upstream source of the 613 attack. The upstream network must then be notified in some way in 614 order to continue the trace. The upstream network will require the 615 IP packet information in order to continue the trace. The 616 upstream provider will want to look at its network and resources 617 and decide if it would like to initiate a trace across its 618 network. A limited number of packets can be stored based on 619 resources and network traffic loads. RID is a possible solution 620 for communicating the upstream TraceRequest between bordering 621 networks. 623 3.2.3 IP Marking 625 The technique of IP Marking can be used more efficiently than 626 iterative trace mechanisms to trace attacks in which the source 627 address has been spoofed. This technique has been proposed 628 specifically in terms of tracing DoS attacks across a network. 629 All information is correlated at the end node or the target 630 where the packets received would have been marked probabilistically 631 along the path of the traffic. This method requires that routers 632 and other infrastructure equipment have the ability to mark packets 633 so that the path they took can be derived at the destination 634 address for the packets. Since all packets are not marked, 635 depending on the IP Marking scheme used, a number of similar 636 packets would have to be sent from a single source in order for it 637 to be identified. IP Marking alone may not be a complete answer 638 for tracing traffic, since an attacker could switch methods to send 639 very little data from any one host used in a DDoS attack, thus 640 making it unlikely that enough packets will be marked to find the 641 source of each stream. Integrating IP Marking with other 642 techniques may be the best answer to ensure the efficiency and 643 robustness of the system as a whole. 645 There are several ways in which the IP Marking approach may be 646 useful in integrating with RID. IP Marking may be used to 647 gather information about the path of the trace up to and including 648 identifying the actual source. A peer closer to the source might 649 be identified if the IP Marking technique were not able to fully 650 reconstruct the path of the trace. In this instance, the trace 651 information could be sent to the closest point identified in the 652 path from the IP Marking technique, thus shortening the length of 653 time required to trace the traffic through the network. If a 654 source was identified, a RID Investigation Request might be used in 655 order to trigger a specific action to take place close to the 656 source to mitigate or stop the effects of the attack. 658 3.2.4 Superset of Packet Information for Traces 660 In order for network traffic to be traced across a network, an 661 example packet from the attack must be sent along with the 662 TraceRequest or Investigation request. According to the research 663 for Hash-based IP Traceback, all of the non-changing fields of an 664 IP header along with 8 bytes of payload are required to provide 665 enough information to uniquely trace the path of a packet. The 666 non-changing fields of the packet header and the 8 bytes of payload 667 are the superset of data required by most single-network tracing 668 systems used; limiting the shared data to the superset of the 669 packet header and 8 bytes of payload prevents the need for sharing 670 potentially sensitive information that may be contained in the 671 data portion of a packet. 673 The RecordItem class in the IODEF will be used to store a 674 hexadecimal formatted packet including all packet header 675 information plus 8 bytes of payload or the entire packet contents. 676 The above trace systems do not require a full packet, but it may be 677 useful in some cases, so the option is given to allow a full packet 678 to be included in the data model. Note: Previously, the packet 679 data was contained in a RID class called IPPacket. The IODEF data 680 model was extended in August 2005 to accomodate a packet of type 681 hexidecimal. 683 If a subset of a packet is used, the following guidelines should be 684 used to provide compatibility between RID systems. The complete 685 header MUST be provided so that all systems expect a full packet 686 header and can be properly parsed. The full content may be 687 provided, but at least 8 bytes must be included to conduct a 688 network trace. RID requires the first 28 bytes of an IP v4 packet 689 in order to perform a trace. The required number of bytes provides 690 the IP header in an IP v4 packet, which is 10 bytes long; the TCP/ 691 UDP/ICMP header is also 10 bytes long, plus an additional 8 bytes 692 of payload to distinguish the packet for tracing purposes. RID 693 requires 48 bytes for an IP v6 packet in order to distinguish the 694 packet in a trace. The input mechanism should be flexible enough 695 to allow intrusion detection systems or packet sniffers to provide 696 the information. The system creating the RID message should also 697 use the packet information to populate the Incident class 698 information in order to avoid human error and also allow a system 699 administrator to override the automatically populated information. 701 4. Communication Between Network Providers 703 Expediting the communication between NPs is essential when 704 responding to a security-related incident, which may cross network 705 access points (Internet backbones) between providers. As a result 706 of the urgency involved in this inter-NP security incident 707 communication, there must be an effective system in place to 708 facilitate the interaction. This communication policy or system 709 should involve multiple means of communication to avoid a single 710 point of failure. Email is one way to transfer information about 711 the incident, packet traces, etc. However, e-mail may not be 712 received in a timely fashion or be acted upon with the same urgency 713 as a phone call or other communication mechanism. 715 Each NP should dedicate a phone number to reach a member of the 716 security incident response team. The phone number could be 717 dedicated to inter-NP incident communications and must be a 718 hotline that provides a 24x7 live response. The phone line should 719 reach someone who would have either the authority and expertise or 720 the means to expedite the necessary action to investigate the 721 incident. This may be a difficult policy to establish at smaller 722 NPs due to resource limitations, so another solution may be 723 necessary. An outside group may be able to serve this function if 724 given the necessary access to the NPs network. The outside 725 resource should be able to mitigate or alleviate the financial 726 limitations and any lack of experienced resource personnel. 728 A technical solution to trace traffic across a single NP may 729 include homegrown or commercial systems in which RID messaging 730 must accommodate the input requirements. The network management 731 systems used on the NP's backbone to coordinate the trace across 732 the single network requires a method to accept and process RID 733 messages and relay trace requests to the system, as well as to wait 734 for responses from the system to continue the RID request process 735 as appropriate. In this scenario, each NP would maintain its own 736 RID system and integrate with a management station used for network 737 monitoring and analysis. An alternative for NPs lacking sufficient 738 resources may be to have a neutral third party with access to the 739 NP's network resources who could be used to perform the trace 740 functions. This could be a function of a central organization 741 operating as a computer response team for the Internet as a whole 742 or within a consortium that may be able to provide centralized 743 resources. Consortiums would consist of a group of NPs that agree 744 to participate in the RID communication protocol with an agreed- 745 upon policy and communication protocol facilitating the secure 746 transport of RID XML documents. Transport for RID messages will be 747 specified in a separate document. 749 The first method described prevents the need to permit access to 750 other network's equipment through the use of a standard messaging 751 mechanism to enable RID or NMSs to communicate trace information 752 to other networks in a consortium or in neighboring networks. The 753 third party mentioned above may be used in this technical solution 754 to assist in facilitating traces through smaller NPs. The 755 messaging mechanism may be a logical or physical out-of-band 756 network to ensure the communication is secure and unaffected by the 757 state of the network under attack. The two management methods 758 would accommodate the needs of larger NPs to maintain full 759 management of their network, and the third party option could be 760 available to smaller NPs who lack the necessary human resources to 761 perform a trace. The first method enables the individual NPs to 762 involve their network operations staff to authorize the continuance 763 of a trace through their network via a notification and alerting 764 system. The out-of-band logical solution for messaging may be 765 permanent virtual circuits configured with a small amount of 766 bandwidth dedicated to RID communications between NPs. 768 The network used for the communication, out-of-band or protected 769 channels, would be direct communication links dedicated to the 770 transport of RID messages. The communication links would be direct 771 connections between network peers who have agreed upon use and 772 abuse policies through the use of a consortium. Consortiums might 773 be linked through policy comparisons and additional agreements to 774 form a larger web or iterative network of peers that correlates to 775 the traffic paths available over the larger web of networks. The 776 maintenance of the individual links will be the responsibility of 777 the two network peers hosting the link. Contact information, IP 778 addresses of RID systems and other information must be coordinated 779 between bilateral peers by a consortium and may use existing 780 databases, such as the Routing Arbitor. The security, 781 configuration, and confidence rating schemes of the RID messaging 782 peers must be negotiated by peers and must meet certain overall 783 requirements of the fully connected network (Internet, government, 784 education, etc.) through the peering and/or a consortium-based 785 agreement. 787 RID messaging established with clients of an NP may be negotiated 788 in a contract as part of a value-added service or through a service 789 level agreement. Further discussion is beyond the scope of this 790 document and may be more appropriately handled in network peering 791 or service level agreements. 793 Procedures for incident handling need to be established and well 794 known by anyone that may be involved in incident response. The 795 procedures should also contain contact information for internal 796 escalation procedures, as well as for external assistance groups 797 such as a CSIRT, CCCERT, GIAC, and the FBI. 799 4.1 Inter-Network Provider RID Messaging 801 In order to implement a messaging mechanism between RID 802 communication or NMS systems, a standard protocol and format is 803 required to ensure inter-operability between vendors. The messages 804 would have to meet several requirements in order to be meaningful 805 as they traverse multiple networks. Real-time Inter-network 806 Defense (RID) provides the framework necessary for communication 807 between networks involved in the traceback and mitigation of a 808 security incident. Several message types described in section 4.3 809 are necessary to facilitate a trace across multiple networks. The 810 message types include the Report, IncidentQuery, TraceRequest, 811 TraceAuthorization, Result, and the Investigation request message. 812 The Report message is used when an incident is to be filed on a 813 RID system or associated database, where no further action is 814 required. An IncidentQuery message is used to request information 815 on a particular incident. A TraceRequest message is used when the 816 source of the traffic may have been spoofed. In that case, each 817 network provider in the upstream path who receives a trace request 818 will issue a trace across the network to determine the upstream 819 source of the traffic. The TraceAuthorization and Result messages 820 are used to communicate the status and result of a trace. The 821 Investigation request message would only involve the RID 822 communication systems along the path to the source of the traffic 823 and not the use of network trace systems. The Investigation 824 Request leverages the bilateral relationships or a consortium's 825 inter-connections to mitigate or stop problematic traffic close to 826 the source. Routes could determine the fastest path to a known 827 source IP address in the case of a Investigation Request. A 828 message sent between RID systems for a TraceRequest or an 829 Investigation Request to stop traffic at the source through a 830 bordering network would require the information enumerated below: 832 1. Enough information to enable the network administrators 833 to make a decision about the importance of continuing the trace. 834 2. The incident or IP packet information needed to carry out 835 the trace or investigation. 836 3. Contact information of the origin of the RID communication. The 837 contact information could be provided through the autonomous 838 system number [RFC1930] or NIC handle information listed in the 839 Registry for Internet Numbers or other Internet databases. 840 4. Network path information to help prevent any routing loops 841 through the network from perpetuating a trace. If a RID system 842 receives a TraceRequest containing its own information in the 843 path, the trace must cease and the RID system should generate an 844 alert to inform the network operations staff that a tracing loop 845 exists. 846 5. A unique identifier for a single attack should be used to 847 correlate traces to multiple sources in a DDoS attack. 849 Use of the communication network and the RID protocol must be 850 for pre-approved, authorized purposes only. It is the 851 responsibility of each participating party to adhere to guidelines 852 set forth in both a global use policy for this system and 853 one established though the peering agreements for each bilateral 854 peer or agreed-upon consortium guidelines. The purpose of such 855 policies is to avoid abuse of the system; the policies shall be 856 developed by a consortium of participating entities. The global 857 policy may be dependent on the domain it operates under; for 858 example, a government network or a commercial network such as the 859 Internet would adhere to different guidelines to address the 860 individual concerns. Privacy issues must be considered in public 861 networks such as the Internet. Privacy issues are discussed in the 862 security section along with other requirements that must be agreed 863 upon by participating entities. 865 Traces must be legitimate security-related incidents and not used 866 for purposes such as sabotage or censorship. An example of such 867 abuse of the system would include a request to rate-limit 868 legitimate traffic to prevent information from being shared between 869 users on the Internet (restricting access to online versions of 870 papers) or restricting access from a competitor's product in order 871 to sabotage a business. 873 The RID system should be configurable to either require user input 874 or automatically continue traces. This feature would enable a 875 network manager to assess the available resources before continuing 876 a trace. A trace may cause adverse effects on a network. If the 877 confidence rating is low, it may not be in the Network Provider's 878 best interest to continue the trace. The confidence ratings must 879 adhere to the specifications for selecting the percentage used to 880 avoid abuse of the system. TraceRequests must be issued by 881 authorized individuals from the initiating network, set forth in 882 policy guidelines established through peering or SLA. 884 4.2 RID Network Topology 886 The most basic topology for communicating RID systems would be a 887 direct connection or a bilateral relationship as illustrated below. 889 __________ __________ 890 | | | | 891 | RID |__________-------------___________| RID | 892 |_________| | NP Border | |________| 893 ------------- 895 Figure 1: Direct Peer Topology 897 Within the consortium model, several topologies might be agreed 898 upon and used. One would leverage bilateral network peering 899 relationships of the members of the consortium. The peers for RID 900 would match that of routing peers and the logical network borders 901 would be used. This approach may be necessary for an iterative 902 trace where the source is unknown. The model would look like the 903 above diagram; however, there may be an extensive number of inter- 904 connections of bilateral relationships formed. Also within a 905 consortium model, it may be useful to establish an integrated mesh 906 of networks to pass RID messages. This may be beneficial when the 907 source address is known, and an interconnection may provide a 908 faster route to reach the closest upstream peer to the source of 909 the attack traffic. An example is illustrated below. 911 _______ _______ ______ 913 | | | | | | 914 __| RID |____-------------____| RID |____-------------____| RID |__ 915 |_____| | NP Border | |_____| | NP Border | |_____| 916 | ------------- ------------- | 917 |_______________________________________________________| 918 Direct connection to network that is not an immediate network peer 920 Figure 2: Mesh Peer Topology 922 By using a fully meshed model in a consortium, broadcasting RID 923 requests would be possible, but not advisable. By broadcasting a 924 request, RID peers that may not have carried the attack traffic on 925 their network would be asked to perform a trace for the potential 926 of deceasing the time in which the true source was identified. As 927 a result, many networks would have utilized unnecessary resources 928 for a TraceRequest that may have also been unnecessary. 930 4.3 Message Formats 932 The following section describes the six RID message types which 933 are based on the IODEF model. The messages are generated and 934 received on RID communication systems on the NP's network. The 935 messages may originate from IODEF messages from intrusion detection 936 servers, CSIRTS, analysts, etc. A RID message uses the IODEF 937 framework with the RID extension, which is encapsulated in a SOAP 938 wrapper. Each RID message type, along with an example, is 939 described in the following sections. 941 4.3.1 RID Messages and Transport 943 The six RID message types follow: 945 1. TraceRequest. This message is sent to the RID system next in 946 the upstream trace. It is used to initiate a TraceRequest or to 947 continue a TraceRequest to an upstream network closer to the 948 source of the origin of the security incident. 950 2. TraceAuthorization. This message is sent to the initiating RID 951 system from each of the upstream NPs' RID systems to provide 952 information on the trace status in the current network. 954 3. Result. This message is sent to the initiating RID system 955 through the network of RID systems in the path of the trace as 956 notification that the source of the attack was located. 958 4. Investigation. This message type is used when the source of the 959 traffic is believed to be valid. The purpose of the Investigation 960 message request is to leverage the existing peer relationships in 961 order to notify the network provider closest to the source of the 962 valid traffic of a security-related incident. 964 5. Report. This message is used to report a security incident, 965 for which no action is requested. This may be used for the purpose 966 of correlating attack information by CSIRTS, statistics and 967 trending information, etc. 969 6. IncidentQuery. This message is used to request information 970 about an incident or incident type from a trusted RID system. The 971 response is provided through the Report message. 973 When a system receives a RID message, it must be able to 974 determine the type of message and parse it accordingly. The 975 message type is specified in the RIDPolicy class. The RIDPolicy 976 class is also presented in the SOAP header to facilitate the 977 communication of security incident data to trace, investigate, 978 query, or report information security incident information. The 979 details of the SOAP wrapper are discussed in the SOAP document for 980 transport communications. 982 4.3.2 RID Data Types 984 RID is derived from the IODEF data model and inherits all of the 985 data types defined in the IODEF model. 987 4.3.3 IODEF-Document 989 The IODEF model will be followed as specified in RFCXXXX for each 990 of the RID message types. (The RFC number will replace the XXXX 991 when a number has been assigned for the document.) The RID schema 992 is used to define an XML envelope for IODEF documents to facilitate 993 RID communications. Each message type varies slightly in format 994 and purpose; hence, the requirements vary and will be specified for 995 each. All classes, elements, attributes, etc., that are defined in 996 the IODEF-Document are valid in the context of a RID message; 997 however, some listed as optional in IODEF are mandatory for RID as 998 defined in section 4.4. The IODEF model MUST be fully implemented 999 to ensure proper parsing of all RID messages. 1001 Please see RFCxxxx for specific information on the IODEF-Document 1002 requirements. (The RFC number will be defined when the document 1003 becomes an RFC.) 1005 4.3.4 IODEF-RID Schema 1007 There are four classes included in the RID extension required to 1008 facilitate RID communications. The NPPath class is used to list 1009 out the path a trace has taken at the RID system or NP level; the 1010 TraceStatus class is used to indicate the approval status of a 1011 TraceRequest or Investigation request; the IncidentSource class is 1012 used to report whether or not a source was found and to identify 1013 the source host(s) or network(s); and the RIDPolicy class provides 1014 information on the agreed policies and specifies the type of 1015 communication message being used. 1017 The RID schema acts as an envelope for the IODEF schema to 1018 facilitate RID communications. The intent in maintaining a 1019 separate schema and not using the AdditionalData extension of IODEF 1020 is the flexibility of sending messages between RID hosts. 1021 Since RID is a separate schema that includes the IODEF schema, the 1022 RID information acts as an envelope, and then the RIDPolicy 1023 class can be easily extracted for use in the SOAP header for 1024 transport. The security requirements of sending incident 1025 information across the network require the use of encryption. The 1026 RIDPolicy information is not required to be encrypted, so 1027 separating out this data from the IODEF extension removes the need 1028 for decrypting and parsing the entire IODEF and RID document to 1029 determine how it should be handled at each RID host. 1031 The purpose of the RIDPolicy class is to specify the message type 1032 for the receiving host, facilitate the policy needs of RID, and 1033 provide routing information in the form of an IP address of the 1034 destination RID system. 1036 The policy information and guidelines are discussed in section 6.5. 1037 The policy is defined between RID peers and within or between 1038 consortiums. The RIDPolicy is meant to be a tool to facilitate the 1039 defined policies. This MUST be used in accordance with policy set 1040 between clients, peers, consortiums, and/or regions. Security, 1041 privacy, and confidentiality MUST be considered as specified in 1042 this document. 1044 The RID Schema is defined as follows: 1046 +------------------+ 1047 | RID | 1048 +------------------+ 1049 | ANY | 1050 | |<>-------------[ RIDPolicy ] 1051 | ENUM restriction | 1052 | ENUM type |<>---{1..*}----[ NPPath ] 1053 | STRING meaning | 1054 | |<>---{0..1}----[ TraceStatus ] 1055 | | 1056 | |<>---{0..1}----[ IncidentSource ] 1057 +------------------+ 1059 Figure 3: The RID Schema 1061 The aggregate classes that constitute the RID schema in the 1062 iodef-rid namespace are as follows: 1064 RIDPolicy 1065 One. The RIDPolicy class is used by all message types to 1066 facilitate policy agreements between peers, consortiums or 1067 federations as well as to properly route messages. 1069 NPPath 1070 One or many. The contact information for the NPs involved in a 1071 trace, which includes information on the actual RID or NMS 1072 systems involved in the trace. The schema will not enforce the 1073 requirement of one entry to enable parsing to work propery in 1074 the SOAP header to support transport. 1076 TraceStatus 1077 Zero or One. This is used only in Trace Authorization messages 1078 to report back to the originating RID system if the trace will be 1079 continued by each RID system that received a TraceRequest in the 1080 path to the source of the traffic. 1082 IncidentSource 1083 Zero or One. The IncidentSource class is used in the Result message 1084 only. The IncidentSource provides the information on the 1085 identified source host or network of an attack trace or 1086 investigation. 1088 4.3.4.1 NPPath Class 1090 The NPPath information is represented in the aggregate RID class. 1092 +------------------+ 1093 | NPPath | 1094 +------------------+ 1095 | ENUM restriction |<>---{0..1}----[ name ] 1096 | | 1097 | |<>---{0..*}----[ RegistryHandle ] 1098 | | 1099 | |<>-------------[ Node ] 1100 | | 1101 | |<>---{0..*}----[ Email ] 1102 | | 1103 | |<>---{0..*}----[ Telephone ] 1104 | | 1105 | |<>---{0..1}----[ Fax ] 1106 | | 1107 | |<>---{0..1}----[ Timezone ] 1108 | | 1109 | |<>---{1..*}----[ NPPath ] 1110 +------------------+ 1112 Figure 4: The NPPath Class 1114 The aggregate classes that constitute the NPPath class are as 1115 follows: 1117 name 1118 Zero or one. NAME. The name of the contact. The contact may 1119 either be an organization or a person. The type attribute 1120 dictates the semantics (organization or person). 1122 RegistryHandle 1123 Zero or many. The handle name in a registry. Care must be taken 1124 to ensure that a handle is meaningful to the recipient. 1125 Intra-organizational handles are of not much use for 1126 extra-organizational communication. The base definition is from 1127 IODEF section 3.7.1. 1129 Node 1130 One. The Node class is used to identify a host or network 1131 device, in this case to identify the system communicating RID 1132 messages or the NP's RID system. 1134 The base definition of the class is reused from the IODEF 1135 specification section 3.16. 1137 Email 1138 Zero or many. EMAIL. The email address of the contact formatted 1139 according to IODEF section 2.2.13. 1141 Telephone 1142 Zero or many. PHONE. The telephone number of the contact 1143 formatted according to documentation in section 5.21 of RFC2256. 1145 Fax 1146 Zero or one. PHONE. The facsimile telephone number of the 1147 contact formatted according to documentation in section 5.21 of 1148 RFC2256. 1150 Timezone 1151 Zero or one. STRING. The timezone in which the contact resides. 1153 NPPath 1154 One or many. Recursive definition of NPPath, allowing for 1155 grouping of data. This is necessary in order to provide the 1156 complete list of systems communicating in the RID Trace, 1157 Investigation, or Report messages. The first NPPath definition 1158 is used for the originating host and NP information; the second 1159 listing is for the first NP that receives a request or message. 1160 All subsequent entries are used to list the information for each 1161 RID system for the NPs involved. 1163 4.3.4.2 TraceStatus Class 1165 The TraceStatus class is an aggregate class in the RID class. 1167 +-------------------+ 1168 | TraceStatus | 1169 +-------------------+ 1170 | | 1171 | ENUM restriction |<>-------[ AuthorizationStatus ] 1172 | | 1173 +-------------------+ 1175 Figure 5: The TraceStatus Class 1177 The aggregate elements that constitute the TraceStatus class are as 1178 follows: 1180 AuthorizationStatus 1181 One. Required. STRING. The listed values are used to provide a 1182 response to the requesting CSIRT of the status of a TraceRequest 1183 in the current network. 1185 Approved. The trace was approved and will begin in the current 1186 NP. 1187 Denied. The trace was denied in the current NP. The next 1188 closest NP can use this message to filter traffic from the 1189 upstream NP using the example packet to help mitigate the 1190 effects of the attack as close to the source as possible. The 1191 TraceAuthorization message must be passed back to the 1192 originator and a Result message used from the closest NP to the 1193 source to indicate actions taken in the IODEF History class. 1194 Pending. Awaiting approval and a time-out period has been 1195 reached which resulted in this pending status and 1196 TraceAuthorization message being generated. 1198 4.3.4.3 IncidentSource Class 1200 The IncidentSource class is an aggregate class in the RID class. 1202 +-------------------+ 1203 | IncidentSource | 1204 +-------------------+ 1205 | | 1206 | ENUM restriction | 1207 | |<>-------------[ SourceFound ] 1208 | | 1209 | |<>---{0..*}----[ Node ] 1210 | | 1211 +-------------------+ 1213 Figure 6: The IncidentSource Class 1215 The elements that constitute the IncidentSource class follow: 1217 SourceFound 1218 One. Boolean. The Source class indicates if a source was 1219 identified. If the source was identified, it will be listed in 1220 the Node element of this class. 1222 True. Source of incident was identified. 1223 False. Source of incident was not identified. 1225 Node 1226 One. The Node class is used to identify a host or network 1227 device, in this case to identify the system communicating RID 1228 messages. 1230 The base definition of the class is reused from the IODEF 1231 specification IODEF 3.16. 1233 4.3.4.4 RIDPolicy 1235 The RIDPolicy class facilitates the delivery of RID messages and is 1236 also referenced in the SOAP header. 1238 +-------------------+ 1239 | RIDPolicy | 1240 +-------------------+ 1241 | | 1242 | ENUM restriction |<>-------------[ MsgType ] 1243 | | 1244 | |<>---{1..*}----[ PolicyRegion ] 1245 | | 1246 | |<>-------------[ MsgDestination ] 1247 | | 1248 | |<>-------------[ Node ] 1249 | | 1250 | |<>---{1..*}----[ TrafficType ] 1251 | | 1252 | |<>---{0..1)----[ IncidentID ] 1253 +-------------------+ 1255 Figure 7: The RIDPolicy Class 1257 The aggregate elements that constitute the RIDPolicy class are as 1258 follows: 1260 MsgType 1261 One. Required. STRING. The type of RID Message sent. The six 1262 types of messages are described in Section 4.3.1 and can be noted 1263 as one of the six selections below. 1265 TraceRequest. This message may be used to initiate a 1266 TraceRequest or to continue a TraceRequest to an upstream 1267 network closer to the source of the origin of the security 1268 incident. 1270 TraceAuthorization. This message is sent to the initiating RID 1271 system from each of the upstream RID systems to provide 1272 information on the trace status in the current network. 1274 Result. This message indicates that the source of the 1275 attack was located and the message is sent to the initiating RID 1276 system through the RID systems in the path of the trace. 1278 Investigation. This message type is used when the source of the 1279 traffic is believed to be valid. The purpose of the 1280 Investigation request is to leverage the existing peer or 1281 consortium relationships in order to notify the network provider 1282 closest to the source of the valid traffic that some event 1283 occurred, which may be a security-related incident. 1285 Report. This message is used to report a security incident, 1286 for which no action is requested in the IODEF expectation class. 1287 This may be used for the purpose of correlating attack 1288 information by CSIRTS, statistics and trending information, etc. 1290 IncidentQuery. This message is used to request information 1291 from a trusted RID system about an incident or incident type. 1293 MsgDestination 1294 One. Required. STRING. The destination of the RID message will 1295 also appear in the NPPath class, but may be encrypted in some 1296 cases. The destination required at this level may either be the 1297 RID messaging system intended to receive the request or the source 1298 of the incident in the case of an Investigation request where the 1299 RID system that can assist to stop or mitigate the traffic may not 1300 be known and the message has to traverse RID messaging systems by 1301 following the routing path to the closest RID system to the source 1302 of the attack traffic. The Node element lists either the RID 1303 system or the IP of the source, and the meaning of the value in 1304 the Node element is determined by the MsgDestination element. 1306 RIDSystem. The address listed in the Node element of the 1307 RIDPolicy class is the next upstream RID system that will 1308 receive the RID message. 1310 SourceOfIncident. The address listed in the Node element of 1311 the RIDPolicy class is the incident source. The IP address will 1312 be used to determine the path of RID systems that will be used 1313 to find the closest RID system to the source of an attack in 1314 which the IP used by the source is believed to be valid and an 1315 Investigation message is used. This is not to be confused with 1316 the IncidentSource class as the defined value here is from an 1317 initial trace or investigation request, not the source used in a 1318 Result message. 1320 Node 1321 One. The Node class is used to identify a host or network 1322 device, in this case to identify the system communicating RID 1323 messages. 1325 The base definition of the class is reused from the IODEF 1326 specification IODEF 3.16. 1328 PolicyRegion 1329 One or many. Required. STRING. The listed values are used to 1330 determine what policy area may require consideration before a 1331 trace can be approved. The PolicyRegion may include multiple 1332 selections from the list in order to fit all possible policy 1333 considerations when crossing regions, consortiums, or networks. 1335 ClientToNP. An enterprise network initiated the request. 1336 NPToClient. An NP passed a RID request to a client or an 1337 enterprise attached network to the NP based on the service 1338 level agreements. 1339 Inter-Consortium. A trace that should have no restrictions 1340 within the boundaries of a consortium with the agreed-upon use 1341 and abuse guidelines. 1342 PeerToPeer. A trace that should have no restrictions between 1343 two peers but may require further evaluation before 1344 continuance beyond that point with the agreed-upon use and 1345 abuse guidelines. 1346 Between-Consortiums. A trace that should have no restrictions 1347 between consortiums that have established agreed-upon use and 1348 abuse guidelines. 1349 AcrossNationalBoundaries. This selection must be set if the 1350 trace type is anything but a trace of attack traffic with 1351 malicious intent. This must also be set if the traffic request 1352 is based upon regulations of a specific nation that would not 1353 apply to all nations. This is different from the inter- 1354 consortium since it may be possible to have multiple nations as 1355 members of the same consortium, and this option must be 1356 selected if the traffic is of a type that may have different 1357 restrictions in other nations. 1359 TrafficType 1360 One or many. Required. STRING. The listed values are meant to 1361 assist in determining if a trace is appropriate for the NP 1362 receiving the request to continue the trace. Multiple values may 1363 be selected for this element; however, where possible, it should 1364 be restricted to one value which would most accurately describe 1365 the traffic type. 1367 Attack. This option should only be selected if the traffic is 1368 related to a network-based attack. The type of attack MUST 1369 also be listed in more detail in the IODEF Method and Impact 1370 classes for further clarification to assist in determining if 1371 the trace can be continued. (IODEF sections 3.10 and 3.11) 1372 Network. This option MUST only be selected when the 1373 trace is related to NP network traffic or routing issues. 1374 Content. This category MUST be used only in the case in which the 1375 request is related to the content and regional restrictions on 1376 accessing that type of content exist. This is not malicious 1377 traffic but may include determining what sources or 1378 destinations accessed certain materials available on the 1379 Internet, including, but not limited to, news, technology, or 1380 inappropriate content. 1381 OfficialBusiness. This option MUST be used if the traffic 1382 being traced is requested or affiliated with any government or 1383 other official business request. This would be used during 1384 an investigation by government authorities or other government 1385 traces to track suspected criminal or other activities. 1386 Other. If this option is selected, a description of the trace 1387 type MUST be provided so that policy decisions can be made to 1388 continue or stop the trace. The information should be provided 1389 in the IODEF message in the Expectation Class or in the History 1390 Class using a HistoryItem log. 1392 IncidentID 1393 Zero or one. Global reference pointing back to the IncidentID 1394 defined in the IODEF data model. The IncidentID includes the 1395 name of the CSIRT, an incident number, and an instance of that 1396 incident. The instance number is appended with a dash 1397 separating the values and is used in cases for which it may be 1398 desirable to group incidents. Examples of incidents that may 1399 be grouped would be botnets, DDoS attacks, multiple hops 1400 of compromised systems found during an investigation, etc. 1402 4.4 RID Documents Defined by Message Type Derived from IODEF 1404 This section includes the mandatory IODEF information used in all 1405 RID messages. Since RID is a wrapper for an IODEF document, the 1406 full IODEF specifications MUST be implemented, and the following 1407 section identifies the IODEF fields that must be filled in when 1408 a RID message or document is generated. Other fields may 1409 optionally be filled in to provide further information to an 1410 incident handler and thus must be implemented for proper parsing of 1411 a RID message wrapping an IODEF document. This section will 1412 reference the IODEF model and the sections of the IODEF RFC where 1413 each IODEF class can be located. 1415 IODEF Schema Classes 1417 Incident Class (IODEF 3.2) 1418 Purpose: The Purpose will be set according to the purpose of the 1419 message type, for instance, incident handling or statistics. 1420 Restriction: Sender can select from the IODEF specifications for 1421 this value and fill in as appropriate. 1422 IncidentID (IODEF 3.3) 1423 GUID: Name of CSIRT or NP that created the document. 1424 AlternativeID (IODEF 3.4) 1425 This incident ID is one set by another CSIRT that is tracking the 1426 same or a similar incident. This value should not be set in the 1427 initial request, but may be set in a request passed forward by an 1428 NP in the path of a trace, investigation, or report. 1430 RelatedActivity Class (IODEF 3.5) 1431 This class is optional if an AlternateID is specified. 1432 AdditionalData Class (IODEF 3.6) 1433 This class is optional and may be used if an extended schema is 1434 necessary to describe the incident. 1435 Contact: Mandatory for RID (IODEF 3.7) 1436 The required aggregate classes for the contact class in RID 1437 messages include Name, RegistryHandle (IODEF 3.7.1), Email, 1438 Telephone. The attributes in the contact class are required in 1439 the IODEF document and thus are required in RID messages and 1440 include Restriction, Role, and Type. 1442 StartTime: Mandatory for RID (IODEF 3.8.1) 1443 EndTime: Optional for RID, incident may still be in process in 1444 which no end time can be listed (IODEF 3.8.2). 1445 DetectTime: Mandatory for RID (IODEF 3.8.3) 1446 ReportTime: Mandatory for RID (IODEF 3.8.4) 1447 EventData: Required for RID (IODEF 3.12) 1448 Much of the EventData Class is a duplicate for the aggregate 1449 IncidentData class and the proper uses of this class are defined 1450 in the IODEF RFC. The EventData contains the Expectation class 1451 to ensure any action requested is associted back to the proper 1452 EventData. 1453 Expectation: Mandatory for RID (IODEF 3.13) 1454 The StartTime and EndTime, as well as the accuracy required, can 1455 be used to determine the type of trace that would be used on a 1456 network with multiple choices. StartTime and EndTime to stop the 1457 trace would indicate if a fast or slower and more accurate method 1458 should be used for each TraceRequest. 1459 The following attributes are required in RID messages: 1460 Priority and Category. The category attribute is used to 1461 place a request for a specific action to be taken close to 1462 the source. 1463 Note: Although category is required in a request, the NP 1464 closest to the source of the attack decides upon the 1465 ultimate response. 1466 Method: Techniques used in attack - Mandatory for RID to 1467 determine the type of traffic for RIDPolicy informatio) 1468 (IODEF 3.9) 1469 Assessment: Characterization of the impact - Mandatory for RID, 1470 (reference IODEF section 3.10) 1471 Impact aggregate class (IODEF 3.10) MUST be used along with 1472 the Confidence class (IODEF 3.10.4) in the Assessment Class. 1473 The other impact classes are optional and may depend on the 1474 Incident type to determine if the additional classes are 1475 appropriate. 1476 History: Required for upstream trace requests, investigations, 1477 and report messages but not for original request. (IODEF 3.11) 1478 The HistoryItem element specifies the actions taken to stop or 1479 mitigate the effects of a security incident through the atype 1480 attribute. It may also be used to further describe actions 1481 taken along the NP Path of a trace as well as to describe the 1482 incident handling in a report message. 1483 Flow Class: Optional for RID (IODEF 3.14) 1484 System class: (IODEF 3.15) 1485 The System class is required and the information listed in this 1486 class can be automatically entered into this class from the 1487 packet used in the incident trace by the RID implementation. 1488 Information must be reviewed by the submitter and the additional 1489 required classes and attributes filled in for proper processing 1490 of a request. The system class MUST be used to list the 1491 source and the target or intermediate system(s) and MUST note if 1492 the system was spoofed through the use of the Node class (IODEF 1493 3.16). A separate instance of the System class (and Node Class) 1494 is used for each type of system listed in the document. The 1495 spoof section MUST be used in the System EventData Class of all 1496 RID messages and is set to the value of spoofed for all 1497 TraceRequests that require an actual trace of network traffic. 1498 In an Investigation request, the source is believed to be valid. 1499 All other classes of the System Class are optional as in the 1500 IODEF document. 1501 Node Class and Service class are embedded within other listed 1502 classes or the IODEF definitions are reused in the RID 1503 specification (IODEF 3.16 and 3.17). 1504 Record Class: Optional for RID (IODEF 3.19) 1505 Required for messages types that must include a sample packet. 1506 The RecordItem Class (IODEF 3.19.2) allows for various packet 1507 types to be included in an IODEF document. This replaced the 1508 need for the IPPacket class in RID and must be used to represent 1509 packet data for incident handling. 1511 RID Schema Classes: RID messages require that the NP Path and the 1512 RecordItem (including an example packet) class are used to 1513 provide adequate information for an upstream peer to perform a 1514 trace. The information contained in the NPPath and RecordItem 1515 classes must remain and be maintained in each type of RID 1516 message document. The TraceStatus class is used in the 1517 TraceAuthorization message only since its purpose is to let the 1518 downstream NP know if the trace was approved and will begin in 1519 the next upstream network. The RIDPolicy class is used in 1520 routing RID messages and providing policy information between 1521 participating RID hosts. 1522 NPPath (Original Request should contain originator plus the 1523 next peer in the upstream request, the host that is receiving 1524 the request) 1525 TraceStatus (Approval status for the trace in the current 1526 network) 1527 IncidentSource (Source information for Result message) 1528 RIDPolicy (Policy information to support RID communications) 1530 Restriction 1531 Optional. The IODEF restriction should be used in addition to 1532 the RID privacy and security guidelines since this is optional 1533 on the part of the receiving end of an IODEF message and is 1534 not enforced. 1536 Note: The implementation of the RID system may obtain some of the 1537 information needed to fill in the content required for each message 1538 type automatically from packet input to the system or default 1539 information such as that used in the NPPath class. 1541 4.4.1 TraceRequest 1543 Description: This message or document is sent to the Network 1544 Management Station next in the upstream trace once the upstream 1545 source of the traffic has been identified. 1547 The following information is required for TraceRequest messages and 1548 will be provided through: 1550 RID Information: 1551 RIDPolicy 1552 RID message type, IncidentID, and destination 1553 policy information 1554 Path information of RID systems used in the trace 1555 NPPath in RID schema 1557 IODEF Information: 1558 Time Stamps (DectectTime, StartTime, EndTime, ReportTime) 1559 Incident Identifier (Incident Class, IncidentID) 1560 Trace number - used for multiple traces of a single 1561 incident, must be noted. 1562 Confidence rating of security incident (Impact and Confidence 1563 Class) 1564 System Class is used to list both the Source and Destination 1565 Information used in the attack and must note if the traffic 1566 is spoofed, thus requiring an upstream TraceRequest in RID. 1567 Expectation class should be used to request any specific actions 1568 to be taken close to the source. 1569 Event, Record, and RecordItem Classes to include example packets 1570 and other information related to the incident. 1571 [Free-form text area for any additional information on 1572 justification for Investigation message request, IODEF 1573 IncidentData Description] 1575 W3C standards for Encryption and Digital Signatures: 1576 Digital signature from initiating RID system, passed to all 1577 systems in upstream trace using XML digital signature. 1579 A DDoS attack can have many sources, resulting in multiple traces 1580 to locate the sources of the attack. It may be valid to continue 1581 multiple traces for a single attack. The path information would 1582 enable the administrators to determine if the exact trace had 1583 already passed through a single network. The incident identifier 1584 must also be used to identify multiple TraceRequests from a 1585 single incident. 1587 4.4.2 TraceAuthorization Message 1589 Description: This message is sent to the initiating RID system from 1590 the next upstream NP's RID system to provide information on the 1591 trace status in the current network. 1593 The following information is required for TraceAuthorization 1594 messages and will be provided through: 1596 RID Information: 1597 RIDPolicy 1598 RID message type, IncidentID, and destination 1599 policy information 1600 Status of TraceRequest 1601 TraceStatus class in RID schema 1602 Path information of RID systems used in the trace 1603 NPPath class in RID schema 1604 The last NP listed is the NP sending this 1605 TraceAuthorization message. All previous NPs listed in the 1606 NPPath must be retained. 1608 IODEF Information: 1609 Time Stamps (DectectTime, StartTime, EndTime, ReportTime) 1610 Incident Identifier (Incident Class, IncidentID) 1611 Trace number - used for multiple traces of a single 1612 incident, must be noted. 1613 Confidence rating of security incident (Impact and Confidence 1614 Class) 1615 System class information 1616 Event, Record, and RecordItem Classes to include example packets 1617 and other information related to the incident [optional]. 1618 [Additional free-form text information on the attack, 1619 Description in History Class] 1621 W3C standards for Encryption and Digital Signatures: 1622 Digital signature of responding NP for authenticity of Trace 1623 Status Message, from the NP creating this message using 1624 XML digital signature. 1626 A message is sent back to the initiating RID system of the trace as 1627 status notification. This message verifies that the next RID 1628 system in the path has received the message from the previous 1629 system in the path. This message also verifies that the trace is 1630 now continuing, has stopped, or is pending in the next upstream. 1631 The pending status would be automatically generated after a 1632 2-minute timeout without system predefined or administrator action 1634 taken to approve or disapprove the trace continuance. 1636 4.4.3 Result Message 1638 Description: This message indicates that the trace or investigation 1639 has been completed and provides the result. The Result message 1640 includes information on whether or not a source was found and the 1641 source information through the IncidentSource class. The Result 1642 information MUST go back to the originating RID system that began 1643 the investigation or trace. 1645 The following information is required for Result messages and will 1646 be provided through: 1648 RID Information: 1649 RIDPolicy 1650 RID message type, IncidentID, and destination 1651 policy information 1652 Path information of RID systems used in the trace 1653 NPPath class in RID schema 1654 The last NP listed is the NP, which located the source of 1655 the traffic (the NP sending the Result message) 1656 Incident Source 1657 The IncidentSource class of the RID schema is used to 1658 note if a source was identified and the source(s) address. 1660 IODEF Information: 1661 Time Stamps (DectectTime, StartTime, EndTime, ReportTime) 1662 Incident Identifier (Incident Class, IncidentID) 1663 Trace number - used for multiple traces of a single 1664 incident, must be noted. 1665 Confidence rating of Security Incident (Impact and Confidence 1666 Class) 1667 System Class is used to list both the Source and Destination 1668 Information used in the attack and must note if the traffic 1669 is spoofed, thus requiring an upstream TraceRequest in RID. 1670 History Class atype attribute is used to note any actions taken. 1671 History class also noes any other background information. 1672 Event, Record, and RecordItem Classes to include example packets 1673 and other information related to the incident [optional] 1674 [Free-form text area for any additional information on 1675 the identified source of the attack traffic, IODEF 1676 Description, Incident Class.] 1678 W3C Encryption and Digital Signature standards: 1679 Digital signature of source NP for authenticity of Result 1680 Message, the NP creating this message using XML digital 1681 signature. 1683 A message sent back to the initiating RID system to notify the 1684 associated CSIRT that the source has been located. The actual 1685 source information may or may not be included, depending on the 1686 policy of the network in which the client or host is attached. 1687 Any action taken by the NP to act upon the discovery of the source 1688 of a trace should be included. The NP may be able to automate the 1689 adjustment of filters at their border router to block outbound 1690 access for the machine(s) discovered as a part of the attack. The 1691 filters may be comprehensive enough to block all Internet access 1692 until the host has taken the appropriate action to resolve any 1693 security issues or to rate-limit the ingress traffic as close to 1694 the source as possible. 1696 Security and privacy considerations discussed in sections 6 and 7 1697 must be taken into account. 1699 Note: The History Class has been expanded in IODEF to accommodate 1700 all of the possible actions taken as a result of a RID TraceRequest 1701 or Investigation request using the iodef:atype or action type 1702 attribute. The History class should be used to note all 1703 actions taken close to the source of a trace or incident using the 1704 most appropriate option for the type of action along with a 1705 description. The atype attribute in the Expectation class can 1706 also be used to request an appropriate action when a TraceRequest 1707 or Investigation request is made. 1709 4.4.4 Investigation Message Request 1711 Description: This message type is used when the source of the 1712 traffic is believed to be valid. The purpose of the Investigation 1713 message request is to leverage the existing bilateral peer 1714 relationships in order to notify the network provider closest to 1715 the source of the valid traffic that some event occurred, 1716 which may be a security-related incident. 1718 The following information is required for Investigation messages 1719 and will be provided through: 1721 RID Information: 1722 RID Policy 1723 RID message type, IncidentID, and destination 1724 policy information 1725 Path information of RID systems used in the trace 1726 NPPath class in RID schema 1728 IODEF Information: 1729 Time Stamps (DectectTime, StartTime, EndTime, ReportTime) 1730 Incident Identifier (Incident Class, IncidentID) 1731 Trace number - used for multiple traces of a single 1732 incident, must be noted. 1733 Confidence rating of security incident (Impact and Confidence 1734 Class) 1735 System Class is used to list both the Source and Destination 1736 Information used in the attack and must note if the traffic 1737 is spoofed, thus requiring an upstream TraceRequest in RID. 1738 Expectation class should be used to request any specific actions 1739 to be taken close to the source. 1740 Event, Record, and RecordItem Classes to include example packets 1741 and other information related to the incident. 1742 [Free-form text area for any additional information on 1743 justification for Investigation message request, IODEF 1744 Description.] 1746 W3C Encryption and Digital Signature standards: 1747 Digital signature from initiating RID system, passed to all 1748 systems in upstream trace using XML digital signature. 1750 Security considerations would include the ability to encrypt the 1751 contents of the Investigation message request using the public key 1752 of the destination RID system. The incident number would increase 1753 as if it were a TraceRequest message in order to ensure 1754 uniqueness within the system. The relaying peers would also 1755 append their AS or RID system information as the request message 1756 was relayed along the web of network providers so that the Result 1757 message could utilize the same path as the set of trust 1758 relationships for the return message, thus indicating any actions 1759 taken. The request would also be recorded in both the state table 1760 of the initiating and destination NP RID system. The destination 1761 NP is responsible for any actions taken as a result of the request 1762 in adherence to any service level agreements or internal policies. 1763 The NP should confirm the traffic actually originated from the 1764 suspected system before taking any action and confirm the reason 1765 for the request. The request may be sent directly to a known 1766 RID System or routed by the source address of the attack using 1767 the message destination of RIDPolicy, SourceOfIncident. 1769 Note: All intermediate parties must be able to view RIDPolicy 1770 information in order to properly direct RID messages. 1772 4.4.5 Report Message 1774 Description: This message or document is sent to a RID system to 1775 provide a report of a security incident. This message does not 1776 require any actions to be taken, except to file the report on the 1777 receiving RID system or associated database. 1779 The following information is required for Report messages and will 1780 be provided through: 1782 RID Information: 1783 RID Policy 1784 RID message type, IncidentID, and destination 1785 Policy information 1787 IODEF Information: 1788 Time Stamps (DectectTime, StartTime, EndTime, ReportTime) 1789 Incident Identifier (Incident Class, IncidentID) 1790 Trace number - used for multiple traces of a single 1791 incident, must be noted. 1792 Confidence rating of security incident (Impact and Confidence 1793 Class) 1794 System Class is used to list both the Source and Destination 1795 Information used in the attack. 1796 Event, Record, and RecordItem Classes to include example packets 1797 and other information related to the incident [optional]. 1798 [Free-form text area for any additional information on 1799 incident, IODEF IncidentData Description.] 1801 W3C Encryption and Digital Signature standards: 1803 Digital signature from initiating RID system, passed to all 1804 systems receiving the report using XML digital signature. 1806 Security considerations would include the ability to encrypt the 1807 contents of the Report message request using the public key 1808 of the destination RID system. Senders of a Report message should 1809 note that the information may be used to correlate security 1810 incident information for the purpose of trending, pattern 1811 detection, etc., and may be shared with other parties unless 1812 otherwise agreed upon with the receiving RID system. Therefore, 1813 sending parties of a report message may obfuscate or remove 1814 destination addresses or other sensitive information before 1815 sending a report message. A Report message may be sent either to 1816 file an incident report or in response to an IncidentQuery and 1817 data sensitivity must be considered in both cases. The NPPath 1818 information is not necessary for this message as it will be 1819 communicated directly between two trusted RID systems. 1821 4.4.6 IncidentQuery 1823 Description: The IncidentQuery message is used to request incident 1824 information from a trusted RID system. The request can include the 1825 incident number, if known, or detailed information about the 1826 incident. If the incident number is known, the report message 1827 containing the incident information can easily be returned to the 1828 trusted requestor using automated methods. If an example packet or 1829 other unique information is included in the IncidentQuery, the 1830 return report may be automated; otherwise, analyst intervention may 1831 be required. 1833 The following information is required for an IncidentQuery message 1834 and will be provided through: 1836 RID Information: 1837 RID Policy 1838 RID message type, IncidentID, and destination 1839 Policy information 1840 IODEF Information [optional]: 1841 Time Stamps (DectectTime, StartTime, EndTime, ReportTime) 1842 Incident Identifier (Incident Class, IncidentID) 1843 Trace number - used for multiple traces of a single 1844 incident, must be noted. 1845 Confidence rating of security incident (Impact and Confidence 1846 Class) 1847 System Class is used to list both the Source and Destination 1848 Information used in the attack. 1849 Event, Record, and RecordItem Classes to include example packets 1850 and other information related to the incident [optional]. 1851 [Free-form text area for any additional information on 1852 justification for IncidentQuery, IODEF IncidentData 1853 Description.] 1855 W3C Encryption and Digital Signature standards: 1856 Digital signature from initiating RID system, passed to all 1857 systems receiving the IncidentQuery using XML digital 1858 signature. If a packet is not included, the signature 1859 may be based on the RIDPolicy class. 1861 The proper response to the IncidentQuery message is a Report 1862 message. Multiple reports may be returned for a single query if an 1863 incident type is requested. In this case, the transport would 1864 notify the sending system of the expected number of replies for 1865 proper handling. The Confidence rating may be used in the Incident 1866 Query message to select only incidents with an equal or higher 1867 confidence rating than what is specified. This may be used for 1868 cases when information is gathered on a type of incident but not 1869 on specifics about a single incident. Source and destination 1870 information may not be needed if the IncidentQuery is intended to 1871 gather data about a specific type of incident as well. 1873 4.5 RID Communication Exchanges 1875 The following section outlines the communication flows for RID and 1876 also provides examples of messages. 1878 4.5.1 Upstream Trace Communication Flow 1880 The diagram below outlines the RID TraceRequest communication flow 1881 between RID systems on different networks tracing an attack. 1883 Attack Dest NP-1 NP-2 NP-3 Attack Src 1885 1. Attack | Attack 1886 reported | detected 1887 2. Initiate trace 1888 3. Locate origin 1889 through 1890 upstream NP 1891 4. o---TraceRequest-----> 1892 5. Trace 1893 Initiated 1894 6. <-TraceAuthorization-o 1895 7. Locate origin 1896 through 1897 upstream NP. 1898 8. o---TraceRequest---> 1899 9. Trace Initiated 1900 10. <------------TraceAuthorization----o 1901 11. Locate attack 1902 source on network X 1903 12. <------------Result----------------o 1905 Figure 8: TraceRequest Communication Flow 1907 The NP that detected the attack initiates the trace. The attack 1908 is traced to the source or the next upstream NP. This process 1909 continues until the trace identifies the source of the attack. Any 1910 Trace Authorization and Result messages must pass through all 1911 RID systems in the path back to the trace initiator because of the 1912 secure connections established between RID systems of bordering 1913 networks. The involved systems in the path for Trace Authorization 1914 and Result messages would then have the ability to see and 1915 acknowledge the trace status before sending the messages back along 1916 the RID communication path to the originating RID system. 1918 Before a trace can be initialized, the originating RID system must 1919 check an internal database to determine if a trace to the same IP 1920 address or network address has occurred within a specified period 1921 of time, no less than 1 day. The trace may have been initiated by 1922 the same RID system or this RID system may have been in the path of 1923 the trace. The previous filter must be maintained for a minimum of 1924 one week in order to retrieve the filter for comparison 1925 before initiating a TraceRequest or allowing a trace continuance 1926 to occur. If the network administrator justifies a similar trace, 1927 a note might be added to the Description element of the document to 1928 provide an additional confidence indication to the upstream NPs in 1929 the path of the trace. 1931 A single-network trace may be constrained using factors determined 1932 by the associated NP's network trace system in the path of the 1933 trace. The trace system may either trace a packet in real time or 1934 search through stored packet data for evidence that the packet had 1935 traversed the network. In the case of a real-time trace, the 1936 traffic needs to be active on the network for the trace to be 1937 successful or the trace will cease. A message is sent to indicate 1938 the status, that the trace cannot continue, to the originating RID 1939 system through the consortium's trust relationships formed by the 1940 RID systems in the path of the trace. The packet trace may also be 1941 limited due to the lack of storage space on networks for saving 1942 traffic data. A TraceAuthorization message is sent, in this case 1943 as well, to provide the path information up to the point at which 1944 the trace could no longer be continued to the originator of the 1945 trace through the RID systems in the path of the trace. This 1946 information could also be used to block or mitigate the traffic at 1947 the participating NP closest to the source. 1949 4.5.1.1 RID TraceRequest Example 1951 The example listed is of a TraceRequest based on the incident 1952 report example from the IODEF document. The RID extension classes 1953 were included as appropriate for a TraceRequest message using the 1954 RIDPolicy and NPPath classes. The example given is that of a CSIRT 1955 reporting a DoS attack in progress to the upstream NP. The request 1956 asks the next NP to continue the trace and have the traffic 1957 mitigated closer to the source of the traffic. 1959 1962 1963 TraceRequest 1964 Inter-Consortium 1965 1966 RIDSystem 1967 1968 1969 172.20.1.2 1970 1971 1972 Attack 1973 CERT-FOR-OUR-DOMAIN#207-1 1975 1976 1977 CSIRT-FOR-OUR-DOMAIN 1978 CSIRT123 1979 csirt-for-our-domain@ourdomain 1980 1981 172.17.1.2 1982 1983 1984 1985 1986 CSIRT-FOR-UPSTREAM-NP 1987 CSIRT345 1988 csirt-for-upstream-np@ourdomain 1989 1990 172.20.1.2 1991 1992 1993 1994 1996 1997 1998 CERT-FOR-OUR-DOMAIN#207-1 2000 2001 2002 Host involved in DOS attack 2003 2004 2004-02-02T22:19:24+00:00 2005 2006 2004-02-02T22:49:24+00:00 2007 2008 2004-02-02T23:20:24+00:00 2009 2010 2011 2013 2014 2016 CSIRT-FOR-OUR-DOMAIN 2017 2018 csirt-for-our-domain@ourdomain 2019 2020 2021 2022 Constituency-contact for 10.1.1.2 2023 2024 Constituency-contact@10.1.1.2 2025 2026 2027 2028 CSIRT-FOR-OUR-DOMAIN#207-1 2030 CERT-FOR-OUR-DOMAIN 2031 Notification sent to next upstream 2032 NP closer to 10.1.1.2 2033 2001-09-14T08:19:01+00:00 2034 2035 2036 2037 2038 2039 2040 38765 2041 2042 2043 10.1.1.2 2044 2045 2046 2047 2048 2049 80 2050 2051 2052 192.168.1.2 2053 2054 2055 2056 2058 Rate limit traffic close to 2059 source 2060 2061 2062 2063 450000522ad 2064 90000ff06c41fc0a801020a010102976d0050103e020810d 2065 94a1350021000ad6700005468616e6b20796f7520666f722 2066 06361726566756c6c792072656164696e672074686973205 2067 246432e0a 2068 2069 The IPv4 packet included 2070 was used in the described attack 2071 2072 2073 2074 2075 2076 2077 2079 <-- Digital Signature applied to the RecordItem class using the 2080 XML Digital Signature W3C Recommendations. --> 2082 2083 2085 2086 2087 2088 2089 2090 450000522ad9 2091 0000ff06c41fc0a801020a010102976d0050103e020810d9 2092 4a1350021000ad6700005468616e6b20796f7520666f7220 2093 6361726566756c6c792072656164696e6720746869732052 2094 46432e0a 2095 2096 2097 2098 2099 2101 2102 2103 2105 2107 2108 2109 2111 2112 2113 KiI5+6SnFAs429VNwsoJjHPplmo= 2114 2116 2117 2118 2119 VvyXqCzjoW0m2NdxNeToXQcqcSM80W+JMW+Kn01cS3z3KQwCPeswzg== 2120 2121 2122 2123 2124

/KaCzo4Syrom78z3EQ5SbbB4sF7ey80etKII864WF64B81uRpH5t9j 2125 QTxeEu0ImbzRMqzVDZkVG9xD7nN1kuFw==

2126 li7dzDacuo67Jg7mtqEm2TRuOMU= 2127 Z4Rxsnqc9E7pGknFFH2xqaryRPBaQ01khpMdLRQnG541Awtx/XPaF5 2128 Bpsy4pNWMOHCBiNU0NogpsQW5QvnlMpA== 2129 VFWTD4I/aKni4YhDyYxAJozmj1iAzPLw9Wwd5B+Z9J5E7lHjcAJ+bs 2130 HifTyYdnj+roGzy4o09YntYD8zneQ7lw== 2131 2132 2133 2134 2135 2136 --> 2138 4.5.2 Investigation Request Communication Flow 2140 The diagram below outlines the RID Investigation Request 2141 communication flow between RID systems on different networks for a 2142 security incident with a known source address. 2144 Attack Dest NP-1 NP-2 Attack Src 2146 1. Attack | Attack 2147 reported | detected 2148 2. Determine source 2149 of security incident 2150 3. o---Investigation----> 2151 4. Research 2152 incident and 2153 determine appropriate 2154 actions to take 2155 5. <-------Result-------o 2157 Figure 9: Investigation Communication Flow 2159 4.5.2.1 Example Investigation Request 2161 The following example will only include the RID-specific details. 2162 The IODEF and security measures are similar to the TraceRequest 2163 information, with the exception that the source is known and the 2164 receiving RID system is known to be close to the source. The 2165 source known is indicated in the IODEF document, which allows for 2166 incident sources to be listed as spoofed, if appropriate. 2168 2171 2172 Investigation 2173 PeertoPeer 2174 2175 SourceOfIncident 2176 2177 2178 172.25.1.33 2179 2180 2181 Attack 2182 CERT-FOR-OUR-DOMAIN#208-1 2184 2185 2186 2187 CSIRT-FOR-OUR-DOMAIN 2188 CSIRT123 2189 csirt-for-our-domain@ourdomain 2190 2191 172.17.1.2 2192 2193 2194 2195 2196 CSIRT-FOR-UPSTREAM-NP 2197 CSIRT345 2198 csirt-for-upstream-np@ourdomain 2199 2200 172.20.1.2 2201 2202 2203 2204 2205 <-- IODEF and XML digital signature follow --> 2207 4.5.3 Report Communication 2209 The diagram below outlines the RID Report communication flow 2210 between RID systems on different networks. 2212 NP-1 NP-2 2213 1. Generate incident information 2214 and prepare report message 2215 2. o-------Report-------> 2216 3. File report in database 2218 Figure 10: Report Communication Flow 2220 The Report communication flow is used to provide information on 2221 specific incidents detected on the network. Incident information 2222 may be shared between CSIRTS or participating RID hosts using this 2223 format. When a report is received, the RID system must verify that 2224 the report has not already been filed. The incident number and 2225 incident data, such as the hexidecimal packet and incident class 2226 information, can be used to compare with existing database entries. 2228 4.5.3.1 Report Example 2230 The following example will only include the RID-specific details. 2231 This report is an unsolicited report message that includes an 2232 IPv4 packet. The IODEF document and digital signature would be 2233 similar to the first example provided for this case. 2235 2238 2239 Report 2240 PeertoPeer 2241 2242 RIDSystem 2243 2244 2245 172.17.1.2 2246 2247 2248 Attack 2249 CERT-FOR-OUR-DOMAIN#209-1 2251 2252 2253 2254 CSIRT-FOR-OUR-DOMAIN 2255 CSIRT123 2256 csirt-for-our-domain@ourdomain 2257 2258 172.20.1.2 2259 2260 2261 2262 2263 CSIRT-FOR-REQUESTING-NP 2264 CSIRT345 2265 csirt-for-requesting-np@ourdomain 2266 2267 2268 172.17.1.2 2269 2270 2271 2272 2273 <-- IODEF and XML digital signature follow --> 2275 4.5.4 IncidentQuery Communication Flow 2277 The diagram below outlines the RID IncidentQuery communication flow 2278 between RID systems on different networks. 2280 NP-1 NP-2 2281 1. Generate a request for 2282 information on a specific 2283 incident number or incident type 2284 2. o---IncidentQuery---> 2285 3. Verify policy information 2286 and determine if matches exist 2287 for requested information 2288 4. <-------Report------o 2289 5. Associate report to request 2290 by incident number or type 2291 and file report(s). 2293 Figure 11: IncidentQuery Communication Flow 2295 The IncidentQuery message communication receives a response of a 2296 Report message. If the Report message is empty, the responding 2297 host did not have information available to share with the 2298 requestor. The incident number and responding RID system, as well 2299 as the transport, assist in the association of the request and 2300 response since a report can be filed and is not always solicited. 2302 4.5.4.1 IncidentQuery Example 2304 The IncidentQuery request may be received in several formats as a 2305 result of the type of query being performed. If the incident 2306 number is the only information provided, the IODEF document and IP 2307 packet data may not be needed to complete the request. However, if 2308 a type of incident is requested, the incident number will remain 2309 null and the IP packet data will not be included in the IODEF 2310 RecordItem class and the other incident information will be the 2311 main source for comparison. In the case in which an incident 2312 number may not be the same between CSIRTS, either or both the 2313 incident number and/or IP packet information can be provided and 2314 used for comparison on the receiving RID system to generate a 2315 Report message(s). 2317 2320 2321 IncidentQuery 2322 PeertoPeer 2323 2324 RIDSystem 2325 2326 2327 172.20.1.2 2328 2329 2330 Attack 2331 CERT-FOR-OUR-DOMAIN#210-1 2333 2334 2335 2336 CSIRT-FOR-OUR-DOMAIN 2337 CSIRT123 2338 csirt-for-our-domain@ourdomain 2339 2340 172.17.1.2 2341 2342 2343 2344 2345 CSIRT-FOR-UPSTREAM-NP 2346 CSIRT345 2347 csirt-for-upstream-np@ourdomain 2348 2349 172.20.1.2 2350 2351 2352 2353 2355 5. RID Schema Definition 2357 2358 2360 2366 2369 2372 2383 2385 2389 2390 XML Schema wrapper for IODEF 2391 2392 2393 2394 2395 2396 <-- NPPath must be included in every RID message but is set to 2397 monOccurs 0 for the purpose of proper parsing of the SOAP 2398 header. NPPath is needed for the proper flow and response 2399 of RID messages--> 2400 2402 2403 2404 2405 2406 2408 2410 2411 2412 2413 2414 2416 2418 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2432 2433 2434 2435 2436 2437 2438 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2452 2453 2454 2455 2459 2460 RID Policy used in SOAP header for transport of 2461 messages 2462 2463 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 6. Message Transport 2527 The transport specifications will be fully defined in a separate 2528 document. The specified transport protocols must use encryption to 2529 provide an additional level of security, integrity, and 2530 authentication through bi-directional certificate usage. SOAP [15] 2531 will be used as a wrapper for the RID messages, then a protocol 2532 binding will be used for the overlying transport. Any transport 2533 method defined will take advantage of existing standards for ease 2534 of implementation and integration of RID systems. Session 2535 encryption for the transport RID messages will be enforced in the 2536 transport specification. The privacy and security considerations 2537 are addressed fully in RID and do not rely on the security provided 2538 by the transport layer. The encryption requirements and 2539 considerations for RID are discussed in the Security section of 2540 this document. 2542 XML security functions such as digital signature and encryption 2543 provide a standards-based method to encrypt and digitally sign RID 2544 messages. RID messages specify system use and privacy guidelines 2545 through the RIDPolicy class. Public key infrastructure (PKI) 2546 provides the base for authentication and authorization, encryption, 2547 and digital signatures to establish trust relationships between 2548 members of a RID consortium or a peering consortium. 2550 XML security functions such as the digital signature and encryption 2551 can be used within the contents of the message for privacy and 2552 security in cases for which certain elements must remain encrypted 2553 or signed as they traverse the path of a trace. For example, the 2554 digital signature on a TraceRequest can be used to verify the 2555 identity of the trace originator. The use of the XML security 2556 features in RID messaging will be in accordance with the 2557 specifications for the IODEF model; however, the use requirements 2558 may differ since RID also incorporates communication of security 2559 incident information. 2561 6.1 Message Delivery Protocol - Integrity and Authentication 2563 The RID protocol must be able to guarantee delivery and meet 2564 the necessary security requirements of a state-of-the-art protocol. 2565 In order to guarantee delivery, TCP should be considered as the 2566 underlying protocol within the current network standard practices. 2568 Security considerations must include the integrity, authentication, 2569 privacy, and authorization of the messages sent between RID 2570 communication or NMS systems. The communication between RID 2571 systems must be authenticated and encrypted to ensure the integrity 2572 of the messages and the RID systems involved in the trace. Another 2573 concern that needs to be addressed is authentication for a request 2574 that traverses multiple networks. In this scenario, systems in the 2575 path of the multi-hop TraceRequest need to authorize a trace from 2576 not only their neighbor network, but also from the initiating RID 2577 system as discussed in section 6.3. Several methods can be used to 2578 ensure integrity and privacy of the communication. 2580 The transport mechanism selected (HTTPS, S/MIME, BEEP, etc.) may be 2581 agreed upon by a consortium using RID messaging to ensure 2582 consistency among the peers. Consortiums may vary their selected 2583 transport mechanisms and thus must decide upon a mutual protocol 2584 to use for transport when communicating with peers in a neighboring 2585 consortium using RID. RID systems MUST support HTTPS and 2586 optionally support other protocols such as S/MIME and BEEP. RID, 2587 the XML security functions, and transport protocols must properly 2588 integrate with a public key infrastructure (PKI) managed by the 2589 consortium. Consortiums are discussed in the security and privacy 2590 sections. 2592 6.2 Transport Communication 2594 Out-of-band communications dedicated to NP interaction for RID 2595 messaging would provide additional security as well as guaranteed 2596 bandwidth during a denial-of-service attack. For example, an 2597 out-of-band channel may consist of logical paths defined over the 2598 existing network. Out-of-band communications may not be possible 2599 between all network providers, but should be considered to protect 2600 the network management systems used for RID messaging. 2602 In order to address the integrity and authenticity of messages, 2603 transport encryption MUST be used to secure the traffic sent 2604 between RID systems with pre-defined trust relationships. Systems 2605 with predefined relationships for RID would include those who peer 2606 within a consortium with agreed-upon appropriate use regulations 2607 and for peering consortiums. 2609 Systems used to send authenticated RID messages between networks 2610 MUST use a dedicated and secured interface to connect to a border 2611 Network's RID systems. Each connection to a RID system must meet 2612 the security requirements agreed upon through the consortium 2613 regulations, peering, or SLAs. The RID system interface must only 2614 listen for and send RID messages, which also must be over an 2615 encrypted tunnel meeting the minimum requirement of algorithms and 2616 key lengths established by the consortium, peering, or SLA. The 2617 selected cryptographic algorithms for symmetric encryption, digital 2618 signatures, and hash functions must meet minimum security levels of 2619 the times. The encryption strength must adhere to import and 2620 export regulations of the involved countries for data exchange. 2622 6.3 Authentication of RID Protocol 2624 In order to ensure the authenticity of the RID messages, a 2625 message authentication scheme using a PKI must be inherent to 2626 the protocol. SOAP tied together with TLS used with BEEP or 2627 HTTP(S) using WS-Security requires a trust center such as a PKI 2628 or Kerberos key distribution center for the distribution of 2629 credentials to provide the necessary levels of security for this 2630 protocol. Public key certificate pairs issued by a trusted 2631 Certificate Authority (CA) will be used to provide the necessary 2632 level of authentication and encryption for the RID protocol. The 2633 CA used for RID messaging must be trusted by all involved parties 2634 and may take advantage of similar efforts, such as the Internet2 2635 federated PKI. The PKI infrastructure used for authentication 2636 would also provide the necessary certificates needed for encryption 2637 via either Transport Layer Security (TLS) used in the HTTPS 2638 protocol, BEEP profile, or Secure MIME (S/MIME). 2640 Hosts receiving a RID message, such as a TraceRequest, for 2641 example, must be able to verify that the sender of the request is 2642 valid and trusted. Using digital signatures on a hash of the 2643 RID message with an X.509 version 3 certificate issued by a 2644 trusted party can be used to authenticate the request. The X.509 2645 version 3 specifications as well as the digital signature 2646 specifications and Certificate Revocation List (CRL) Internet 2647 standards set forth in RFC2459 must be followed in order to 2648 interoperate with a PKI designed for similar Internet purposes. 2649 The IODEF specification must be followed for digital signatures to 2650 provide the authentication and integrity aspects required for 2651 secure messaging between network providers. The use of digital 2652 signatures in RID XML messages MUST follow the World Wide Web 2653 Consortium (W3C) recommendations for signature syntax and 2654 processing when either the XML encryption or digital signature is 2655 used within a document. Transport specifications will be detailed 2656 in a separate document. 2658 An optional extension to the authentication scheme would be to 2659 incorporate the use of attribute certificates to provide 2660 authorization capabilities as described in RFC3281. This may be 2661 useful as messages are sent from network peers to determine 2662 authorization levels based on the attribute information in the 2663 certificate, which could be used to determine priority of a trace 2664 request. The attribute information might be used to determine if 2665 a TraceRequest should be processed automatically or if human 2666 intervention is required. 2668 6.4 Authentication Considerations for a Multi-hop TraceRequest 2670 Bilateral trust relations between network providers ensure the 2671 authenticity of requests for TraceRequests from immediate peers 2672 in the web of networks formed to provide the traceback 2673 capability. A network provider several hops into the path of the 2674 RID trace must trust the information from its peer as to the 2675 confidence rating of the attack and the previous trust 2676 relationships in the downstream path. In order to provide a 2677 higher assurance level of the authenticity of the TraceRequest, 2678 the originating RID system is included in the TraceRequest along 2679 with contact information and the information of all RID 2680 systems in the path the trace has taken. 2682 A second measure must be taken to ensure the identity of the 2683 originating RID system. The originating RID system MUST include 2684 a digital signature in the TraceRequest sent to all systems in the 2685 upstream path. The digital signature from the RID system is 2686 performed on the RecordItem class of the IODEF following the XML 2687 digital signature specifications from W3C [22]. The signature 2688 MUST be passed to all parties that receive a TraceRequest, and each 2689 party MUST be able to perform full path validation on the digital 2690 signature. Full path validation verifies the chaining 2691 relationship to a trusted root and also performs certificate 2692 revocation status. In order to accommodate that requirement, the 2693 IP packet in the RecordItem data MUST remain unchanged as a 2694 request is passed along between providers and is the only element 2695 for which the signature is applied. A second benefit to this 2696 requirement is that the integrity of the filter used is ensured as 2697 it is passed to subsequent NPs in the upstream trace of the packet. 2698 The trusted PKI used in section 6.3 will also provide the keys 2699 used to digitally sign the RecordItem class for TraceRequests to 2700 meet the requirement of authenticating the original request. 2701 Since the CA is known and trusted by all parties, any host in the 2702 path of the trace can verify the digital signature. 2704 In the case in which an enterprise network using RID sends a trace 2705 request to its provider, the signature from the enterprise 2706 network must be included in the initial request. The NP may 2707 generate a new request to send upstream to members of the NP 2708 consortium to continue the trace. If the original request is sent, 2709 the originating NP, acting on behalf of the enterprise network 2710 under attack, must also digitally sign the message to assure the 2711 authenticity of the trace. An NP that offers RID as a service may 2712 be using its own PKI to secure RID communications between its 2713 RID system and the attached enterprise networks. NPs participating 2714 in the trace must be able to determine the authenticity of RID 2715 requests at the NP level. 2717 6.4.1 Public Key Infrastructures and Consortiums 2719 Consortiums of NPs are an ideal way to establish a communication 2720 web of trust for RID messaging. The consortium could provide 2721 centralized resources, such as a PKI, and established guidelines 2722 for use of the RID protocol. The consortium would also assist in 2723 establishing trust relationships between the participating NPs to 2724 achieve the necessary level of cooperation and experience-sharing 2725 among the consortium entities. The consortium may also be used for 2726 other purposes to better facilitate communication among NPs in a 2727 common area (Internet, region, government, education, private 2728 networks, etc.). 2730 Using a PKI to distribute certificates used by RID systems provides 2731 an already established method to link trust relationships between 2732 NPs of consortiums that would peer with NPs belonging to a separate 2733 consortium. In other words, consortiums could peer with other 2734 consortiums to enable communication of RID messages between the 2735 participating NPs. The PKI along with Memorandums of Agreement 2736 could be used to link border directories to share public key 2737 information in a bridge, hierarchy, or a single cross-certification 2738 relationship. 2740 Consortiums also need to establish guidelines for each 2741 participating NP to adhere to. The guidelines MUST include 2743 O Physical and logical practices to protect RID systems; 2744 O Network and application layer protection for RID systems and 2745 communications; 2746 O Proper use guidelines for RID systems, messages, and requests; 2747 and 2748 O A PKI to provide authentication, integrity, and privacy. 2750 The functions described for a consortium's role would parallel 2751 that of a PKI federation. The PKI federations that currently exist 2752 are responsible for establishing security guidelines and PKI trust 2753 models. The trust models are used to support applications 2754 to share information using trusted methods and protocols. 2756 PKI can also provide the same level of security for communication 2757 between an end entity (enterprise, educational, government customer 2758 network) and the NP. The PKI may be a subordinate CA or in the CA 2759 hierarchy from the NP's consortium to establish the trust 2760 relationships necessary as the request is made to other connected 2761 networks. 2763 6.5 Privacy Concerns and System Use Guidelines 2765 Privacy issues raise many concerns when information sharing is 2766 required to achieve the goal of stopping or mitigating the effects 2767 of a security incident. The RIDPolicy class is used to automate 2768 the enforcement of the privacy concerns listed within this 2769 document. The privacy and system use concerns that MUST be 2770 addressed in the RID system and other integrated components 2771 include the following: 2773 Network Provider Concerns: 2775 o Privacy of data monitored and/or stored on IDS for attack 2776 detection. 2777 o Privacy of data monitored and stored on systems used to trace 2778 traffic across a single network. 2780 Customer attached networks participating in RID with NP: 2782 O Customer networks may include enterprise, educational, government 2783 or other attached network to an NP participating in RID and MUST 2784 be made fully aware of the security and privacy considerations 2785 for using RID. 2787 O Customers MUST know the security and privacy considerations in 2788 place by their NP and the consortium of which the NP is a member. 2789 O Customers MUST understand that their data can and will be sent to 2790 other NPs in order to complete a trace unless an agreement 2791 stating otherwise is made in the service level agreements between 2792 the customer and NP. 2794 Parties Involved in the Attack: 2796 o Privacy of the identity of a host involved in an attack. 2797 o Privacy of information such as the source and destination used 2798 for communication purposes over the monitored or RID connected 2799 network(s). 2800 o Protection of data from being viewed by intermediate parties 2801 in the path of a Investigation request MUST be considered. 2803 Consortium Considerations: 2805 o System use restricted to security incident handling within the 2806 local region's definitions of appropriate traffic for the network 2807 monitored and linked via RID in a single consortium also abiding 2808 by the consortiums use guidelines. 2809 o System use prohibiting the consortiums participating NPs from 2810 inappropriately tracing non-attack traffic to locate sources or 2811 mitigate traffic unlawfully within the jurisdiction or region. 2813 Inter-consortium Considerations: 2815 o System use between peering consortiums MUST also adhere to any 2816 government communication regulations that apply between those two 2817 regions, such as encryption export and import restrictions. 2818 o System use between consortiums MUST not request traffic traces 2819 and actions beyond the scope intended and permitted by law or 2820 inter-consortium agreements. 2821 o System use between consortiums MUST respect national boundary 2822 issues and limit requests to appropriate system use and not to 2823 achieve their own agenda to limit or restrict traffic that is 2824 otherwise permitted within the country in which the peering 2825 consortium resides. 2827 RID is useful in determining the true source of a packet that 2828 traverses multiple networks or to communicate security incidents 2829 and automate the response. 2831 In order to identify the source and trace multiple networks, the 2832 packet header information along with 8 bytes of payload are used in 2833 the packet identification. The information obtained from the trace 2834 may determine the identity of the source host or the network 2835 provider used by the source of the traffic. It should be noted 2836 that the trace mechanism used across a single-network provider may 2837 also raise privacy concerns for the clients of the network. 2838 Methods that may raise concern include those which involve storing 2839 packets for some length of time in order to trace packets after the 2840 fact. Monitoring networks for intrusions and for tracing 2841 capabilities also raises concerns for potentially sensitive valid 2842 traffic that may be traversing the monitored network. IDS and 2843 single-network tracing is outside of the scope of this document, 2844 but the concern should be noted and addressed within the use 2845 guidelines of the network. Some IDS and single-network trace 2846 mechanisms attempt to properly address these issues. RID is 2847 designed to provide the information needed by any single-network 2848 trace mechanism. The provider's choice of a single trace mechanism 2849 depends on resources, existing solutions, and local legislation. 2850 Privacy concerns in regard to the single-network trace must be 2851 dealt with at the client-to-network provide level and are out of 2852 scope for RID messaging. 2854 The identity of the true source of an attack packet being traced 2855 through RID could be sensitive. The true identity listed in a 2856 Result message can be protected through the use of encryption 2857 on the fields containing the identity, using the public encryption 2858 key for the originating NP. Alternatively, the action taken may be 2859 listed without the identity being revealed to the originating NP. 2860 The ultimate goal of the RID communication system is to stop or 2861 mitigate attack traffic, not to ensure the identity of the attack 2862 traffic is known to involved parties. The NP that identifies the 2863 source needs to deal directly with the involved parties and proper 2864 authorities in order to determine the guidelines for the release of 2865 such information, if it is regarded as sensitive. In some 2866 situations, systems used in attacks are compromised by an unknown 2867 source and, in turn, are used to attack other systems. In that 2868 situation, the reputation of a business or organization may be at 2869 stake, and the action taken may be the only additional information 2870 reported in the Result message to the originating system. If 2871 the security incident is a minor incident, such as a zombie system 2872 used in part of a large-scale DDoS attack, ensuring the system is 2873 taken off the network until it has been fixed may be sufficient. 2874 The textual descriptions should include details of the incident in 2875 order to protect the reputation of the unknowing attacker and 2876 prevent the need for additional investigation. Local, state, or 2877 national laws may dictate the appropriate reporting action for 2878 specific security incidents. 2880 Privacy becomes an issue whenever sensitive data traverses a 2881 network. For example, if an attack occurred between a specific 2882 source and destination, then every network provider in the path of 2883 the trace would become aware that the cyber attack occurred. In a 2884 targeted attack, it may not be desirable for the information that 2885 two nation states are battling a cyber war to become general 2886 knowledge to all intermediate parties. However, it is important to 2887 allow the traces to take place in order to halt the activity since 2888 the health of the networks in the path could also be at stake 2889 during the attack. This provides a second argument for allowing 2890 the Result message to only include an action taken and not 2891 the identity of the offending host. In the case of an 2892 Investigation request, where the originating NP is aware of the NP 2893 that will receive the request for processing, the free-form text 2894 areas of the document could be encrypted using the public key of 2895 the destination NP to ensure that no other NP in the path can read 2896 the contents The encryption would be accomplished through the W3C 2897 specification for encrypting an element. 2899 In some situations, all network traffic of a nation may be granted 2900 through a single network provider. In that situation, options must 2901 support sending Result messages from a downstream peer of 2902 that network provider. That option provides an additional level of 2903 abstraction to hide the identity and the NP of the identified 2904 source of the traffic. Legal action may override this technical 2905 decision after the trace has taken place, but that is out of the 2906 technical scope of this document. 2908 Privacy concerns when using an Investigation Request to request 2909 action close to the source of valid attack traffic needs to be 2910 considered. Although the intermediate NPs relay the request to the 2911 closest NP to the source, the intermediate NPs do not require the 2912 ability to see the contents of the packet or the text description 2913 field(s) in the request. This message type does not require any 2914 action by the intermediate RID systems, except to relay the packet 2915 to the next NP in the path. Therefore, the contents of the request 2916 may be encrypted. The intermediate NPs would only need to know how 2917 to direct the request to the manager of the AS number in which the 2918 source IP address belongs. 2920 Traces must be legitimate security-related incidents and not used 2921 for purposes such as sabotage or censorship. An example of such 2922 abuse of the system would include a request to block or rate-limit 2923 legitimate traffic to prevent information from being shared between 2924 users on the Internet (restricting access to online versions of 2925 papers) or restricting access from a competitor's product in order 2926 to sabotage a business. 2928 Inter-consortium RID communications raise additional issues 2929 especially when the peering consortiums reside in different 2930 regions or nations. TraceRequests and requested actions to 2931 mitigate traffic must adhere to the appropriate use guidelines and 2932 yet prevent abuse of the system. First, the peering consortiums 2933 MUST identify the types of traffic that can be traced between the 2934 borders of the participating NPs of each consortium. The traffic 2935 traced should be limited to security incident-related traffic. 2936 Second, the traces permitted within one consortium if passed to a 2937 peering consortium may infringe upon the peering consortium's 2938 freedom of information laws. An example would be a consortium in 2939 one country permitting a trace of traffic containing objectionable 2940 material, outlawed within that country. The RID trace may be a 2941 valid use of the system within the confines of that country's 2942 network border; however, it may not be permitted to continue across 2943 network boundaries where such content is permitted under law. By 2944 continuing the trace in another country's network, the trace and 2945 response could have the effect of improperly restricting access to 2946 data. A continued trace into a second country may break the laws 2947 and regulations of that nation. Any such traces MUST cease at the 2948 country's border. 2950 The privacy concerns listed in this section have addressed issues 2951 of privacy among the trusted parties involved in a trace within an 2952 NP, a RID consortium, and peering RID consortiums. Data 2953 used for RID communications must also be protected from parties 2954 that are not trusted. This protection is provided through the 2955 authentication and encryption of documents as they traverse the 2956 path of trusted servers. Each RID system MUST perform a 2957 bi-directional authentication when sending a RID message and use 2958 the public encryption key of the upstream or downstream peer to 2959 send a message or document over the network. This means that the 2960 document is decrypted and re-encrypted at each RID system either 2961 via S/MIME or TLS over BEEP or HTTPS. The RID messages must be 2962 decrypted at each RID system in order to properly process the 2963 request or relay the information. Today's processing power is more 2964 than sufficient to handle the minimal burden of encrypting and 2965 decrypting relatively small typical RID messages. 2967 7. Security Considerations 2969 Communication between NPs' RID systems must be protected. An out- 2970 of-band network, either logical or physical, would prevent outside 2971 attacks against RID communication. An out-of-band connection 2972 would be ideal, but not necessarily practical. Authenticated 2973 encrypted tunnels between RID systems MUST be used to provide 2974 confidentiality, integrity, authenticity, and privacy for the data. 2975 Trust relationships are based on consortiums and established trust 2976 relationships of PKI cross certifications of consortiums. By using 2977 SOAP, RIDPolicy information, Transport Layer Security (TLS), and 2978 the XML security features of encryption and digital signatures, 2979 RID takes advantage of existing security standards. The standards 2980 provide clear methods to ensure messages are secure, authenticated, 2981 authorized, meet policy and privacy guidelines, and maintain 2982 integrity. 2984 As specified in the relevant sections of this document, the XML 2985 digital signature and XML encryption are used in the following 2986 cases: 2988 XML Digital Signature 2989 O Originator of the Trace or Investigation Request MUST sign the 2990 RecordItem class data to provide authentication to all 2991 upstream participants in the trace of the origin. This 2992 signature MUST be passed to all recipients of the TraceRequest. 2993 O For all message types, the full RID message MUST be signed by 2994 the sending peer to provide authentication and integrity to the 2995 receiving RID system. 2997 XML Encryption 2998 O The entire message may be encrypted to provide an extra layer 2999 of security between peers so that the message is not only 3000 encrypted for the transport, but also while stored. This 3001 behavior would be agreed upon between peers or a consortium, or 3002 determined on a per message basis based on security 3003 requirements. The RIDPolicy class will be presented in clear 3004 text in the SOAP header. 3005 O An Investigation request, or any other message type that may be 3006 relayed through RID systems other than the intended destination 3007 as a result of trust relationships, may be encrypted for the 3008 intended recipient. This may be necessary if the RID network 3009 is being used for message transfer, the intermediate parties 3010 do not need to have knowledge of the request contents, and a 3011 direct communication path does not exist. In that case, the 3012 RIDPolicy class is used by intermediate parties and is 3013 maintained in the SOAP header in clear text. 3014 O The action taken in the Result message may be encrypted 3015 using the key of the request originator. In that case, the 3016 intermediate parties can view the RIDPolicy information and 3017 know the trace has been completed and do not need to see the 3018 action. If the use of encryption were limited to sections of 3019 the message, the History class information would be 3020 encrypted. Otherwise, the entire message, with the exception 3021 of the RIDPolicy information and incident identifier, could be 3022 encrypted for the originator of the request. The existence 3023 of the Result message for an incident would tell the 3024 intermediate parties used in the path of the trace that the 3025 incident trace has been completed. 3027 Policies between NPs must be established to provide guidelines for 3028 communication. The policy should include communication methods, 3029 security, and fall-back procedures. The policy should establish a 3030 method to protect communications of RID systems between all 3031 bordering NPs. The trust relationships should extend to all 3032 bordering NPs to support tracing and stopping attacks throughout 3033 the network. A fully meshed communication ability would provide 3034 the means for all RID messages to be sent directly to the intended 3035 RID system. If a fully meshed communication system is 3036 not available, messages may have to traverse multiple systems to 3037 reach the intended RID system. Other policy considerations 3038 include how the RegistryHandle and RID system IP address should be 3039 shared. This should also be coupled with any necessary pre-shared 3040 key or certificate (or trusted Security Authority) stored in the 3041 RID system for encryption negotiation where PKI is in use. 3043 Note: The contact information and corresponding IP address for a 3044 network RID system is shared among cooperating networks via 3045 a predefined table. This information may be stored locally in RID 3046 systems or a central database accessible on the secured network 3047 used for inter-NP messaging. The repository can also be used as 3048 the border directory to other consortiums for sharing public key 3049 information necessary to establish and protect communications. 3051 The method of passing a TraceRequest message to subsequent 3052 networks eliminates the need for granting access to remote 3053 entities to configure network equipment on border networks. Access 3054 to network equipment to configure systems for trace continuance 3055 remains in the responsibility of the parties who own and manage 3056 that equipment. Thus, there is no need to share authentication 3057 information with devices outside of the network operation center 3058 managing the device. Network administrators, who have the ability 3059 to base the decision on the available resources and other factors 3060 of their network, maintain control of the continuance of a trace. 3062 8. IANA Considerations 3064 This document uses URNs to describe XML namespaces and XML schemas 3065 conforming to a registry mechanism described in [RFC3688]. 3067 Registration request for the iodef-rid namespace: 3069 URI: urn:ietf:params:xml:ns:iodef-rid-1.0 3071 Registrant Contact: See the "Author's Address" section 10.2 of 3072 this document. 3074 XML: None. Namespace URIs do not represent an XML specification. 3076 Registration request for the iodef-rid XML schema: 3078 URI: urn:ietf:params:xml:schema:iodef-rid-1.0 3080 Registrant Contact: See the "Author's Address" section 10.2 of 3081 this document. 3083 XML: See the "RID Schema Definition" section 5 of this document. 3085 9. Summary 3087 Security incidents and denial-of-service attacks have always been 3088 difficult to trace as a result of the spoofed sources, resource 3089 limitations, and bandwidth utilization problems. Incident response 3090 is often slow even when the IP address is known to be valid because 3091 of the resources required to notify the responsible party of the 3092 attack and then to stop or mitigate the attack traffic. Methods to 3093 identify and trace attacks near real time are essential to 3094 thwarting attack attempts. Network providers need policies and 3095 automated methods to combat the hacker's efforts. NPs need 3096 automated monitoring and response capabilities to identify and 3097 trace attacks quickly without resource-intensive side effects. 3098 Integration with a centralized communication system to coordinate 3099 the detection, tracing, and identification of attack sources on a 3100 single network is essential. RID provides a way to integrate a 3101 network provider's resources for each aspect of attack detection, 3102 tracing, and source identification and extends the communication 3103 capabilities among network providers. The communication is 3104 accomplished through the use of flexible IODEF XML-based documents 3105 that may originate on an IDS system wrapped in a RID message. A 3106 TraceRequest or Investigation request is communicated to an 3107 upstream provider and may result in an upstream trace or in an 3108 action to stop or mitigate the attack traffic. The messages are 3109 communicated among peers with security inherent to the RID 3110 messaging scheme provided through existing standards such as XML 3111 encryption and digital signatures. Policy information is carried 3112 in the RID message itself through the use of the RIDPolicy. RID 3113 provides the timely communication among NPs, which is essential for 3114 incident handling. 3116 10. References 3118 [ISO 9594/8] CCITT Rec. X.509 (1994) | ISO/IEC 9594-8:1994, 3119 Information Technology - Open Systems Interconnection The 3120 Directory: Authentication Framework 3122 [RFC791] "Internet Protocol, DARPA Internet Program, Protocol 3123 Specification." Information Sciences Institute, University of 3124 Southern California. September 1981. 3126 [RFC1213] "Management Information Base for Network Management of 3127 TCP/IP-based Internets: MIB-II." K. McCloghrie and M . Rose. March 3128 1991. 3130 [RFC1215] "A Convention for Defining Traps for use with the SNMP." 3131 M. Rose. March 1991. 3133 [RFC1930] "Guidelines for creation, selection, and registration of 3134 an Autonomous System (AS)." J. Hawkinson and T. Bates. March 1996. 3136 [RFC2246] "The TLS Protocol." T. Dierks and C. Allen. 3137 January 1999. 3139 [RFC2256] "A Summary of the X.500(96) User Schema for use with 3140 LDAPv3." M. Wahl. December 1997. 3142 [RFC2459] "Internet Public Key Infrastructure: Part I: X.509 3143 Certificate and CRL Profile." R. Housley, W. Ford, W. Polk, and 3144 D. Solo. January 1999. 3146 [RFC2527] "Internet X.509 Public Key Infrastructure: Certificate 3147 Policy and Certification Practices Framework." S. Chokhani and 3148 W. Ford. March 1999. 3150 [RFC2528] "Internet X.509 Public Key Infrastructure: 3151 Representation of Key Exchange Algorithm (KEA) Keys in Internet 3152 X.509 Public Key Infrastructure Certificates." R. Housley and 3153 W. Polk. March 1999. 3155 [RFC2720] "Traffic Flow Measurement: Meter MIB." N. Brownlee. 3156 October 1999. 3158 [RFC2722]"Traffic Flow Measurement: Architecture." N. Brownlee, C. 3159 Mills, and G. Ruth. October 1999. 3161 [RFC2723] "SRL: A Language for Describing Traffic Flows and 3162 Specifying Actions for Flow Groups." N. Brownlee. October 1999. 3164 [RFC2827] "Network Ingress Filtering: Defeating Denial of Service 3165 Attacks Which Employ IP Source Address Spoofing." P. Ferguson and 3166 D. Senie. May 2000. 3168 [RFC3688] "The IETF XML Registry", BCP 81, M. Mealling, 3169 January 2004. 3171 [RFC3821] "An Internet Attribute Certificate Profile for 3172 Authorization." S. Farrell and R. Housley. April 2002. 3174 [RFCXXXX] "The Incident Data Exchange Format Data Model and XML 3175 Implementation." J. Meijer, R. Danyliw, and Y. Demchenko. 3176 August 2006. 3177 http://www.ietf.org/internet-drafts/draft-ietf-inch-iodef-08.txt 3179 [RFCXXXX] "Requirements for the Format for INcident information 3180 Exchange," Y. Demchenko, R. Danyliw, and G. Keeni, June 2006. 3181 http://www.ietf.org/internet-drafts/draft-ietf-inch-requirements- 3182 08.txt 3184 [1] Advanced and Authenticated Marking Schemes for IP Traceback. 3185 D. Song and A. Perrig. IEEE INFOCOM 2001. 3187 [2] Applied Cryptography: Protocols, Algoritms, and Source Code 3188 B.C. Schneier. Second edition. John Wiley & Sons. 1996. 3190 [3] "CenterTrack: An IP Overlay Network for Tracing DoS Floods." 3191 R. Stone. 9th Usenix Security Symposium Proceedings. August 3192 2000. 3194 [4] Extensible Markup Language (XML) 1.0 (Second Edition). W3C 3195 Recommendation. T. Bray, E. Maler, J. Paoli, and C. M. Sperberg- 3196 McQueen. October 2000. 3197 http://www.w3.org/TR/2000/REC-xml-20001006 3199 [5] http://www.cisco.com/go/netflow 3201 [6] http://www.info-sec.com/denial/infosece.html-ssi 3203 [7] "Hash Based IP Traceback." A. Snoren, L. Sanchez, C. Jones, 3204 F. Tchakountio, S. Kent, and W. Strayer. SIGCOMM'01. August 2001. 3206 [8] "ICMP Traceback Messages." S. M. Bellovin, M. Leech, and 3207 T. Taylor. Internet Draft: 3208 http://www.ietf.org/proceedings/03mar/I-D/draft-ietf-itrace-04.txt 3209 February 2003. 3211 [9] "Inferring Internet Denial of Service Activity." D. Moore, 3212 G. M. Voelker, and S. Savage. Published in Proceedings 3213 of the 2001 USENIX Security Symposium. 3215 [10] "MULTOPS: A Data-Structure For Bandwidth Attack Detection." 3216 T. M. Gil and M. Poletta. Published in Proceedings of 3217 the 2001 USENIX Security Symposium. 3219 [11] "Network Congestion Monitoring and Detection using the IMI 3220 infrastructure." T. Saitoh, G. Mansfield, and N.Shiratori. 3221 Graduate School of Information Sciences, Tohoku University. 3223 [12] PKCS 5 v2.0 Password-Based Cryptography Standard. RSA Security 3224 http://www.rsasecurity.com/rsalabs/pkcs/pkcs-5/index.html. 3225 March 1999. 3227 [13] PKCS 7 Cryptographic Message Syntax Standard. RSA Security. 3228 http://www.rsasecurity.com/rsalabs/pkcs/pkcs-7/index.html. 3229 May 1997. 3231 [14] "Practical Network support for IP Traceback." S. Savage, 3232 D. Wetherall, A. Karlin, and T. Anderson. SIGCOMM'00. August 2000. 3234 [15] Security Architecture for Open Agent Systems. Vrije 3235 Universiteit. Y. Demchenko, B. Overiender, and H. M. Boonstra. 3236 http://carol.science.uva.nl/~demch/worksinprogress/ 3237 draft-saas-paper03.pdf 3239 [16] "Security in a Web Services World: A Proposed Architecture 3240 and Roadmap." IBM and Microsoft. April 2002. 3241 http://www-106.ibm.com/developerworks/webservices/library/ws-secmap 3243 [17] SOAP Version 1.2 Part 0: Primer. W3C Recommendation. 3244 http://www.w3c.org/TR/REC-soap12-part0-20030624/. 24 June 2004. 3246 [18] SOAP Version 1.2 Part 1:Messaging Framework. W3C 3247 Recommendation. http://www.w3c.org/TR/REC-soap12-part1-20030624/. 3248 24 June 2004. 3250 [19] "Trends in Denial of Service Attack Technology." K. Houle, 3251 G. Weaver, N. Long, and R. Thomas. CERT Coordination Center. 3252 October 2001. 3254 [20] XML Encryption Syntax and Processing, W3C Recommendation. 3255 T. Imamura, B. Dillaway, and E. Simon. December 2002. 3257 http://www.w3.org/TR/xmlenc-core/ 3259 [21] XML Schema. E. Van der Vlist. O'Reilly. 2002. 3261 [22] XML-Signature Syntax and Processing. W3C Recommendation. 3262 M. Bartel, J. Boyer, B. Fox, B. LaMacchia, and E. Simon. February 3263 2002. http://www.w3.org/TR/xmldsig-core/#sec-Design. 3265 10.1 Acknowledgements 3267 Many thanks to coworkers and the Internet community for reviewing 3268 and commenting on the draft as well as providing recommendations to 3269 simplify and secure the protocol: Dr. Robert K. Cunningham, Cynthia 3270 D. McLain, Dr. William Streilein, Iljitsch van Beijnum, Steve 3271 Bellovin, Yuri Demchenko, Jean-Francois Morfin, Jose Nazaro, 3272 Stephen Northcutt, Jeffrey Schiller, Brian Trammell, Roman Danyliw, 3273 and Tony Tauber. 3275 Funding for the RFC Editor function is currently provided by the 3276 Internet Society. 3278 10.2 Author Information 3280 Kathleen M. Moriarty 3281 MIT Lincoln Laboratory 3282 244 Wood Street 3283 Lexington, MA 02420 3284 Email: Moriarty@ll.mit.edu 3286 Intellectual Property Statement 3288 The IETF takes no position regarding the validity or scope of any 3289 Intellectual Property Rights or other rights that might be claimed 3290 to pertain to the implementation or use of the technology described 3291 in this document or the extent to which any license under such 3292 rights might or might not be available; nor does it represent that 3293 it has made any independent effort to identify any such rights. 3294 Information on the procedures with respect to rights in RFC 3295 documents can be found in BCP 78 and BCP 79. 3297 Copies of IPR disclosures made to the IETF Secretariat and any 3298 assurances of licenses to be made available, or the result of an 3299 attempt made to obtain a general license or permission for the use 3300 of such proprietary rights by implementers or users of this 3301 specification can be obtained from the IETF on-line IPR repository 3302 at http://www.ietf.org/ipr. 3304 The IETF invites any interested party to bring to its attention any 3305 copyrights, patents or patent applications, or other proprietary 3306 rights that may cover technology that may be required to implement 3307 this standard. Please address the information to the IETF at 3308 ietf-ipr@ietf.org. 3310 The IETF has been notified of intellectual property rights claimed 3311 in regard to some or all of the specification contained in this 3312 document. For more information consult the online list of claimed 3313 rights. 3315 Disclaimer of Validity 3317 This document and the information contained herein are provided on an 3318 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3319 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3320 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3321 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3322 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3323 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3325 Copyright Statement 3327 Copyright (C) The Internet Society (2006). This document is subject 3328 to the rights, licenses and restrictions contained in BCP 78, and 3329 except as set forth therein, the authors retain all their rights. 3331 Sponsor Information 3333 This work was sponsored by the Air Force under Air Force 3334 Contract FA8721-05-C-0002. 3336 "Opinions, interpretations, conclusions, and recommendations 3337 are those of the author and are not necessarily endorsed 3338 by the United States Government."