idnits 2.17.1 draft-moriarty-post-inch-rid-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document 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 (July 6, 2010) is 5014 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5070 (Obsoleted by RFC 7970) -- Obsolete informational reference (is this intentional?): RFC 5735 (Obsoleted by RFC 6890) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 4 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 Internet-draft EMC 3 Intended status: Informational July 6, 2010 4 draft-moriarty-post-inch-rid-12.txt 5 Expires: January 6, 2011 7 Real-time Inter-network Defense 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on January 10, 2010. 32 Copyright Notice 34 Copyright (c) 2010 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the BSD License. 47 Abstract 49 Network security incidents, such as system compromises, worms, 50 viruses, phishing incidents, and denial of service, typically 51 result in the loss of service, data, and resources both human and 52 system. Network providers and Computer Security Incident Response 53 Teams need to be equipped and ready to assist in communicating and 54 tracing security incidents with tools and procedures in place 55 before the occurrence of an attack. Real-time Inter-network 56 Defense outlines a proactive inter-network communication method to 57 facilitate sharing incident handling data while integrating 58 existing detection, tracing, source identification, and mitigation 59 mechanisms for a complete incident handling solution. Combining 60 these capabilities in a communication system provides a way to 61 achieve higher security levels on networks. Policy guidelines for 62 handling incidents are recommended and can be agreed upon by a 63 consortium using the security recommendations and considerations. 65 TABLE OF CONTENTS 67 Status of this Memo ................................................ 1 69 Copyright Notice ................................................... 1 71 Abstract ........................................................... 2 73 1. Normative and Informative ....................................... 5 74 1.1 Terminology ................................................ 5 75 1.2 Introduction ............................................... 5 76 1.3 Attack Types and RID Messaging ............................. 6 78 2. RID Integration with Network Provider Technologies .............. 8 80 3. Characteristics of Attacks ...................................... 9 81 3.1 Integrating Trace Approaches ............................... 11 82 3.2 Superset of Packet Information for Traces .................. 11 84 4. Communication Between Network Providers ......................... 12 85 4.1 Inter-Network Provider RID Messaging ....................... 14 86 4.2 RID Network Topology ....................................... 16 87 4.3 Message Formats ............................................ 16 88 4.3.1 RID Data Types ....................................... 17 89 4.3.1.1 Boolean ....................................... 17 90 4.3.2 RID Messages and Transport ........................... 17 91 4.3.3 IODEF-RID Schema ..................................... 18 92 4.3.3.1 RequestStatus Class ............................ 19 93 4.3.3.2 IncidentSource Class ........................... 21 94 4.3.3.3 RIDPolicy ..................................... 22 95 4.3.4 RID Namespace ....................................... 25 96 4.4 RID Messages ............................................... 26 97 4.4.1 TraceRequest ......................................... 26 98 4.4.2 RequestAuthorization Message ......................... 27 99 4.4.3 Result Message ....................................... 28 100 4.4.4 Investigation Message Request ........................ 29 101 4.4.5 Report Message ....................................... 30 102 4.4.6 IncidentQuery ........................................ 31 103 4.5 RID Communication Exchanges ................................ 32 104 4.5.1 Upstream Trace Communication Flow .................... 34 105 4.5.1.1 RID TraceRequest Example ....................... 35 106 4.5.1.2 RequestAuthorization Message Example ........... 38 107 4.5.1.3 Result Message Example ......................... 38 108 4.5.2 Investigation Request Communication Flow ............. 41 109 4.5.2.1 Example Investigation Request .................. 41 110 4.5.2.2 RequestAuthorization Message Example ........... 43 111 4.5.3 Report Communication ................................. 44 112 4.5.3.1 Report Example ................................. 44 113 4.5.4 IncidentQuery Communication Flow ..................... 46 114 4.5.4.1 IncidentQuery Example .......................... 46 116 5. RID Schema Definition ........................................... 48 118 6. Security Considerations ......................................... 52 119 6.1 Message Transport .......................................... 53 120 6.2 Message Delivery Protocol - Integrity and Authentication ... 54 121 6.3 Transport Communication .................................... 55 122 6.4 Authentication of RID Protocol ............................. 55 123 6.4.1 Multi-hop TraceRequest Authentication ................ 56 124 6.5 Consortiums and Public Key Infrastructures ................. 58 125 6.6 Privacy Concerns and System Use Guidelines ................. 58 127 7. IANA Considerations ............................................. 63 129 8. Summary ......................................................... 63 131 9. Normative References ............................................ 64 133 10. Informative References ......................................... 65 135 11. Acknowledgements ............................................... 66 137 12. Author Information ............................................. 66 138 1. Normative and Informative 140 The XML schema [4] and transport requirements contained in this 141 document are normative, all other information provided is intended 142 as informative. More specifically, the following sections of this 143 document are intended as informative: 1, 2, 3, the subsections of 4 144 including the introduction to 4, 4.1, and 4.2. 145 The following sections of this document are normative: 146 The sub-sections of 4 including 4.3, 4.4, 4.5, Section 5, 147 and Section 6. 149 1.1 Terminology 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 1.2 Introduction 157 Incident handling involves the detection, reporting, 158 identification, and mitigation of an attack, whether it be a system 159 compromise, socially engineered phishing attack, or a denial of 160 service attack. When an attack is detected, the response may 161 include simply filing a report, notification to the source of the 162 attack, a request for mitigation, or the request to locate the 163 source. One of the more difficult cases is that in which the 164 source of an attack is unknown, requiring the ability to trace the 165 attack traffic iteratively upstream through the network for the 166 possibility of any further actions to take place. In cases when 167 accurate records of an active session between the victim system and 168 the attacker or source system are available, the source is easy to 169 identify. The problem of tracing incidents becomes more difficult 170 when the source is obscured or spoofed, logs are deleted, and the 171 number of sources is overwhelming. If the source of an attack is 172 known or identified, it may be desirable to request actions be 173 taken to stop or mitigate the effects of the attack. 175 Current approaches to mitigating the effects of security incidents 176 are aimed at identifying and filtering or rate-limiting packets 177 from attackers who seek to hide the origin of their attack by 178 source address spoofing from multiple locations. Measures can be 179 taken at network provider (NP) edge routers providing ingress, 180 egress, and broadcast filtering as a recommended best practice in 181 [RFC2827]. 183 Network providers have devised solutions, in-house or commercial, 184 to trace attacks across their backbone infrastructure to either 185 identify the source on their network or on the next upstream 186 network in the path to the source. Techniques such as collecting 187 packets as traffic traverses the network have been implemented to 188 provide the capability to trace attack traffic after an incident 189 has occurred. Other methods use packet-marking techniques or flow- 190 based traffic analysis to trace traffic across the network in real 191 time. The single-network trace mechanisms use similar information 192 across the individual networks to trace traffic. Problems may 193 arise when an attempt is made to have a trace continued through the 194 next upstream network since the trace mechanism and management may 195 vary. 197 In the case in which the traffic traverses multiple networks, there 198 is currently no established communication mechanism for continuing 199 the trace. If the next upstream network has been identified, a 200 phone call might be placed to contact the network administrators in 201 an attempt to have them continue the trace. A communication 202 mechanism is needed to facilitate the transfer of information to 203 continue traces accurately and efficiently to upstream networks. 204 The communication mechanism described in this paper, Real-time 205 Inter-network Defense (RID), takes into consideration the 206 information needed by various single network trace implementations 207 and the requirement for network providers to decide if a trace 208 request should be permitted to continue. The data in RID messages 209 is represented in an Extensible Markup Language (XML) [1] document 210 using the Incident Object Description Exchange Format (IODEF) 211 and RID. By following this model, integration with other aspects of 212 the network for incident handling is simplified. Finally, methods 213 are incorporated into the communication system to indicate what 214 actions need to be taken closest to the source in order to halt or 215 mitigate the effects of the attack at hand. RID is intended to 216 provide a method to communicate the relevant information between 217 Computer Security Incident Response Teams (CSIRTs) while being 218 compatible with a variety of existing and possible future detection 219 tracing and response approaches. 221 Security and privacy considerations are of high concern since 222 potentially sensitive information may be passed through RID 223 messages. RID messaging takes advantage of XML security and 224 privacy policy information set in the RID schema. The RID schema 225 acts as an XML envelope to support the communication of IODEF 226 documents for exchanging or tracing information security incidents. 227 RID messages are encapsulated for transport, which is defined in a 228 separate document. The authentication, integrity, and 229 authorization features each layer has to offer is used to achieve 230 a necessary level of security. 232 1.3 Attack Types and RID Messaging 234 RID messaging is intended for use in coordinating incident handling 235 to locate the source of an attack and stop or mitigate the effects 236 of the attack. The attack types include system or network 237 compromises, denial of service attacks, or other malicious network 238 traffic. RID is essentially a messaging system coordinating attack 239 detection, tracing mechanisms, and the incident handling responses 240 to locate the source of traffic. If a source address is spoofed, a 241 more detailed trace of a packet (RID TraceRequest) would be 242 required to locate the true source. If the source address is 243 valid, the incident handling may only involve the use of routing 244 information to determine what network provider is closest to the 245 source (RID Investigation request) and can assist with the 246 remediation. The type of RID message used to locate a source is 247 determined by the validity of the source address. RID message 248 types are discussed in Section 4.3. 250 DoS [11] attacks are characterized by large amounts of traffic 251 destined for particular Internet locations and can originate from a 252 single or multiple sources. An attack from multiple sources is 253 known as a distributed denial-of-service attack (DDoS). Because 254 DDoS attacks can originate from multiple sources, tracing such an 255 attack can be extremely difficult or nearly impossible. Many 256 TraceRequests may be required to accomplish the task and may 257 require the use of dedicated network resources to communicate 258 incident handling information to prevent a DoS against the RID 259 system and network used for tracing and remediation. Provisions 260 are suggested to reduce the load and prevent the same trace from 261 occurring twice on a single-network backbone discussed in Section 4 262 on communication between NPs. The attacks can be launched from 263 systems across the Internet unified in their efforts or by 264 compromised systems enlisted as "zombies" that are controlled by 265 servers, thereby providing anonymity to the controlling server of 266 the attack. This scenario may require multiple RID traces, one to 267 locate the zombies and an additional one to locate the controlling 268 server. DDoS attacks do not necessarily spoof the source of an 269 attack since there are a large number of source addresses, which 270 make it difficult to trace anyway. DDoS attacks can also originate 271 from a single system or a subset of systems that spoof the source 272 address in packet headers in order to mask the identity of the 273 attack source. In this case, an iterative trace through the 274 upstream networks in the path of the attack traffic may be 275 required. 277 RID traces may also be used to locate a system used in an attack 278 to compromise another system. Compromising a system can be 279 accomplished through one of many attack vectors, using various 280 techniques from a remote host or through local privilege 281 escalation attempts. The attack may exploit a system or 282 application level vulnerability that may be the result of a design 283 flaw or a configuration issue. A compromised system, as described 284 above, can be used to later attack other systems. A single RID 285 Investigation request may be used in this case since it is probable 286 that the source address is valid. Identifying the sources of 287 system compromises may be difficult since an attacker may access 288 the compromised system from various sources. The attacker may also 289 take measures to hide their tracks by deleting log files or by 290 accessing the system through a series of compromised hosts. 291 Iterative RID traces may be required for each of the compromised 292 systems used to obscure the source of the attack. If the source 293 address is valid, an Investigation request may be used in lieu of a 294 full RID TraceRequest. 296 Once an attack has been reported, CSIRTs may want to query other 297 CSIRTs if they have detected an attack or simply report that one 298 has taken place. The Report message can be used to file a report 299 without an action taken and an IncidentQuery can be used to ask if 300 an attack has been seen by another CSIRT. 302 System compromises may result from other security incident types 303 such as worms, Trojans, or viruses. It is often the case that an 304 incident goes unreported even if valid source address information 305 is available because it is difficult to take any action to mitigate 306 or stop the attack. Incident handling is a difficult task for an 307 NP and even at some client locations due to network size and 308 resource limitations. 310 2. RID Integration with Network Provider Technologies 312 For the purpose of this document, a network provider (NP) shall be 313 defined as a backbone infrastructure manager of a network. The 314 network provider's Computer Security Incident Response Team shall 315 be referred to as the CSIRT. The backbone may be that of an 316 organization providing network (Internet or private) access to 317 commercial, personal, government, or educational institutions, or 318 the backbone provider of the connected network. The connected 319 network provider is an extension meant to include Intranet and 320 Extranet providers as well as instances such as a business or 321 educational institute's private network. 323 NPs typically manage and monitor their networks through a 324 centralized network management system (NMS). The acronym NMS will 325 be used to generically represent management systems on a network 326 used for the management of network resources. An Incident Handling 327 System (IHS) is used to communicate RID messages and may be 328 integrated with an NMS as well as other components of the network. 329 The components of the network that may be integrated through the 330 RID messaging system include attack or event detection, network 331 tracing, and network devices to stop the effects of an attack. 333 The detection of security incidents may rely on manual reporting, 334 automated intrusion detection tools, and variations in traffic 335 types or levels on a network. Intrusion detection systems (IDS) 336 may be integrated into the IHS to create IODEF documents or RID 337 messages to facilitate security incident handling. Detection of a 338 security incident is outside the scope of this paper; however, it 339 should be possible to integrate detection methods with RID 340 messaging. 342 RID messaging in an IHS is intended to be flexible in order to 343 accommodate various traceback systems currently in use as well as 344 those that may evolve with technology. RID is intended to 345 communicate the necessary information needed by a trace mechanism 346 to the next upstream NP in the path of a trace. Therefore, a RID 347 message must carry the superset of data required for all tracing 348 systems. If possible, the trace may need to inspect packets to 349 determine a pattern, which could assist reverse path 350 identification. This may be accomplished by inspecting packet 351 header information such as the source and destination IP addresses, 352 ports, and protocol flags to determine if there is a way to 353 distinguish the packets being traced from other packets. A 354 description of the incident along with any available automated 355 trace data should trigger an alert to the NP's CSIRT for 356 further investigation. The various technologies used to trace 357 traffic across a network are described in Section 3.1. 359 Another area of integration is the ability to mitigate or stop 360 attack traffic once a source has been located. Any automated 361 solution should consider the possible side effects to the network. 362 A change control process or a central point for configuration 363 management might be used to ensure that the security of the network 364 and necessary functionality are maintained and that equipment 365 configuration changes are documented. Automated solutions may 366 depend upon the capabilities and current configuration management 367 solutions on a particular network. The solutions may be based on 368 HTTPS or an appropriate protocol defined in the transport 369 specification. 371 3. Characteristics of Attacks 373 The goal of tracing a security incident may be to identify the 374 source or to find a point on the network as close to the origin of 375 the incident as possible. A security incident may be defined as a 376 system compromise, a worm or Trojan infection, or a single- or 377 multiple-source denial-of-service attack. Incident tracing can be 378 used to identify the source(s) of an attack in order to halt or 379 mitigate the undesired behavior. The communication system, 380 RID, described in this paper can be used to trace any type of 381 security incident and allows for actions to be taken when the 382 source of the attack or a point closer to the source is known or 383 has been identified. The purpose of tracing an attack would be to 384 halt or mitigate the effects of the attack through methods such as 385 filtering or rate-limiting the traffic close to the source or 386 by using methods such as taking the host or network offline. 387 Care must also be taken to ensure the system is not abused and to 388 use proper analysis in determining if attack traffic is, in fact, 389 attack traffic at each NP along the path of a trace. 391 Tracing security incidents can be a difficult task since attackers 392 go to great lengths to obscure their identity. In the case of a 393 security incident, the true source might be identified through an 394 existing established connection to the attacker's point of origin. 395 However, the attacker may not connect to the compromised system for 396 a long period of time after the initial compromise or may access 397 the system through a series of compromised hosts spread across the 398 network. Other methods of obscuring the source may include 399 targeting the host with the same attack from multiple sources using 400 both valid and spoofed source addresses. This tactic can be used 401 to compromise a machine and leave the difficult task of locating the 402 true origin for the administrators. Security incidents, including 403 DDoS attacks, can be difficult or nearly impossible to trace 404 because of the nature of the attack. Some of the difficulties in 405 tracing attacks include the following: 407 O the attack originates from multiple sources; 409 O the attack may include various types of traffic meant to 410 consume server resources, such as a SYN flood attack without a 411 significant increase in bandwidth utilization; 413 O the type of traffic could include valid destination services, 414 which cannot be blocked since they are essential services to 415 business, such as DNS servers at an NP or HTTP requests sent to 416 an organization connected to the Internet; 418 O the attack may utilize varying types of packets including TCP, 419 UDP, ICMP, or other IP protocols; 421 O the attack may be from 'zombies', which then require additional 422 searches to locate a controlling server as the true origin of 423 the attack; 425 O the attack may use a very small number of packets from any 426 particular source, thus making a trace after the fact nearly 427 impossible. 429 If the source(s) of the attack cannot be determined from IP address 430 information or tracing the increased bandwidth utilization, it may 431 be possible to trace the traffic based on the type of packets seen 432 by the client. In the case of packets with spoofed source 433 addresses, it is no longer a trivial task to identify the source of 434 an attack. In the case of an attack using valid source addresses, 435 methods such as the traceroute utility can be used to fairly 436 accurately identify the path of the traffic between the source and 437 destination of an attack. If the true source has been identified, 438 actions should be taken to halt or mitigate the effects of the 439 attack by reporting the incident to the NP or the upstream NP 440 closest to the source. In the case of a spoofed source address, 441 other methods can be used to trace back to the source of an attack. 442 The methods include packet filtering, packet hash comparisons, IP 443 marking techniques, ICMP traceback, and packet flow analysis. As 444 in the case of attack detection, tracing traffic across a single 445 network is a function that can be used with RID in order to provide 446 the networked ability to trace spoofed traffic to the source, while 447 RID provides all the necessary information to accommodate the 448 approach used on any single network to accomplish this task. RID 449 can also be used to report attack traffic close to the source where 450 the IP address used was determined to be valid or simply to report 451 that an incident occurred. 453 3.1 Integrating Trace Approaches 455 There have been many separate research initiatives to solve the 456 problem of tracing upstream packets to detect the true source of 457 attack traffic. Upstream packet tracing is currently confined to 458 the borders of a network or an NP's network. Traces require access 459 to network equipment and resources, thus potentially limiting a 460 trace to a specific network. Once a trace reaches the boundaries 461 of a network, the network manager or NP adjacent in the upstream 462 trace must be contacted in order to continue the trace. NPs have 463 been working on individual solutions to accomplish upstream tracing 464 within their own network environments. The tracing mechanisms 465 implemented thus far have included proprietary or custom solutions 466 requiring specific information such as IP packet header data, hash 467 values of the attack packets, or marked packets. Hash values are 468 used to compare a packet against a database of packets that have 469 passed through the network in the case of "Hash Based IP 470 Traceback" [7]. Other research solutions involve marking packets 471 as explained in "ICMP Traceback Messages" [8], "Practical Support 472 for IP Traceback" [10], the IP Flow Information eXport (IPFIX) 473 protocol [RFC3917], and IP Marking [6]. The single network 474 traceback solutions were considered in developing RID to 475 determine the information needed to accomplish an inter-network 476 trace where different solutions may be in place. 478 3.2 Superset of Packet Information for Traces 480 In order for network traffic to be traced across a network, an 481 example packet from the attack must be sent along with the 482 TraceRequest or Investigation request. According to the research 483 for Hash-based IP Traceback, all of the non-changing fields of an 484 IP header along with 8 bytes of payload are required to provide 485 enough information to uniquely trace the path of a packet. The 486 non-changing fields of the packet header and the 8 bytes of payload 487 are the superset of data required by most single-network tracing 488 systems used; limiting the shared data to the superset of the 489 packet header and 8 bytes of payload prevents the need for sharing 490 potentially sensitive information that may be contained in the 491 data portion of a packet. 493 The RecordItem class in the IODEF is used to store a 494 hexadecimal formatted packet including all packet header 495 information plus 8 bytes of payload or the entire packet contents. 496 The above trace systems do not require a full packet, but it may be 497 useful in some cases, so the option is given to allow a full packet 498 to be included in the data model. 500 If a subset of a packet is used, the research presented in "Hash- 501 based IP Traceback", [7] provide guidlelines to establish a minimum 502 requirement for distinguishing packets. The full packet and content 503 SHOULD be provided, but the minimum requirement MUST be provided. 504 The reserach from [7] found that the first 28 invariant bytes of a 505 packet (masked IP header plus the first bytes of the payload) are 506 sufficient to differentiate almost all non-identical IPv4 packets. 507 RID requires the first 28 invariant bytes of an IP v4 packet in 508 order to perform a trace. RID requires the first 48 invariant 509 bytes for an IP v6 packet in order to distinguish the packet in a 510 trace. Refernece [7] for additional details. 512 The input mechanism for packets to be traced should be flexible 513 to allow intrusion detection systems or packet sniffers to provide 514 the information. The system creating the RID message should also 515 use the packet information to populate the Incident class 516 information in order to avoid human error and also allow a system 517 administrator to override the automatically populated information. 519 4. Communication Between Network Providers 521 Note: The introduction and sub-sections 4.1 and 4.2 are 522 informative, with the exception of references to IODEF/RID 523 Transport, [RFCYYYY]. Sub-sections 4.3, 4.4, 4.5 are normative. 525 Expediting the communication between CSIRTs is essential when 526 responding to a security-related incident, which may cross network 527 access points (Internet backbones) between providers. As a result 528 of the urgency involved in this inter-NP security incident 529 communication, there must be an effective system in place to 530 facilitate the interaction. This communication policy or system 531 should involve multiple means of communication to avoid a single 532 point of failure. Email is one way to transfer information about 533 the incident, packet traces, etc. However, e-mail may not be 534 received in a timely fashion or be acted upon with the same urgency 535 as a phone call or other communication mechanism. 537 Each NP should dedicate a phone number to reach a member of their 538 respective CSIRT. The phone number could be dedicated to inter-NP 539 incident communications and must be a hotline that provides a 24x7 540 live response. The phone line should reach someone who would have 541 the authority, expertise, and the means to expedite the necessary 542 action to investigate the incident. This may be a difficult policy 543 to establish at smaller NPs due to resource limitations, so another 544 solution may be necessary. An outside group may be able to serve 545 this function if given the necessary access to the NPs network. 546 The outside resource should be able to mitigate or alleviate the 547 financial limitations and any lack of experienced resource 548 personnel. 550 A technical solution to trace traffic across a single NP may 551 include homegrown or commercial systems for which RID messaging 552 must accommodate the input requirements. The IHS used on the NP's 553 backbone by the CSIRT to coordinate the trace across the single 554 network requires a method to accept and process RID messages and 555 relay trace requests to the system, as well as to wait for 556 responses from the system to continue the RID request process as 557 appropriate. In this scenario, each NP would maintain its own 558 RID/IHS and integrate with a management station used for network 559 monitoring and analysis. An alternative for NPs lacking sufficient 560 resources may be to have a neutral third party with access to the 561 NP's network resources who could be used to perform the incident 562 handling functions. This could be a function of a central 563 organization operating as a CSIRT for the Internet as a whole 564 or within a consortium that may be able to provide centralized 565 resources. Consortiums would consist of a group of NPs and/or 566 CSIRTs that agree to participate in the RID communication protocol 567 with an agreed-upon policy and communication protocol facilitating 568 the secure transport of IODEF/RID XML documents. Transport for RID 569 messages is specified in the IODEF/RID Transport [RFCYYYY] 570 document. 572 One goal of RID is to prevent the need to permit access to other 573 network's equipment through the use of a standard messaging 574 mechanism to enable IHSs to communicate incident handling 575 information to other networks in a consortium or in neighboring 576 networks. The third party mentioned above may be used in this 577 technical solution to assist in facilitating incident handling 578 and possibly traceback through smaller NPs. The RID messaging 579 mechanism may be a logical or physical out-of-band network to 580 ensure the communication is secure and unaffected by the state of 581 the network under attack. The two management methods would 582 accommodate the needs of larger NPs to maintain full management 583 of their network, and the third party option could be available to 584 smaller NPs who lack the necessary human resources to perform 585 incident handling operations. The first method enables the 586 individual NPs to involve their network operations staff to 587 authorize the continuance of a trace or other necessary response to 588 a RID communication request through their network via a 589 notification and alerting system. The out-of-band logical solution 590 for messaging may be permanent virtual circuits configured with a 591 small amount of bandwidth dedicated to RID communications between 592 NPs. 594 The network used for the communication should consist of 595 out-of-band or protected channels (direct communication links) or 596 encrypted channels dedicated to the transport of RID messages. The 597 communication links would be direct connections between network 598 peers who have agreed upon use and abuse policies through the use 599 of a consortium. Consortiums might be linked through policy 600 comparisons and additional agreements to form a larger web or 601 iterative network of peers that correlates to the traffic paths 602 available over the larger web of networks. The maintenance of the 603 individual links is the responsibility of the two network 604 peers hosting the link. Contact information, IP addresses of RID 605 systems and other information must be coordinated between bilateral 606 peers by a consortium and may use existing databases, such as the 607 Routing Arbiter. The security, configuration, and confidence rating 608 schemes of the RID messaging peers must be negotiated by peers and 609 must meet certain overall requirements of the fully connected 610 network (Internet, government, education, etc.) through the peering 611 and/or a consortium-based agreement. 613 RID messaging established with clients of an NP may be negotiated 614 in a contract as part of a value-added service or through a service 615 level agreement. Further discussion is beyond the scope of this 616 document and may be more appropriately handled in network peering 617 or service level agreements. 619 Procedures for incident handling need to be established and well 620 known by anyone that may be involved in incident response. The 621 procedures should also contain contact information for internal 622 escalation procedures, as well as for external assistance groups 623 such as a CSIRT, CCCERT, GIAC, and the FBI or other assisiting 624 government organization in the country of the investigation. 626 4.1 Inter-Network Provider RID Messaging 628 In order to implement a messaging mechanism between RID 629 communication or IHS systems, a standard protocol and format is 630 required to ensure inter-operability between vendors. The messages 631 would have to meet several requirements in order to be meaningful 632 as they traverse multiple networks. RID provides the framework 633 necessary for communication between networks involved in the 634 incident handling, possible traceback, and mitigation of a security 635 incident. Several message types described in Section 4.3 are 636 necessary to facilitate the handling of a security incident. The 637 message types include the Report, IncidentQuery, TraceRequest, 638 RequestAuthorization, Result, and the Investigation request message. 639 The Report message is used when an incident is to be filed on a 640 RID system or associated database, where no further action is 641 required. An IncidentQuery message is used to request information 642 on a particular incident. A TraceRequest message is used when the 643 source of the traffic may have been spoofed. In that case, each 644 network provider in the upstream path who receives a trace request 645 will issue a trace across the network to determine the upstream 646 source of the traffic. The RequestAuthorization and Result 647 messages are used to communicate the status and result of a 648 TraceRequest or Investigation. The Investigation request message 649 would only involve the RID communication systems along the path to 650 the source of the traffic and not the use of network trace systems. 651 The Investigation request leverages the bilateral relationships or 652 a consortium's inter-connections to mitigate or stop problematic 653 traffic close to the source. Routes could determine the fastest 654 path to a known source IP address in the case of an Investigation 655 request. A message sent between RID systems for a TraceRequest or 656 an Investigation request to stop traffic at the source through a 657 bordering network would require the information enumerated below: 659 1. Enough information to enable the network administrators 660 to make a decision about the importance of continuing the trace. 661 2. The incident or IP packet information needed to carry out 662 the trace or investigation. 663 3. Contact information of the origin of the RID communication. The 664 contact information could be provided through the autonomous 665 system number [RFC1930] or NIC handle information listed in the 666 Registry for Internet Numbers or other Internet databases. 667 4. Network path information to help prevent any routing loops 668 through the network from perpetuating a trace. If a RID system 669 receives a TraceRequest containing its own information in the 670 path, the trace must cease and the RID system should generate an 671 alert to inform the network operations staff that a tracing loop 672 exists. 673 5. A unique identifier for a single attack should be used to 674 correlate traces to multiple sources in a DDoS attack. 676 Use of the communication network and the RID protocol must be 677 for pre-approved, authorized purposes only. It is the 678 responsibility of each participating party to adhere to guidelines 679 set forth in both a global use policy for this system and 680 one established though the peering agreements for each bilateral 681 peer or agreed-upon consortium guidelines. The purpose of such 682 policies is to avoid abuse of the system; the policies shall be 683 developed by a consortium of participating entities. The global 684 policy may be dependent on the domain it operates under; for 685 example, a government network or a commercial network such as the 686 Internet would adhere to different guidelines to address the 687 individual concerns. Privacy issues must be considered in public 688 networks such as the Internet. Privacy issues are discussed in the 689 security section along with other requirements that must be agreed 690 upon by participating entities. 692 RID requests must be legitimate security-related incidents and not 693 used for purposes such as sabotage or censorship. An example of 694 such abuse of the system would include a request to rate-limit 695 legitimate traffic to prevent information from being shared between 696 users on the Internet (restricting access to online versions of 697 papers) or restricting access from a competitor's product in order 698 to sabotage a business. 700 The RID system should be configurable to either require user input 701 or automatically continue traces. This feature would enable a 702 network manager to assess the available resources before continuing 703 a trace. A trace initiated from a TraceRequest may cause adverse 704 effects on a network. If the confidence rating is low, it may not 705 be in the NP's best interest to continue the trace. The confidence 706 ratings must adhere to the specifications for selecting the 707 percentage used to avoid abuse of the system. TraceRequests must 708 be issued by authorized individuals from the initiating network, 709 set forth in policy guidelines established through peering or SLA. 711 4.2 RID Network Topology 713 The most basic topology for communicating RID systems would be a 714 direct connection or a bilateral relationship as illustrated below. 716 __________ __________ 717 | | | | 718 | RID |__________-------------___________| RID | 719 |_________| | NP Border | |________| 720 ------------- 722 Figure 1: Direct Peer Topology 724 Within the consortium model, several topologies might be agreed 725 upon and used. One would leverage bilateral network peering 726 relationships of the members of the consortium. The peers for RID 727 would match that of routing peers and the logical network borders 728 would be used. This approach may be necessary for an iterative 729 trace where the source is unknown. The model would look like the 730 above diagram; however, there may be an extensive number of inter- 731 connections of bilateral relationships formed. Also within a 732 consortium model, it may be useful to establish an integrated mesh 733 of networks to pass RID messages. This may be beneficial when the 734 source address is known, and an interconnection may provide a 735 faster route to reach the closest upstream peer to the source of 736 the attack traffic. An example is illustrated below. 738 _______ _______ ______ 740 | | | | | | 741 __| RID |____-------------____| RID |____-------------____| RID |__ 742 |_____| | NP Border | |_____| | NP Border | |_____| 743 | ------------- ------------- | 744 |_______________________________________________________| 745 Direct connection to network that is not an immediate network peer 747 Figure 2: Mesh Peer Topology 749 By using a fully meshed model in a consortium, broadcasting RID 750 requests would be possible, but not advisable. By broadcasting a 751 request, RID peers that may not have carried the attack traffic on 752 their network would be asked to perform a trace for the potential 753 of decreasing the time in which the true source was identified. As 754 a result, many networks would have utilized unnecessary resources 755 for a TraceRequest that may have also been unnecessary. 757 4.3 Message Formats 759 The following section describes the six RID message types which 760 are based on the IODEF model [RFC5070]. The messages are generated 761 and received on RID communication systems on the NP's network. The 762 messages may originate from IODEF messages from intrusion detection 763 servers, CSIRTS, analysts, etc. A RID message uses the IODEF 764 framework with the RID extension, which is encapsulated for 765 transport [RFCYYYY]. Each RID message type, along with an example, 766 is described in the following sections. The IODEF-RID schema is 767 introduced in Section 4.3.3 to support the RID message types in 768 Section 4.3.1. 770 4.3.1 RID Data Types 772 RID is derived from the IODEF data model and inherits all of the 773 data types defined in the IODEF model. One data type is added by 774 RID, BOOLEAN. 776 4.3.1.1 Boolean 778 A boolean value is represented by the BOOLEAN data type. 780 The BOOLEAN data type is implemented as "xs:Boolean" [9] in the 781 schema. 783 4.3.2 RID Messages and Transport 785 The six RID message types follow: 787 1. TraceRequest. This message is sent to the RID system next in 788 the upstream trace. It is used to initiate a TraceRequest or to 789 continue a TraceRequest to an upstream network closer to the 790 source of the origin of the security incident. The TraceRequest 791 would trigger a traceback on the network to locate the source of 792 the attack traffic. 794 2. RequestAuthorization. This message is sent to the initiating RID 795 system from each of the upstream NPs' RID systems to provide 796 information on the request status in the current network. 798 3. Result. This message is sent to the initiating RID system 799 through the network of RID systems in the path of the trace as 800 notification that the source of the attack was located. The Result 801 message is also used to provide the notification of actions taken 802 for an Investigation request. 804 4. Investigation. This message type is used when the source of the 805 traffic is believed not to be spoofed. The purpose of the 806 Investigation message request is to leverage the existing peer 807 relationships in order to notify the network provider closest to 808 the source of the valid traffic of a security-related incident for 809 any necessary actions to be taken. 811 5. Report. This message is used to report a security incident, 812 for which no action is requested. This may be used for the purpose 813 of correlating attack information by CSIRTS, statistics and 814 trending information, etc. 816 6. IncidentQuery. This message is used to request information 817 about an incident or incident type from a trusted RID system. The 818 response is provided through the Report message. 820 When a system receives a RID message, it must be able to 821 determine the type of message and parse it accordingly. The 822 message type is specified in the RIDPolicy class. The RIDPolicy 823 class may also be used by the transport protocol to facilitate the 824 communication of security incident data to trace, investigate, 825 query, or report information security incident information. 827 4.3.3 IODEF-RID Schema 829 There are three classes included in the RID extension required to 830 facilitate RID communications. The RequestStatus class is used 831 to indicate the approval status of a TraceRequest or Investigation 832 request; the IncidentSource class is used to report whether or not 833 a source was found and to identify the source host(s) or 834 network(s); and the RIDPolicy class provides information on the 835 agreed policies and specifies the type of communication message 836 being used. 838 The RID schema acts as an envelope for the IODEF schema to 839 facilitate RID communications. The intent in maintaining a 840 separate schema and not using the AdditionalData extension of IODEF 841 is the flexibility of sending messages between RID hosts. 842 Since RID is a separate schema that includes the IODEF schema, the 843 RID information acts as an envelope, and then the RIDPolicy 844 class can be easily extracted for use by the transport protocol. 845 The security requirements of sending incident information across 846 the network require the use of encryption. The RIDPolicy 847 information is not required to be encrypted, so separating out this 848 data from the IODEF extension removes the need for decrypting and 849 parsing the entire IODEF and RID document to determine how it 850 should be handled at each RID host. 852 The purpose of the RIDPolicy class is to specify the message type 853 for the receiving host, facilitate the policy needs of RID, and 854 provide routing information in the form of an IP address of the 855 destination RID system. 857 The policy information and guidelines are discussed in Section 6.6. 858 The policy is defined between RID peers and within or between 859 consortiums. The RIDPolicy is meant to be a tool to facilitate the 860 defined policies. This MUST be used in accordance with policy set 861 between clients, peers, consortiums, and/or regions. Security, 862 privacy, and confidentiality MUST be considered as specified in 863 this document. 865 The RID Schema is defined as follows: 867 +------------------+ 868 | RID | 869 +------------------+ 870 | ANY | 871 | |<>---{0..1}----[ RIDPolicy ] 872 | ENUM restriction | 873 | ENUM type |<>---{0..1}----[ RequestStatus ] 874 | STRING meaning | 875 | |<>---{0..1}----[ IncidentSource ] 876 +------------------+ 878 Figure 3: The RID Schema 880 The aggregate classes that constitute the RID schema in the 881 iodef-rid namespace are as follows: 883 RIDPolicy 884 Zero or One. The RIDPolicy class is used by all message types 885 to facilitate policy agreements between peers, consortiums or 886 federations as well as to properly route messages. 888 RequestStatus 889 Zero or One. This is used only in Request Authorization messages 890 to report back to the originating RID system if the trace will be 891 continued by each RID system that received a TraceRequest in the 892 path to the source of the traffic. 894 IncidentSource 895 Zero or One. The IncidentSource class is used in the Result message 896 only. The IncidentSource provides the information on the 897 identified source host or network of an attack trace or 898 investigation. 900 Each of the three listed classes may be the only class included in 901 the RID class, hence the option for zero or one. In some cases, 902 RIDPolicy MAY be the only class in the RID definition when used by 903 the transport protocol [RFCYYYY] as that information should be as 904 small as possible and may not be encrypted. The RequestStatus 905 message MUST be able to stand alone without the need for an IODEF 906 document to facilitate the communication, limiting the data 907 transported to the required elements per RFCYYYY. 909 4.3.3.1 RequestStatus Class 911 The RequestStatus class is an aggregate class in the RID class. 913 +--------------------------------+ 914 | RequestStatus | 915 +--------------------------------+ 916 | | 917 | ENUM restriction | 918 | ENUM AuthorizationStatus | 919 | ENUM Justification | 920 | STRING ext-AuthorizationStatus | 921 | STRING ext-Justification | 922 | | 923 +--------------------------------+ 925 Figure 4: The RequestStatus Class 927 The RequestStatus class has five attributes: 929 restriction 930 OPTIONAL. ENUM. This attribute indicates the disclosure 931 guidelines to which the sender expects the recipient to adhere. 932 This guideline provides no real security since it is the choice 933 of the recipient of the document to honor it. This attribute 934 follows the same guidelines as restriction used in IODEF. 936 AuthorizationStatus 937 REQUIRED. ENUM. The listed values are used to provide a 938 response to the requesting CSIRT of the status of a TraceRequest 939 in the current network. 941 1. Approved. The trace was approved and will begin in the current 942 NP. 943 2. Denied. The trace was denied in the current NP. The next 944 closest NP can use this message to filter traffic from the 945 upstream NP using the example packet to help mitigate the 946 effects of the attack as close to the source as possible. The 947 RequestAuthorization message must be passed back to the 948 originator and a Result message used from the closest NP to the 949 source to indicate actions taken in the IODEF History class. 950 3. Pending. Awaiting approval and a time-out period has been 951 reached which resulted in this pending status and 952 RequestAuthorization message being generated. 953 4. ext-value. An escape value used to extend this attribute. See 954 [RFC5070] IODEF Section 5.1. 956 Justification 957 OPTIONAL. ENUM. Provide a reason for a denied or pending 958 message. 959 1. SystemResource. A resource issue exists on the systems that 960 would be involved in the request. 961 2. Authentication. The enveloped digital signature [RFC3275] 962 failed to validate. 963 3. AuthenticationOrigin. The detached digital signature for the 964 original requestor on the IP packet failed to validate. 966 4. Encryption. Unable to decrypt the request. 967 5. Other. There were other reasons this request could not be 968 processed. 969 6. ext-value. An escape value used to extend this attribute. See 970 [RFC5070] IODEF Section 5.1. 972 AuthorizationStatus-ext 973 OPTIONAL. STRING. A means by which to extend the 974 AuthorizationStatus attribute. See [RFC5070] IODEF Section 5.1. 976 Justification-ext 977 OPTIONAL. STRING. A means by which to extend the Justification 978 attribute. See [RFC5070] IODEF Section 5.1. 980 4.3.3.2 IncidentSource Class 982 The IncidentSource class is an aggregate class in the RID class. 984 +-------------------+ 985 | IncidentSource | 986 +-------------------+ 987 | | 988 | ENUM restriction | 989 | |<>-------------[ SourceFound ] 990 | | 991 | |<>---{0..*}----[ Node ] 992 | | 993 +-------------------+ 995 Figure 5: The IncidentSource Class 997 The elements that constitute the IncidentSource class follow: 999 SourceFound 1000 One. BOOLEAN. The Source class indicates if a source was 1001 identified. If the source was identified, it is listed in 1002 the Node element of this class. 1004 True. Source of incident was identified. 1005 False. Source of incident was not identified. 1007 Node 1008 One. The Node class is used to identify a host or network 1009 device, in this case to identify the system communicating RID 1010 messages. 1012 The base definition of the class is reused from the IODEF 1013 specification IODEF 3.16. 1015 The IncidentSource class has one attribute. 1017 restriction 1018 OPTIONAL. ENUM. This attribute indicates the disclosure 1019 guidelines to which the sender expects the recipient to adhere. 1020 This guideline provides no real security since it is the choice 1021 of the recipient of the document to honor it. This attribute 1022 follows the same guidelines as restriction used in IODEF. 1024 4.3.3.3 RIDPolicy 1026 The RIDPolicy class facilitates the delivery of RID messages and is 1027 also referenced for transport in the transport document [RFCYYYY]. 1029 +------------------------+ 1030 | RIDPolicy | 1031 +------------------------+ 1032 | | 1033 | ENUM restriction |<>-------------[ Node ] 1034 | ENUM MsgType | 1035 | ENUM MsgDestination |<>---{0..1}----[ IncidentID ] 1036 | ENUM ext-MsgType | 1037 | ENUM ext-MsgDestination|<>---{1..*}----[ PolicyRegion ] 1038 | | 1039 | |<>---{1..*}----[ TrafficType ] 1040 | | 1041 +------------------------+ 1043 Figure 6: The RIDPolicy Class 1045 The aggregate elements that constitute the RIDPolicy class are as 1046 follows: 1048 Node 1049 One. The Node class is used to identify a host or network 1050 device, in this case to identify the system communicating RID 1051 messages. 1053 The base definition of the class is reused from the IODEF 1054 specification IODEF 3.16. 1056 IncidentID 1057 Zero or one. Global reference pointing back to the IncidentID 1058 defined in the IODEF data model. The IncidentID includes the 1059 name of the CSIRT, an incident number, and an instance of that 1060 incident. The instance number is appended with a dash 1061 separating the values and is used in cases for which it may be 1062 desirable to group incidents. Examples of incidents that may 1063 be grouped would be botnets, DDoS attacks, multiple hops 1064 of compromised systems found during an investigation, etc. 1066 PolicyRegion 1067 One or many. REQUIRED. The values for the attribute region are used 1068 to determine what policy area may require consideration before a 1069 trace can be approved. The PolicyRegion may include multiple 1070 selections from the attribute list in order to fit all possible 1071 policy considerations when crossing regions, consortiums, or 1072 networks. 1074 region 1075 One. ENUM. 1076 1. ClientToNP. An enterprise network initiated the request. 1077 2. NPToClient. An NP passed a RID request to a client or an 1078 enterprise attached network to the NP based on the service 1079 level agreements. 1080 3. IntraConsortium. A trace that should have no restrictions 1081 within the boundaries of a consortium with the agreed-upon use 1082 and abuse guidelines. 1083 4. PeerToPeer. A trace that should have no restrictions between 1084 two peers but may require further evaluation before 1085 continuance beyond that point with the agreed-upon use and 1086 abuse guidelines. 1087 5. Between-Consortiums. A trace that should have no restrictions 1088 between consortiums that have established agreed-upon use and 1089 abuse guidelines. 1090 6. AcrossNationalBoundaries. This selection must be set if the 1091 trace type is anything but a trace of attack traffic with 1092 malicious intent. This must also be set if the traffic request 1093 is based upon regulations of a specific nation that would not 1094 apply to all nations. This is different from the inter- 1095 consortium since it may be possible to have multiple nations as 1096 members of the same consortium, and this option must be 1097 selected if the traffic is of a type that may have different 1098 restrictions in other nations. 1099 7. ext-value. An escape value used to extend this attribute. See 1100 [RFC5070] IODEF Section 5.1. 1102 TrafficType 1103 One or many. REQUIRED. The values for the attribute type are meant 1104 To assist in determining if a trace is appropriate for the NP 1105 receiving the request to continue the trace. Multiple values may 1106 be selected for this element; however, where possible, it should 1107 be restricted to one value which would most accurately describe 1108 the traffic type. 1110 type 1111 One. ENUM. 1112 1. Attack. This option should only be selected if the traffic is 1113 related to a network-based attack. The type of attack MUST 1114 also be listed in more detail in the IODEF Method and Impact 1115 classes for further clarification to assist in determining if 1116 the trace can be continued. ([RFC5070] Sections 3.9 and 3.10.1) 1117 2. Network. This option MUST only be selected when the 1118 trace is related to NP network traffic or routing issues. 1119 3. Content. This category MUST be used only in the case in which 1120 the request is related to the content and regional restrictions 1121 on accessing that type of content exist. This is not malicious 1122 traffic but may include determining what sources or 1123 destinations accessed certain materials available on the 1124 Internet, including, but not limited to, news, technology, or 1125 inappropriate content. 1126 4. OfficialBusiness. This option MUST be used if the traffic 1127 being traced is requested or affiliated with any government or 1128 other official business request. This would be used during 1129 an investigation by government authorities or other government 1130 traces to track suspected criminal or other activities. 1131 5. Other. If this option is selected, a description of the 1132 traffic type MUST be provided so that policy decisions can be 1133 made to continue or stop the trace. The information should be 1134 provided in the IODEF message in the Expectation class or in 1135 the History class using a HistoryItem log. 1136 6. ext-value. An escape value used to extend this attribute. See 1137 [RFC5070] IODEF Section 5.1. 1139 The RIDPolicy class has five attributes 1141 restriction 1142 OPTIONAL. ENUM. This attribute indicates the disclosure 1143 guidelines to which the sender expects the recipient to adhere. 1144 This guideline provides no real security since it is the choice 1145 of the recipient of the document to honor it. This attribute 1146 follows the same guidelines as restriction used in IODEF. 1148 MsgType 1149 REQUIRED. ENUM. The type of RID Message sent. The six types of 1150 messages are described in Section 4.3.1 and can be noted as one of 1151 the six selections below. 1153 1. TraceRequest. This message may be used to initiate a 1154 TraceRequest or to continue a TraceRequest to an upstream 1155 network closer to the source of the origin of the security 1156 incident. 1158 2. RequestAuthorization. This message is sent to the initiating 1159 RID system from each of the upstream RID systems to provide 1160 information on the request status in the current network. 1162 3. Result. This message indicates that the source of the 1163 attack was located and the message is sent to the initiating 1164 RID system through the RID systems in the path of the trace. 1166 4. Investigation. This message type is used when the source of 1167 the traffic is believed to be valid. The purpose of the 1168 Investigation request is to leverage the existing peer or 1169 consortium relationships in order to notify the NP closest to 1170 the source of the valid traffic that some event occurred, which 1171 may be a security-related incident. 1173 5. Report. This message is used to report a security incident, 1174 for which no action is requested in the IODEF expectation 1175 class. This may be used for the purpose of correlating attack 1176 information by CSIRTS, statistics and trending information, 1177 etc. 1179 6. IncidentQuery. This message is used to request information 1180 from a trusted RID system about an incident or incident type. 1182 7. ext-value. An escape value used to extend this attribute. See 1183 [RFC5070] IODEF Section 5.1. 1185 MsgDestination 1186 REQUIRED. ENUM. The destination required at this level may 1187 either be the RID messaging system intended to receive the request 1188 or the source of the incident in the case of an Investigation 1189 request where the RID system that can assist to stop or mitigate 1190 the traffic may not be known and the message has to traverse RID 1191 messaging systems by following the routing path to the closest RID 1192 system to the source of the attack traffic. The Node element 1193 lists either the RID system or the IP of the source, and the 1194 meaning of the value in the Node element is determined by the 1195 MsgDestination element. 1197 1. RIDSystem. The address listed in the Node element of the 1198 RIDPolicy class is the next upstream RID system that will 1199 receive the RID message. 1201 2. SourceOfIncident. The address listed in the Node element of 1202 the RIDPolicy class is the incident source. The IP address 1203 is used to determine the path of RID systems that will 1204 be used to find the closest RID system to the source of an 1205 attack in which the IP used by the source is believed to be 1206 valid and an Investigation message is used. This is not to 1207 be confused with the IncidentSource class as the defined 1208 value here is from an initial trace or investigation request, 1209 not the source used in a Result message. 1210 3. ext-value. An escape value used to extend this attribute. 1211 See [RFC5070] IODEF Section 5.1. 1213 MsgType-ext 1214 OPTIONAL. STRING. A means by which to extend the MsgType 1215 attribute. See [RFC5070] IODEF Section 5.1. 1217 MsgDestination-ext 1218 OPTIONAL. STRING. A means by which to extend the MsgDestination 1219 attribute. See [RFC5070] IODEF Section 5.1. 1221 4.3.4 RID Namespace 1223 The RID schema declares a namespace of "iodef-rid-1.0" and registers 1224 it per [2]. Each IODEF-RID document MUST use the "iodef-rid-1.0" 1225 namespace in the top-level element RID-Document. It can be 1226 referenced as follows: 1228 1638 5. Trace 1639 Initiated 1640 6. <-RequestAuthorization-o 1641 7. Locate origin 1642 through 1643 upstream NP. 1644 8. o---TraceRequest---> 1645 9. Trace Initiated 1646 10. <----------RequestAuthorization----o 1647 <---RequestAuth---o 1648 11. Locate attack 1649 source on network X 1650 12. <------------Result----------------o 1652 Figure 7: TraceRequest Communication Flow 1654 Before a trace is initiated, the RID system should verify if an 1655 instance of the trace or a similar request is not active. The 1656 traces may be resource intensive, therefore providers need to be 1657 able to detect potential abuse of the system or unintentional 1658 resource drains. Information such as the source and destination 1659 information, associated packets, and the incident may be desirable 1660 to maintain for a period of time determined by administrators. 1662 The communication flow demonstrates that a RequestAuthorization 1663 message is sent to both the downstream peer and the original 1664 requester. If a TraceRequest is denied, the downstream peer has 1665 the option to take an action and respond with a Result message. 1666 The originator of the request may follow up with the downstream 1667 peer of the NP involved using an Investigation request to ensure an 1668 action is taken if no response is received. Nothing precludes the 1669 originator of the request from initiating a new trace request 1670 bypassing the NP, which denied the request if a trace is needed 1671 beyond that point. Another option may also be for the initiator to 1672 send an Investigation request to an NP upstream of the NP which 1673 denied the request if enough information was gathered to discern 1674 the true source of the attack traffic from the incident handling 1675 information. 1677 4.5.1.1 RID TraceRequest Example 1679 The example listed is of a TraceRequest based on the incident 1680 report example from the IODEF document. The RID extension classes 1681 were included as appropriate for a TraceRequest message using the 1682 RIDPolicy class. The example given is that of a CSIRT reporting a 1683 DoS attack in progress to the upstream NP. The request asks the 1684 next NP to continue the trace and have the traffic mitigated closer 1685 to the source of the traffic. 1687 In the following example, use of [5] to generate digital signatures 1688 does not currently provide digest algorithm agility, as [5] only 1689 supports SHA-1. A future version of [5] may support additional 1690 digest algorithms to support digest algorithm agility. 1692 1694 1696 1697 1698 192.0.2.3 1699 1700 1701 1702 CERT-FOR-OUR-DOMAIN#207-1 1703 1704 1705 1706 1707 1709 1710 1711 CERT-FOR-OUR-DOMAIN#207-1 1712 1713 2004-02-02T22:49:24+00:00 1714 2004-02-02T22:19:24+00:00 1715 2004-02-02T23:20:24+00:00 1716 Host involved in DOS attack 1717 1718 1719 1720 1721 Constituency-contact for 192.0.2.35 1722 1723 Constituency-contact@192.0.2.35 1724 1725 1726 1727 1728 1729 192.0.2.35 1730 1731 1732 1733 38765 1734 1735 1736 1737 1738 192.0.2.67 1739 1740 1741 1742 80 1743 1744 1745 1746 1747 1748 Rate limit traffic close to source 1749 1750 1751 1752 1753 1754 The IPv4 packet included was used in the described attack 1755 1756 450000522ad9 1757 0000ff06c41fc0a801020a010102976d0050103e020810d9 1758 4a1350021000ad6700005468616e6b20796f7520666f7220 1759 6361726566756c6c792072656164696e6720746869732052 1760 46432e0a 1761 1762 1763 1764 1765 1766 1767 2001-09-14T08:19:01+00:00 1768 1769 CSIRT-FOR-OUR-DOMAIN#207-1 1770 1771 1772 Notification sent to next upstream NP closer to 192.0.2.35 1773 1774 1775 1776 1777 1778 1779 1782 1783 1784 1785 1786 1787 450000522ad9 1788 0000ff06c41fc0a801020a010102976d0050103e020810d9 1789 4a1350021000ad6700005468616e6b20796f7520666f7220 1790 6361726566756c6c792072656164696e6720746869732052 1791 46432e0a 1792 1793 1794 1795 1796 1797 1798 1799 1800 1803 1805 1806 1807 1809 1810 1812 KiI5+6SnFAs429VNwsoJjHPplmo= 1813 1814 1815 1816 VvyXqCzjoW0m2NdxNeToXQcqcSM80W+JMW+Kn01cS3z3KQwCPeswzg== 1817 1818 1819 1820 1821

/KaCzo4Syrom78z3EQ5SbbB4sF7ey80etKII864WF64B81uRpH5t9j 1822 QTxeEu0ImbzRMqzVDZkVG9xD7nN1kuFw==

1823 li7dzDacuo67Jg7mtqEm2TRuOMU= 1824 Z4Rxsnqc9E7pGknFFH2xqaryRPBaQ01khpMdLRQnG541Awtx/XPaF5 1825 Bpsy4pNWMOHCBiNU0NogpsQW5QvnlMpA== 1826 VFWTD4I/aKni4YhDyYxAJozmj1iAzPLw9Wwd5B+Z9J5E7lHjcAJ+bs 1827 HifTyYdnj+roGzy4o09YntYD8zneQ7lw== 1828
1829
1831
1832
1833
1835 4.5.1.2 RequestAuthorization Message Example 1837 The example RequestAuthorization message is in response to the 1838 TraceRequest message listed above. The NP that received the 1839 request is responding to approve the trace continuance in their 1840 network. 1842 1844 1846 1847 1848 192.0.2.67 1849 1850 1851 1852 CERT-FOR-OUR-DOMAIN#207-1 1853 1854 1855 1856 1858 4.5.1.3 Result Message Example 1860 The example Result message is in response to the TraceRequest 1861 listed above. This message type only comes after a 1862 RequestAuthorization within the TraceRequest flow of messages. It 1863 may be a direct response to an Investigation request. This message 1864 provides information about the source of the attack and the actions 1865 taken to mitigate the traffic. 1867 1869 1871 1872 1873 192.0.2.67 1874 1875 1876 1877 CERT-FOR-OUR-DOMAIN#207-1 1878 1879 1880 1881 true 1882 1883 192.0.2.37 1884 1885 1886 1887 1888 1890 1891 1892 CERT-FOR-OUR-DOMAIN#207-1 1893 1894 2004-02-02T22:49:24+00:00 1895 2004-02-02T22:19:24+00:00 1896 2004-02-02T23:20:24+00:00 1897 Host involved in DOS attack 1898 1899 1900 1901 1902 Constituency-contact for 192.0.2.35 1903 1904 Constituency-contact@192.0.2.35 1905 1906 1907 1908 Admin-contact for 192.0.2.35 1909 1910 Admin-contact@10.1.1.2 1911 1912 1913 1914 1915 192.0.2.35 1916 1917 1918 1919 1920 1921 1922 Admin-contact for 192.0.2.3 1923 1924 Admin-contact@192.0.2.3 1925 1926 1927 1928 1929 192.0.2.3 1930 1931 1932 1933 1935 1936 1937 1938 1939 1940 1941 192.0.2.35 1942 1943 1944 1945 38765 1946 1947 1948 1949 1950 192.0.2.67 1951 1952 1953 1954 80 1955 1956 1957 1958 1959 1960 Rate limit traffic close to source 1961 1962 1963 1964 1965 1966 The IPv4 packet included was used in the described attack 1967 1968 450000522ad9 1969 0000ff06c41fc0a801020a010102976d0050103e020810d9 1970 4a1350021000ad6700005468616e6b20796f7520666f7220 1971 6361726566756c6c792072656164696e6720746869732052 1972 46432e0a 1973 1974 1975 1976 1977 1978 1979 2004-02-02T22:53:01+00:00 1980 1981 CSIRT-FOR-OUR-DOMAIN#207-1 1982 1983 1984 Notification sent to next upstream NP closer to 192.0.2.35 1985 1986 1987 1988 2004-02-02T23:07:21+00:00 1989 1990 CSIRT-FOR-NP3#3291-1 1991 1992 1993 Host rate limited for 24 hours 1994 1995 1996 1997 1998 2000 4.5.2 Investigation Request Communication Flow 2002 The diagram below outlines the RID Investigation Request 2003 communication flow between RID systems on different networks for a 2004 security incident with a known source address. The proper response 2005 to an Investigation request is a Result message. If there is a 2006 problem with the request, such as a failure to validate the digital 2007 signature or decrypt the request, a RequestAuthorization message is 2008 sent to the requestor. The RequestAuthorization message should 2009 provide the reason why the message could not be processed. 2011 Attack Dest NP-1 NP-2 Attack Src 2013 1. Attack | Attack 2014 reported | detected 2015 2. Determine source 2016 of security incident 2017 3. o---Investigation----> 2018 4. Research 2019 incident and 2020 determine appropriate 2021 actions to take 2022 5. <-------Result-------o 2024 Figure 8: Investigation Communication Flow 2026 4.5.2.1 Example Investigation Request 2028 The following example only includes the RID-specific details. 2029 The IODEF and security measures are similar to the TraceRequest 2030 information, with the exception that the source is known and the 2031 receiving RID system is known to be close to the source. The 2032 source known is indicated in the IODEF document, which allows for 2033 incident sources to be listed as spoofed, if appropriate. 2035 2037 2040 2041 2042 192.0.2.98 2043 2044 2045 2046 CERT-FOR-OUR-DOMAIN#208-1 2047 2048 2049 2050 2051 2053 2054 2055 CERT-FOR-OUR-DOMAIN#208-1 2056 2057 2004-02-05T08:13:33+00:00 2058 2004-02-05T08:13:31+00:00 2059 2004-02-05T08:13:33+00:00 2060 2004-02-05T08:13:35+00:00 2061 Host involved in DOS attack 2062 2063 2064 2065 2066 Constituency-contact for 192.0.2.35 2067 2068 Constituency-contact@10.1.1.2 2069 2070 2071 2072 2073 2074 192.0.2.35 2075 2076 2077 2078 41421 2079 2080 2081 2082 2083 192.0.2.67 2084 2085 2086 2087 80 2088 2089 2090 2091 2092 2093 Investigate whether source has been compromised 2094 2095 2096 2097 2098 2099 2004-02-05T08:19:01+00:00 2100 2101 CSIRT-FOR-OUR-DOMAIN#208-1 2102 2103 2104 Investigation request sent to NP for 192.0.2.35 2105 2106 2107 2108 2109 2111 4.5.2.2 RequestAuthorization Message Example 2113 The example RequestAuthorization message is in response to the 2114 Investigation request listed above. The NP that received the 2115 request was unable to validate the digital signature used to 2116 authenticate the sending RID system. 2118 2120 2122 2123 2124 192.0.2.67 2125 2126 2127 2128 CERT-FOR-OUR-DOMAIN#208-1 2129 2130 2131 2133 2134 4.5.3 Report Communication 2136 The diagram below outlines the RID Report communication flow 2137 between RID systems on different networks. 2139 NP-1 NP-2 2140 1. Generate incident information 2141 and prepare report message 2142 2. o-------Report-------> 2143 3. File report in database 2145 Figure 9: Report Communication Flow 2147 The Report communication flow is used to provide information on 2148 specific incidents detected on the network. Incident information 2149 may be shared between CSIRTS or participating RID hosts using this 2150 format. When a report is received, the RID system must verify that 2151 the report has not already been filed. The incident number and 2152 incident data, such as the hexidecimal packet and incident class 2153 information, can be used to compare with existing database entries. 2154 The Report message typically does not have a response. If there is 2155 a problem with the Report message, such as a failure to validate 2156 the digital signature [RFC3275] or decrypt the request, a 2157 RequestAuthorization message is sent to the requestor. The 2158 RequestAuthorization message should provide the reason why the 2159 message could not be processed. 2161 4.5.3.1 Report Example 2163 The following example only includes the RID-specific details. 2164 This report is an unsolicited report message that includes an 2165 IPv4 packet. The IODEF document and digital signature would be 2166 similar to the first example provided for this case. 2168 2170 2171 2172 2173 192.0.2.130 2174 2175 2176 2177 CERT-FOR-OUR-DOMAIN#209-1 2178 2179 2180 2182 2183 2185 2186 2187 CERT-FOR-OUR-DOMAIN#209-1 2188 2189 2004-02-05T10:21:08+00:00 2190 2004-02-05T10:21:05+00:00 2191 2004-02-05T10:35:00+00:00 2192 2004-02-05T10:27:38+00:00 2193 Host illicitly accessed admin account 2194 2195 2196 2198 2199 2200 2201 Constituency-contact for 192.0.2.35 2202 2203 Constituency-contact@10.1.1.2 2204 2205 2206 2207 2208 2209 192.0.2.35 2210 2211 2212 2213 32821 2214 2215 2216 2217 2218 192.0.2.67 2219 2220 2221 2222 22 2223 2224 2225 2226 2227 2228 2229 2004-02-05T10:28:00+00:00 2230 2231 CSIRT-FOR-OUR-DOMAIN#209-1 2232 2233 2234 Incident report sent to NP for 192.0.2.35 2235 2237 2238 2239 2240 2242 4.5.4 IncidentQuery Communication Flow 2244 The diagram below outlines the RID IncidentQuery communication flow 2245 between RID systems on different networks. 2247 NP-1 NP-2 2248 1. Generate a request for 2249 information on a specific 2250 incident number or incident type 2251 2. o---IncidentQuery---> 2252 3. Verify policy information 2253 and determine if matches exist 2254 for requested information 2255 4. <-------Report------o 2256 5. Associate report to request 2257 by incident number or type 2258 and file report(s). 2260 Figure 10: IncidentQuery Communication Flow 2262 The IncidentQuery message communication receives a response of a 2263 Report message. If the Report message is empty, the responding 2264 host did not have information available to share with the 2265 requestor. The incident number and responding RID system, as well 2266 as the transport, assist in the association of the request and 2267 response since a report can be filed and is not always solicited. 2268 If there is a problem with the IncidentQuery message, such as a 2269 failure to validate the digital signature or decrypt the request, a 2270 RequestAuthorization message is sent to the requestor. The 2271 RequestAuthorization message should provide the reason why the 2272 message could not be processed. 2274 4.5.4.1 IncidentQuery Example 2276 The IncidentQuery request may be received in several formats as a 2277 result of the type of query being performed. If the incident 2278 number is the only information provided, the IODEF document and IP 2279 packet data may not be needed to complete the request. However, if 2280 a type of incident is requested, the incident number remains 2281 null and the IP packet data will not be included in the IODEF 2282 RecordItem class and the other incident information is the 2283 main source for comparison. In the case in which an incident 2284 number may not be the same between CSIRTS, either or both the 2285 incident number and/or IP packet information can be provided and 2286 used for comparison on the receiving RID system to generate a 2287 Report message(s). 2289 2291 2293 2294 2295 192.0.2.3 2296 2297 2298 2299 CERT-FOR-OUR-DOMAIN#210-1 2300 2301 2302 2303 5. RID Schema Definition 2305 2306 2312 2315 2318 2326 2328 2332 2333 XML Schema wrapper for IODEF 2334 2335 2336 2337 2338 2339 2340 2341 2342 2343 2344 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354 2356 2357 2358 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2375 2376 2377 2378 2379 2380 2381 2382 2384 2385 2386 2387 2388 2392 2393 RID Policy used for transport of 2394 messages 2395 2396 2398 2399 2400 2401 2402 2403 2404 2405 2406 2407 2408 2409 2410 2411 2412 2413 2414 2415 2416 2417 2418 2419 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2433 2434 2435 2436 2437 2438 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2471 2472 2473 2474 6. Security Considerations 2476 Communication between NPs' RID systems must be protected. RID has 2477 many security considerations built into the design of the protocol, 2478 several of which are decribed in the following sub-sections. 2479 For a complete view of security, considerations need to include 2480 the availability, confidentiality, and integrity concerns for the 2481 transport, storage, and exchange of information. 2483 When considering the transport of RID messages, an out- 2484 of-band network, either logical or physical, would prevent outside 2485 attacks against RID communication. An out-of-band connection 2486 would be ideal, but not necessarily practical. Authenticated 2487 encrypted tunnels between RID systems MUST be used to provide 2488 confidentiality, integrity, authenticity, and privacy for the data. 2489 Trust relationships are based on consortiums and established trust 2490 relationships of PKI cross certifications of consortiums. By using 2491 RIDPolicy information, TLS, and the XML security features of 2492 encryption [3] and digital signatures [RFC3275],[5], RID takes 2493 advantage of existing security standards. The standards provide 2494 clear methods to ensure messages are secure, authenticated, 2495 authorized, meet policy and privacy guidelines, and maintain 2496 integrity. 2498 As specified in the relevant sections of this document, the XML 2499 digital signature [RFC3275] and XML encryption [3] are used in the 2500 following cases: 2502 XML Digital Signature 2503 O Originator of the Trace or Investigation Request MUST use a 2504 detached signature to sign at least one of the original IP 2505 packets included in the RecordItem class data to provide 2506 authentication to all upstream participants in the trace of the 2507 origin. All IP packets provided by the originator may be 2508 signed and additional packets added by upstream peers in the 2509 trace may be signed by the peer adding the data, while 2510 maintaining the IP packet and detached signature from the 2511 original requestor. This signature MUST be passed to all 2512 recipients of the TraceRequest. 2513 O For all message types, the full IODEF/RID document MUST be 2514 Signed using an enveloped signature by the sending peer to 2515 provide authentication and integrity to the receiving RID 2516 system. 2518 XML Encryption 2519 O The IODEF/RID document may be encrypted to provide an extra 2520 layer of security between peers so that the message is not only 2521 encrypted for the transport, but also while stored. This 2522 behavior would be agreed upon between peers or a consortium, or 2523 determined on a per message basis based on security 2524 requirements. It should be noted, there are cases for 2525 transport where the RIDPolicy class needs to be presented in 2526 clear text as detailed in the transport document [RFCYYYY]. 2527 O An Investigation request, or any other message type that may be 2528 relayed through RID systems other than the intended destination 2529 as a result of trust relationships, may be encrypted for the 2530 intended recipient. This may be necessary if the RID network 2531 is being used for message transfer, the intermediate parties 2532 do not need to have knowledge of the request contents, and a 2533 direct communication path does not exist. In that case, the 2534 RIDPolicy class is used by intermediate parties and is 2535 maintained in clear text. 2536 O The action taken in the Result message may be encrypted 2537 using the key of the request originator. In that case, the 2538 intermediate parties can view the RIDPolicy information and 2539 know the trace has been completed and do not need to see the 2540 action. If the use of encryption were limited to sections of 2541 the message, the History class information would be encrypted. 2542 Otherwise, it is RECOMMENDED to encrypt the entire IODEF/RID 2543 document, using an enveloped signature, for the originator of 2544 the request. The existence of the Result message for an 2545 incident would tell any intermediate parties used in the path 2546 of the incident investigation that the incident handling has 2547 been completed. 2549 The formation of policies is a very important aspect of using a 2550 messaging system like RID to exchange potentially sensitive 2551 information. Many considerations should be involved for peering 2552 parties and some guidelines to protect the data, systems, and 2553 transport are covered in this section. Policies established 2554 should provide guidelines for communication methods, security, 2555 and fall-back procedures. 2557 The security considerations for the storage and exchange of 2558 information in RID messaging may include adherance to local, 2559 regional, or national regulations in addition to the obligations 2560 to protect client information during an investigation. RID Policy 2561 is a necessary tool for listing the requirements of messages to 2562 provide a method to categorize data elements for proper handling. 2563 Controls are also provided for the sending entity to protect 2564 messages from third parties through XML encryption. 2566 RID provides a method to exchange incident handling request and 2567 Report messages to peer networks. Network administrators, who have 2568 the ability to base the decision on the available resources and 2569 other factors of their network, maintain control of incident 2570 investigations within their own network. Thus, RID provides the 2571 ability for participating networks to manage their own security 2572 controls, leverging the information listed in RIDPolicy. 2574 6.1 Message Transport 2576 The transport specifications is fully defined in a separate 2577 document [RFCYYYY]. The specified transport protocols MUST use 2578 encryption to provide an additional level of security and 2579 integrity, while supporting mutual authentication through 2580 bi-directional certificate usage. Any subsequent transport method 2581 defined should take advantage of existing standards for ease of 2582 implementation and integration of RID systems. Session 2583 encryption for the transport of RID messages is enforced in the 2584 transport specification. The privacy and security considerations 2585 are addressed fully in RID to protect sensitive portions of 2586 documents and provide a method to authenticate the messages. 2587 Therefore, RID messages do not rely on the security provided by 2588 the transport layer alone. The encryption requirements and 2589 considerations for RID are discussed in at the start of Section 2590 6 of this document. 2592 XML security functions such as digital signature [RFC3275] and 2593 encryption [3] provide a standards-based method to encrypt and 2594 digitally sign RID messages. RID messages specify system use and 2595 privacy guidelines through the RIDPolicy class. Public key 2596 infrastructure (PKI) provides the base for authentication and 2597 authorization, encryption, and digital signatures to establish 2598 trust relationships between members of a RID consortium or a 2599 peering consortium. 2601 XML security functions such as the digital signature [RFC3275] and 2602 encryption [3] can be used within the contents of the message for 2603 privacy and security in cases for which certain elements must remain 2604 encrypted or signed as they traverse the path of a trace. For 2605 example, the digital signature on a TraceRequest can be used to 2606 verify the identity of the trace originator. The use of the XML 2607 security features in RID messaging is in accordance with the 2608 specifications for the IODEF model; however, the use requirements 2609 may differ since RID also incorporates communication of security 2610 incident information. 2612 6.2 Message Delivery Protocol - Integrity and Authentication 2614 The RID protocol must be able to guarantee delivery and meet 2615 the necessary security requirements of a state-of-the-art protocol. 2616 In order to guarantee delivery, TCP should be considered as the 2617 underlying protocol within the current network standard practices. 2619 Security considerations must include the integrity, authentication, 2620 privacy, and authorization of the messages sent between RID 2621 communication or IHS systems. The communication between RID 2622 systems must be authenticated and encrypted to ensure the integrity 2623 of the messages and the RID systems involved in the trace. Another 2624 concern that needs to be addressed is authentication for a request 2625 that traverses multiple networks. In this scenario, systems in the 2626 path of the multi-hop TraceRequest need to authorize a trace from 2627 not only their neighbor network, but also from the initiating RID 2628 system as discussed in Section 6.4. Several methods can be used to 2629 ensure integrity and privacy of the communication. 2631 The transport mechanism selected MUST follow the defined transport 2632 protocol [RFCYYYY] when using RID messaging to ensure consistency 2633 among the peers. Consortiums may vary their selected transport 2634 mechanisms and thus must decide upon a mutual protocol to use for 2635 transport when communicating with peers in a neighboring 2636 consortium using RID. RID systems MUST implement and deploy HTTPS 2637 as defined in the transport document [RFCYYYY] and optionally 2638 support other protocols such as BEEP. RID, the XML security 2639 functions, and transport protocols must properly integrate with a 2640 public key infrastructure (PKI) managed by the consortium or one 2641 managed by a trusted entity. For the Internet, an example of an 2642 existing effort that could be leveraged to provide the supporting 2643 PKI could be the American Registry for Internet Numbers (ARIN) 2644 and Regional Internet Registry's (RIR) PKI hierarchy. Consortiums 2645 are discussed in the security and privacy sections. 2647 6.3 Transport Communication 2649 Out-of-band communications dedicated to NP interaction for RID 2650 messaging would provide additional security as well as guaranteed 2651 bandwidth during a denial-of-service attack. For example, an 2652 out-of-band channel may consist of logical paths defined over the 2653 existing network. Out-of-band communications may not be possible 2654 between all network providers, but should be considered to protect 2655 the network management systems used for RID messaging. Methods 2656 to protect the data transport may also be provided through session 2657 encryption. 2659 In order to address the integrity and authenticity of messages, 2660 transport encryption MUST be used to secure the traffic sent 2661 between RID systems. Systems with predefined relationships for 2662 RID would include those who peer within a consortium with agreed- 2663 upon appropriate use regulations and for peering consortiums. 2664 Trust relationships may also be defined through a bridged or 2665 hierarchical PKI in which both peers belong. 2667 Systems used to send authenticated RID messages between networks 2668 MUST use a secured system and interface to connect to a border 2669 Network's RID systems. Each connection to a RID system MUST meet 2670 the security requirements agreed upon through the consortium 2671 regulations, peering, or SLAs. The RID system MUST only listen for 2672 and send RID messages on the designated port, which also MUST be 2673 over an encrypted tunnel meeting the minimum requirement of 2674 algorithms and key lengths established by the consortium, peering, 2675 or SLA. The selected cryptographic algorithms for symmetric 2676 encryption, digital signatures, and hash functions MUST meet 2677 minimum security levels of the times. The encryption strength MUST 2678 adhere to import and export regulations of the involved countries 2679 for data exchange. 2681 6.4 Authentication of RID Protocol 2682 In order to ensure the authenticity of the RID messages, a 2683 message authentication scheme is used to secure the protocol. 2684 XML security functions utilized in RID requires a trust center 2685 such as a PKI for the distribution of credentials to provide the 2686 necessary level of security for this protocol. Layered transport 2687 protocols also utilize encryption and rely on a trust center. 2688 Public key certificate pairs issued by a trusted Certification 2689 Authority (CA) MAY be used to provide the necessary level of 2690 authentication and encryption for the RID protocol. The CA used 2691 for RID messaging must be trusted by all involved parties and may 2692 take advantage of similar efforts, such as the Internet2 federated 2693 PKI or the ARIN/RIR effort to provide PKI to network providers. 2694 The PKI infrastructure used for authentication would also provide 2695 the necessary certificates needed for encryption used for the 2696 transport protocol [RFCYYYY]. 2698 The use of pre-shared keys may be considered for authentication. 2699 If this option is selected, the following standard MUST be 2700 followed: Pre-Shared Key Ciphersuites for Transport Layer Security 2701 [RFC4279]. 2703 Hosts receiving a RID message MUST be able to verify that the 2704 sender of the request is valid and trusted. Using digital 2705 signatures on a hash of the RID message with an X.509 version 3 2706 certificate issued by a trusted party MUST be used to authenticate 2707 the request. The X.509 version 3 specifications as well as the 2708 digital signature specifications and path validation standards set 2709 forth in [RFC5280] MUST be followed in order to interoperate with 2710 a PKI designed for similar purposes. The IODEF specification MUST 2711 be followed for digital signatures to provide the authentication 2712 and integrity aspects required for secure messaging between network 2713 providers. The use of digital signatures in RID XML messages MUST 2714 follow the World Wide Web Consortium (W3C) recommendations for 2715 signature syntax and processing when either the XML encryption [3] 2716 or digital signature [5], [RFC3275] is used within a document. 2717 Transport specifications are detailed in a separate document. 2719 It might be helpful to define an extension to the authentication 2720 scheme that uses attribute certificates [RFC5755] in such a way 2721 that an application could automatically determine whether human 2722 intervention is needed to authorize a request; however, the 2723 specification of such an extension is out of scope for this 2724 document. 2726 6.4.1 Multi-hop TraceRequest Authentication 2728 Bilateral trust relations between network providers ensure the 2729 authenticity of requests for TraceRequests from immediate peers 2730 in the web of networks formed to provide the traceback 2731 capability. A network provider several hops into the path of the 2732 RID trace must trust the information from its and the previous 2733 trust relationships in the downstream path. For practical reasons, 2734 the NPs may want to prioritize incident handling events based upon 2735 the immediate peer for a trace request, the originator, and the 2736 listed confidence rating for the incident. In order to provide a 2737 higher assurance level of the authenticity of the TraceRequest, 2738 the originating RID system is included in the TraceRequest along 2739 with contact information and the information of all RID systems in 2740 the path the trace has taken. This information is provided through 2741 the IODEF EventData class nesting the list of systems and contacts 2742 involved in a trace, while setting the category attribute to 2743 infrastructure. 2745 A second measure MUST be taken to ensure the identity of the 2746 originating RID system. The originating RID system MUST include 2747 a digital signature in the TraceRequest sent to all systems in the 2748 upstream path. The digital signature from the RID system is 2749 performed on the RecordItem class of the IODEF following the XML 2750 digital signature specifications from W3C [5] using a detached 2751 signature. The signature MUST be passed to all parties that 2752 receive a TraceRequest, and each party MUST be able to perform full 2753 path validation on the digital signature. Full path validation 2754 verifies the chaining relationship to a trusted root and also 2755 performs certificate revocation check. In order to accommodate 2756 that requirement, the IP packet in the RecordItem data MUST remain 2757 unchanged as a request is passed along between providers and is the 2758 only element for which the signature is applied. If additional 2759 packets are included in the document at upstream peers, the initial 2760 packet MUST still remain with the detached signature. The 2761 subsequent packets may be signed by the peer adding the incident 2762 information for the investigation. A second benefit to this 2763 requirement is that the integrity of the filter used is ensured as 2764 it is passed to subsequent NPs in the upstream trace of the packet. 2765 The trusted PKI also provides the keys used to digitally sign the 2766 RecordItem class for TraceRequests to meet the requirement of 2767 authenticating the original request. Any host in the path of the 2768 trace should be able to verify the digital signature using the 2769 trusted PKI. 2771 In the case in which an enterprise network using RID sends a 2772 TraceRequest to its provider, the signature from the enterprise 2773 network MUST be included in the initial request. The NP may 2774 generate a new request to send upstream to members of the NP 2775 consortium to continue the trace. If the original request is sent, 2776 the originating NP, acting on behalf of the enterprise network 2777 under attack, MUST also digitally sign, with an enveloped 2778 signature, the full IODEF document to assure the authenticity of 2779 the TraceRequest. An NP that offers RID as a service may be using 2780 its own PKI to secure RID communications between its RID system and 2781 the attached enterprise networks. NPs participating in the trace 2782 MUST be able to determine the authenticity of RID requests. 2784 6.5 Consortiums and Public Key Infrastructures 2786 Consortiums of NPs are an ideal way to establish a communication 2787 web of trust for RID messaging. The consortium could provide 2788 centralized resources, such as a PKI, and established guidelines 2789 for use of the RID protocol. The consortium would also assist in 2790 establishing trust relationships between the participating NPs to 2791 achieve the necessary level of cooperation and experience-sharing 2792 among the consortium entities. This may be established through PKI 2793 certificate policy [RFC3647] reviews to determine the appropriate 2794 trust levels between organizations or entities. The consortium may 2795 also be used for other purposes to better facilitate communication 2796 among NPs in a common area (Internet, region, government, 2797 education, private networks, etc.). 2799 Using a PKI to distribute certificates used by RID systems provides 2800 an already established method to link trust relationships between 2801 NPs of consortiums that would peer with NPs belonging to a separate 2802 consortium. In other words, consortiums could peer with other 2803 consortiums to enable communication of RID messages between the 2804 participating NPs. The PKI along with Memorandums of Agreement 2805 could be used to link border directories to share public key 2806 information in a bridge, hierarchy, or a single cross-certification 2807 relationship. 2809 Consortiums also need to establish guidelines for each 2810 participating NP to adhere to. The RECOMMENDED guidelines include: 2812 O Physical and logical practices to protect RID systems; 2813 O Network and application layer protection for RID systems and 2814 communications; 2815 O Proper use guidelines for RID systems, messages, and requests; 2816 and 2817 O A PKI to provide authentication, integrity, and privacy. 2819 The functions described for a consortium's role would parallel 2820 that of a PKI federation. The PKI federations that currently exist 2821 are responsible for establishing security guidelines and PKI trust 2822 models. The trust models are used to support applications 2823 to share information using trusted methods and protocols. 2825 PKI can also provide the same level of security for communication 2826 between an end entity (enterprise, educational, government customer 2827 network) and the NP. The PKI may be a subordinate CA or in the CA 2828 hierarchy from the NP's consortium to establish the trust 2829 relationships necessary as the request is made to other connected 2830 networks. 2832 6.6 Privacy Concerns and System Use Guidelines 2834 Privacy issues raise many concerns when information sharing is 2835 required to achieve the goal of stopping or mitigating the effects 2836 of a security incident. The RIDPolicy class is used to automate 2837 the enforcement of the privacy concerns listed within this 2838 document. The privacy and system use concerns that MUST be 2839 addressed in the RID system and other integrated components 2840 include the following: 2842 Network Provider Concerns: 2844 o Privacy of data monitored and/or stored on IDS for attack 2845 detection. 2846 o Privacy of data monitored and stored on systems used to trace 2847 traffic across a single network. 2849 Customer attached networks participating in RID with NP: 2851 O Customer networks may include enterprise, educational, government 2852 or other attached network to an NP participating in RID and MUST 2853 be made fully aware of the security and privacy considerations 2854 for using RID. 2855 O Customers MUST know the security and privacy considerations in 2856 place by their NP and the consortium of which the NP is a member. 2857 O Customers MUST understand that their data can and will be sent to 2858 other NPs in order to complete a trace unless an agreement 2859 stating otherwise is made in the service level agreements between 2860 the customer and NP. 2862 Parties Involved in the Attack: 2864 o Privacy of the identity of a host involved in an attack. 2865 o Privacy of information such as the source and destination used 2866 for communication purposes over the monitored or RID connected 2867 network(s). 2868 o Protection of data from being viewed by intermediate parties 2869 in the path of a Investigation request MUST be considered. 2871 Consortium Considerations: 2873 o System use restricted to security incident handling within the 2874 local region's definitions of appropriate traffic for the network 2875 monitored and linked via RID in a single consortium also abiding 2876 by the consortiums use guidelines. 2877 o System use prohibiting the consortiums participating NPs from 2878 inappropriately tracing non-attack traffic to locate sources or 2879 mitigate traffic unlawfully within the jurisdiction or region. 2881 Intra-consortium Considerations: 2883 o System use between peering consortiums MUST also adhere to any 2884 government communication regulations that apply between those two 2885 regions, such as encryption export and import restrictions. 2886 o System use between consortiums MUST NOT request traffic traces 2887 and actions beyond the scope intended and permitted by law or 2888 intra-consortium agreements. 2889 o System use between consortiums MUST respect national boundary 2890 issues and limit requests to appropriate system use and not to 2891 achieve their own agenda to limit or restrict traffic that is 2892 otherwise permitted within the country in which the peering 2893 consortium resides. 2895 The security and privacy considerations listed above are for the 2896 consortiums, NPs, and Enterprises to agree upon. The agreed upon 2897 policies may be facilitated through use of the RIDPolicy class. 2898 Some privacy considerations are addressed through the RID 2899 guidelines for encryption and digital signatures as described at 2900 the start of Section 6. 2902 RID is useful in determining the true source of a packet that 2903 traverses multiple networks or to communicate security incidents 2904 and automate the response. The information obtained from the trace 2905 may determine the identity of the source host or the network 2906 provider used by the source of the traffic. It should be noted 2907 that the trace mechanism used across a single-network provider may 2908 also raise privacy concerns for the clients of the network. 2909 Methods that may raise concern include those, which involve storing 2910 packets for some length of time in order to trace packets after the 2911 fact. Monitoring networks for intrusions and for tracing 2912 capabilities also raises concerns for potentially sensitive valid 2913 traffic that may be traversing the monitored network. IDS and 2914 single-network tracing is outside of the scope of this document, 2915 but the concern should be noted and addressed within the use 2916 guidelines of the network. Some IDS and single-network trace 2917 mechanisms attempt to properly address these issues. RID is 2918 designed to provide the information needed by any single-network 2919 trace mechanism. The provider's choice of a single trace mechanism 2920 depends on resources, existing solutions, and local legislation. 2921 Privacy concerns in regard to the single-network trace must be 2922 dealt with at the client-to-NP level and are out of scope for RID 2923 messaging. 2925 The identity of the true source of an attack packet being traced 2926 through RID could be sensitive. The true identity listed in a 2927 Result message can be protected through the use of encryption [3] 2928 enveloping the IODEF document and RID Result information, using the 2929 public encryption key of the originating NP. Alternatively, the 2930 action taken may be listed without the identity being revealed to 2931 the originating NP. The ultimate goal of the RID communication 2932 system is to stop or mitigate attack traffic, not to ensure the 2933 identity of the attack traffic is known to involved parties. The 2934 NP that identifies the source should deal directly with the 2935 involved parties and proper authorities in order to determine the 2936 guidelines for the release of such information, if it is regarded 2937 as sensitive. In some situations, systems used in attacks are 2938 compromised by an unknown source and, in turn, are used to attack 2939 other systems. In that situation, the reputation of a business or 2940 organization may be at stake, and the action taken may be the only 2941 additional information reported in the Result message to the 2942 originating system. If the security incident is a minor incident, 2943 such as a zombie system used in part of a large-scale DDoS attack, 2944 ensuring the system is taken off the network until it has been 2945 fixed may be sufficient. The decision is left to the system users 2946 and consortiums to determine appropriate data to be shared given 2947 that the goal of the specification is to provide the appropriate 2948 technical options to remain compliant. The textual descriptions 2949 should include details of the incident in order to protect the 2950 reputation of the unknowing attacker and prevent the need for 2951 additional investigation. Local, state, or national laws may 2952 dictate the appropriate reporting action for specific security 2953 incidents. 2955 Privacy becomes an issue whenever sensitive data traverses a 2956 network. For example, if an attack occurred between a specific 2957 source and destination, then every network provider in the path of 2958 the trace would become aware that the cyber attack occurred. In a 2959 targeted attack, it may not be desirable for the information that 2960 two nation states are battling a cyber war to become general 2961 knowledge to all intermediate parties. However, it is important to 2962 allow the traces to take place in order to halt the activity since 2963 the health of the networks in the path could also be at stake 2964 during the attack. This provides a second argument for allowing 2965 the Result message to only include an action taken and not 2966 the identity of the offending host. In the case of an 2967 Investigation request, where the originating NP is aware of the NP 2968 that will receive the request for processing, the free-form text 2969 areas of the document could be encrypted [3] using the public key 2970 of the destination NP to ensure that no other NP in the path can 2971 read the contents. The encryption would be accomplished through 2972 the W3C [3] specification for encrypting an element. 2974 In some situations, all network traffic of a nation may be granted 2975 through a single network provider. In that situation, options must 2976 support sending Result messages from a downstream peer of 2977 that network provider. That option provides an additional level of 2978 abstraction to hide the identity and the NP of the identified 2979 source of the traffic. Legal action may override this technical 2980 decision after the trace has taken place, but that is out of the 2981 technical scope of this document. 2983 Privacy concerns when using an Investigation request to request 2984 action close to the source of valid attack traffic needs to be 2985 considered. Although the intermediate NPs may relay the request if 2986 there is no direct trust relationship to the closest NP to the 2987 source, the intermediate NPs do not require the ability to see the 2988 contents of the packet or the text description field(s) in the 2989 request. This message type does not require any action by the 2990 intermediate RID systems, except to relay the packet to the next NP 2991 in the path. Therefore, the contents of the request may be 2992 encrypted for the destination system. The intermediate NPs would 2993 only need to know how to direct the request to the manager of the 2994 AS number in which the source IP address belongs. 2996 Traces must be legitimate security-related incidents and not used 2997 for purposes such as sabotage or censorship. An example of such 2998 abuse of the system would include a request to block or rate-limit 2999 legitimate traffic to prevent information from being shared between 3000 users on the Internet (restricting access to online versions of 3001 papers) or restricting access from a competitor's product in order 3002 to sabotage a business. 3004 Intra-consortium RID communications raise additional issues 3005 especially when the peering consortiums reside in different 3006 regions or nations. TraceRequests and requested actions to 3007 mitigate traffic must adhere to the appropriate use guidelines and 3008 yet prevent abuse of the system. First, the peering consortiums 3009 MUST identify the types of traffic that can be traced between the 3010 borders of the participating NPs of each consortium. The traffic 3011 traced should be limited to security incident-related traffic. 3012 Second, the traces permitted within one consortium if passed to a 3013 peering consortium may infringe upon the peering consortium's 3014 freedom of information laws. An example would be a consortium in 3015 one country permitting a trace of traffic containing objectionable 3016 material, outlawed within that country. The RID trace may be a 3017 valid use of the system within the confines of that country's 3018 network border; however, it may not be permitted to continue across 3019 network boundaries where such content is permitted under law. By 3020 continuing the trace in another country's network, the trace and 3021 response could have the effect of improperly restricting access to 3022 data. A continued trace into a second country may break the laws 3023 and regulations of that nation. Any such traces MUST cease at the 3024 country's border. 3026 The privacy concerns listed in this section address issues 3027 among the trusted parties involved in a trace within an NP, a RID 3028 consortium, and peering RID consortiums. Data used for RID 3029 communications must also be protected from parties that are not 3030 trusted. This protection is provided through the authentication 3031 and encryption of documents as they traverse the path of trusted 3032 servers. Each RID system MUST perform a bi-directional 3033 authentication when sending a RID message and use the public 3034 encryption key of the upstream or downstream peer to send a message 3035 or document over the network. This means that the document is 3036 decrypted and re-encrypted at each RID system either via TLS over 3037 the transport protocol [RFCYYYY]. The RID messages may be 3038 decrypted at each RID system in order to properly process the 3039 request or relay the information. Today's processing power is more 3040 than sufficient to handle the minimal burden of encrypting and 3041 decrypting relatively small typical RID messages. 3043 7. IANA Considerations 3045 This document uses URNs to describe XML namespaces and XML schemas 3046 [4] conforming to a registry mechanism described in [RFC3688]. 3048 Registration request for the iodef-rid namespace: 3050 URI: urn:ietf:params:xml:ns:iodef-rid-1.0 3052 Registrant Contact: See the "Author's Address" Section 12 of 3053 this document. 3055 XML: None. Namespace URIs do not represent an XML specification. 3057 Registration request for the iodef-rid XML schema: 3059 URI: urn:ietf:params:xml:schema:iodef-rid-1.0 3061 Registrant Contact: See the "Author's Address" Section 12 of 3062 this document. 3064 XML: See the "RID Schema Definition" Section 5 of this document. 3066 8. Summary 3068 Security incidents have always been difficult to trace as a result 3069 of the spoofed sources, resource limitations, and bandwidth 3070 utilization problems. Incident response is often slow even when 3071 the IP address is known to be valid because of the resources 3072 required to notify the responsible party of the attack and then to 3073 stop or mitigate the attack traffic. Methods to identify and trace 3074 attacks near real time are essential to thwarting attack attempts. 3075 Network providers need policies and automated methods to combat the 3076 hacker's efforts. NPs need automated monitoring and response 3077 capabilities to identify and trace attacks quickly without 3078 resource-intensive side effects. Integration with a centralized 3079 communication system to coordinate the detection, tracing, and 3080 identification of attack sources on a single network is essential. 3081 RID provides a way to integrate NP resources for each aspect of 3082 attack detection, tracing, and source identification and extends 3083 the communication capabilities among network providers. The 3084 communication is accomplished through the use of flexible IODEF XML 3085 based documents passed between IHS or RID systems. A TraceRequest 3086 or Investigation request is communicated to an upstream NP and may 3087 result in an upstream trace or in an action to stop or mitigate the 3088 attack traffic. The messages are communicated among peers with 3089 security inherent to the RID messaging scheme provided through 3090 existing standards such as XML encryption and digital signatures. 3091 Policy information is carried in the RID message itself through the 3092 use of the RIDPolicy. RID provides the timely communication among 3093 NPs, which is essential for incident handling. 3095 9. Normative References 3097 [RFC2119] "Key words for use in RFCs to Indicate Requirement 3098 Levels", S. Bradner. March 1997. 3100 [RFC3275] "(Extensible Markup Language) XML-Signature Syntax and 3101 Processing", D. Eastlake 3rd, J. Reagle, D. Solo. March 2002. 3103 [RFC3688] "The IETF XML Registry", BCP 81, M. Mealling. 3104 January 2004. 3106 [RFC4279] "Pre-Shared Key Ciphersuites for Transport Layer 3107 Security (TLS)", P. Eronen, H. Tschofenig. December 2005. 3109 [RFC5070] "The Incident Object Description Exchange Format." R. 3110 Danyliw, J. Meijer, and Y. Demchenko. December 2007. 3112 [RFC5280] "Internet X.509 Public Key Infrastructure: Certificate 3113 and Certificate Revocation List (CRL) Profile." D. Cooper, S. 3114 Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk. 3115 May 2008. 3117 [RFC5755] "An Internet Attribute Certificate: Profile for 3118 Authorization." S. Farrell, R. Housley, and S. Turner. 3119 January 2010. 3121 [RFCYYYY] "Transport of Real-time Inter-network Defense (RID) 3122 Messages," K. Moriarty, B. Trammell June 2009. 3123 http://tools.ietf.org/html/draft-moriarty-post-inch-rid- 3124 transport-00 3126 [1] Extensible Markup Language (XML) 1.0 (Second Edition). W3C 3127 Recommendation. T. Bray, E. Maler, J. Paoli, and C. M. Sperberg- 3128 McQueen. October 2000. 3129 http://www.w3.org/TR/2000/REC-xml-20001006 3131 [2] Namespaces in XML. W3C Recommendation. T.Bray, D. Hollander, 3132 A. Layman, R. Tobin. August 2006. 3133 http://www.w3.org/TR/REC-xml-names/ 3135 [3] XML Encryption Syntax and Processing, W3C Recommendation. 3136 T. Imamura, B. Dillaway, and E. Simon. December 2002. 3137 http://www.w3.org/TR/xmlenc-core/ 3139 [4] XML Schema. E. Van der Vlist. O'Reilly. 2002. 3141 [5] XML-Signature Syntax and Processing. W3C Recommendation. 3142 M. Bartel, J. Boyer, B. Fox, B. LaMacchia, and E. Simon. June 3143 2008. http://www.w3.org/TR/xmldsig-core/#sec-Design. 3145 10. Informative References 3147 [RFC1930] "Guidelines for creation, selection, and registration of 3148 an Autonomous System (AS)." J. Hawkinson and T. Bates. March 1996. 3150 [RFC2827] "Network Ingress Filtering: Defeating Denial of Service 3151 Attacks Which Employ IP Source Address Spoofing." P. Ferguson and 3152 D. Senie. May 2000. 3154 [RFC3647] "Internet X.509 Public Key Infrastructure: Certificate 3155 Policy and Certification Practices Framework." S. Chokhani, W. 3156 W. Ford, R. Sabett, C. Merrill, S. Wu. November 2003. 3158 [RFC3917] "Requirements for IP Flow Information Export (IPFIX)". 3159 J. Quittek, T. Zseby, B. Claise, S. Zander. October 2004. 3161 [RFC5735] "Special-Use IPv4 Addresses." M. Cotton and L. Vegoda. 3162 January 2010. 3164 [6] Advanced and Authenticated Marking Schemes for IP Traceback. 3165 D. Song and A. Perrig. IEEE INFOCOM 2001. 3167 [7] "Hash Based IP Traceback." A. Snoren, L. Sanchez, C. Jones, 3168 F. Tchakountio, S. Kent, and W. Strayer. SIGCOMM'01. August 2001. 3170 [8] "ICMP Traceback Messages." S. M. Bellovin, M. Leech, and 3171 T. Taylor. Internet Draft: 3172 http://www.ietf.org/proceedings/03mar/I-D/draft-ietf-itrace-04.txt 3173 February 2003. 3175 [9] "Network Congestion Monitoring and Detection using the IMI 3176 infrastructure." T. Saitoh, G. Mansfield, and N.Shiratori. 3177 Graduate School of Information Sciences, Tohoku University. 3179 [10] "Practical Network support for IP Traceback." S. Savage, 3180 D. Wetherall, A. Karlin, and T. Anderson. SIGCOMM'00. August 2000. 3182 [11] "Trends in Denial of Service Attack Technology." K. Houle, 3183 G. Weaver, N. Long, and R. Thomas. CERT Coordination Center. 3184 October 2001. 3186 11. Acknowledgements 3188 Many thanks to coworkers and the Internet community for reviewing 3189 and commenting on the draft as well as providing recommendations to 3190 simplify and secure the protocol: Robert K. Cunningham, Ph.D, 3191 Cynthia D. McLain, Dr. William Streilein, Iljitsch van Beijnum, 3192 Steve Bellovin, Yuri Demchenko, Jean-Francois Morfin, Stephen 3193 Northcutt, Jeffrey Schiller, Brian Trammell, Roman Danyliw, Tony 3194 Tauber, and Sandra G. Dykes, Ph.D. 3196 Funding for the RFC Editor function is currently provided by the 3197 Internet Society. 3199 12. Author Information 3201 Kathleen M. Moriarty 3202 RSA, The Security Division of EMC 3203 174 Middlesex Turnpike 3204 Bedford, MA 01730 3205 Email: Moriarty_Kathleen@EMC.com 3207 Sponsor Information 3209 This work was sponsored by the Air Force under Air Force 3210 Contract FA8721-05-C-0002, while working at MIT Lincoln Laboratory. 3212 "Opinions, interpretations, conclusions, and recommendations 3213 are those of the author and are not necessarily endorsed 3214 by the United States Government."