RFC 6545

Real-time Inter-network Defense (RID)

📅 published April 2012, from ietf

🎀 Part 1 of 20. More parts are coming, bestie! 🫶

RFC 6545: Real-time Inter-network Defense (RID) 🦋

okay bestie, so this is RFC 6545, called Real-time Inter-network Defense (RID) ✨ It's an IETF doc, and the author is K. Moriarty over at EMC. It came out in April 2012, and it's a Standards Track doc, which means it's the real deal, not just a suggestion 💅 It's listed as ISSN 2070-1721. It obsoletes RFC 6045, so this one replaces the older version, and its header doesn't list any Updates. Main character energy for sure 👑

Abstract ✨

so, security incidents are the worst 😭 System compromises, worms, viruses, phishing, and denial of service all tend to cost you service, data, and resources, both human and system. Service providers and CSIRTs (Computer Security Incident Response Teams) need to already have their tools and procedures in place before an attack happens, not scramble after 💀

That's where Real-time Inter-network Defense (RID) comes in 🛡️ It's a proactive way for networks to talk to each other so they can share incident-handling data. It also plays nicely with the detection, tracing, source identification, and mitigation tools you already have, so you get a complete incident-handling setup. Put it all in one communication system and you get higher security levels across networks 🔥 The doc also says policy guidelines for handling incidents are recommended, and a consortium can agree on them using the security recommendations and considerations 🤝 And yes, this document obsoletes RFC 6045 🦋

Status of This Memo

this one is an Internet Standards Track document 🎀

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🫶 It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741.

For the current status, any errata, or to send feedback, go to http://www.rfc-editor.org/info/rfc6545 🌸

Copyright Notice

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc 📜 Any Code Components pulled out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as the Simplified BSD License says 💜

   1. Introduction ....................................................3
      1.1. Changes from RFC 6045 ......................................5
      1.2. Normative and Informative ..................................6
      1.3. Terminology ................................................7
   2. Characteristics of Incidents ....................................7
   3. Communication between CSIRTs and Service Providers ..............8
      3.1. Inter-Service-Provider RID Messaging ......................10
      3.2. RID Communication Topology ................................12
   4. Message Formats ................................................13
      4.1. RID Data Types ............................................13
           4.1.1. Boolean ............................................13
      4.2. RID Message Types .........................................14
   5. IODEF-RID Schema ...............................................15
      5.1. RIDPolicy Class ...........................................17
           5.1.1. ReportSchema .......................................23
      5.2. RequestStatus .............................................26
      5.3. IncidentSource ............................................28
      5.4. RID Name Spaces ...........................................29
      5.5. Encoding ..................................................29
      5.6. Including IODEF or Other XML Documents ....................29
           5.6.1. Including XML Documents in RID .....................30
   6. RID Messages ...................................................31
      6.1. Request ...................................................31
      6.2. Acknowledgement ...........................................33
      6.3. Result ....................................................34
      6.4. Report ....................................................36
      6.5. Query .....................................................38
   7. RID Communication Exchanges ....................................39
      7.1. Upstream Trace Communication Flow .........................40
           7.1.1. RID TraceRequest Example ...........................43
           7.1.2. Acknowledgement Message Example ....................47
           7.1.3. Result Message Example .............................47
      7.2. Investigation Request Communication Flow ..................50
           7.2.1. Investigation Request Example ......................51
           7.2.2. Acknowledgement Message Example ....................53
      7.3. Report Communication Flow .................................54
           7.3.1. Report Example .....................................54
      7.4. Query Communication Flow ..................................56
           7.4.1. Query Example ......................................57
   8. RID Schema Definition ..........................................58
   9. Security Requirements ..........................................62
      9.1. XML Digital Signatures and Encryption .....................62
      9.2. Message Transport .........................................66
      9.3. Public Key Infrastructure .................................67
           9.3.1. Authentication .....................................68
           9.3.2. Multi-Hop Request Authentication ...................69
      9.4. Consortiums and Public Key Infrastructures ................70
      9.5. Privacy Concerns and System Use Guidelines ................71
      9.6. Sharing Profiles and Policies .............................76
   10. Security Considerations .......................................77
   11. Internationalization Issues ...................................77
   12. IANA Considerations ...........................................78
   13. Summary .......................................................80
   14. References ....................................................80
      14.1. Normative References .....................................80
      14.2. Informative References ...................................82
   Appendix A. Acknowledgements ......................................84

1. Introduction 🎀

okay so organizations need help from other parties all the time 🫶 To identify incidents, stop malicious stuff from hitting their computing resources, and get insight into possible threats, they share info with each other. That coordination can look like working with a service provider (SP) to filter attack traffic, working with an SP to fix a config issue that's accidentally causing chaos, contacting a remote site to take down a bot network, or passing around watch-lists of known malicious IP addresses within a consortium 🕸️ In this doc, "SP" means any kind of service provider or Computer Security Incident Response Team (CSIRT) that might be involved in RID communications 💜

Handling an incident means detecting it, reporting it, identifying it, and mitigating it. That could be a harmless config issue, an IT incident, a breach of a service level agreement (SLA), a system compromise, a socially engineered phishing attack, a denial-of-service (DoS) attack, and so on 😭 When something gets detected, the response might be as simple as filing a report, notifying whoever the source is, asking an SP to resolve or mitigate it, or asking someone to track down the source. The really tricky case is when you don't know where the attack is coming from. Then you have to trace the attack traffic upstream, step by step, through the network, so you can figure out what to do next 🔍 If you have accurate records of an active session between the target or victim system and the source or attacking system, though, the source is easy to spot 🦋

Real-time inter-network defense (RID) is a proactive way for networks to talk to each other and share incident-handling data 🛡️ It works alongside the detection, tracing, source identification, and mitigation tools you already have, for a complete incident handling solution ✨ RID gives you a secure way to pass incident info around, and that info is in the form of Incident Object Description and Exchange Format (IODEF) [RFC5070] Extensible Markup Language (XML) documents 📄 RID also thinks about security, policy, and privacy for all that potentially sensitive info, so SPs or organizations can make the calls that fit their own policies 🔐 It has provisions for confidentiality, integrity, and authentication, so it's giving protected 💖

The data in RID messages is written as an XML [XML1.0] document that uses IODEF and RID. Because of that, it's way easier to plug into the other pieces of incident handling 🧩 The system also has methods to say what actions should happen closest to the source, so the incident or attack can be halted or mitigated 🎯 RID is meant to pass the relevant info between CSIRTs, and it stays compatible with a bunch of current and possible future detection, tracing, and response approaches 🌈 Incidents can also cover Information Technology (IT) incidents, and RID lets providers communicate about non-security IT incidents, either between providers or inside one 💅

Security and privacy are a huge deal here because RID messages can carry potentially sensitive info 🙈 RID messaging uses the XML security, privacy, and policy info that's set in the RID schema, which defines the communication-specific metadata for passing IODEF documents around, whether that's for exchanging info or tracing it about incidents ⭐ RID messages get encapsulated for transport, and that's defined in a separate document [RFC6546] 🚚 The authentication, integrity, and authorization features of RID and RID transport are what get you the level of security you need 🔥

Coordinating with other CSIRTs isn't only a technical problem, lowkey. There are plenty of procedural, trust, and legal considerations that might stop an org from sharing info 🙃 RID gives organizations info and options, and then they apply their own policies to decide what to share 🫶 And organizations must develop policies and procedures for using the RID protocol and IODEF 📋

1.1. Changes from RFC 6045 ✨

okay so this doc has a whole glow-up compared to its predecessor [RFC6045] 💅 here's the tea:

this one is Standards Track 🎀, while [RFC6045] was Informational
this doc obsoletes [RFC6045] and moves it to Historic status 🕰️
it refers to the updated RID transport spec [RFC6546] wherever that makes sense 🦋
the RID updates are mostly glow-ups to the informational bits 🌸 (the descriptions now make clear that IODEF and RID work for ALL kinds of incidents, not just network security ones 🙌). The focus shifted from attacks to incidents where it fits, and "network provider" became the more generic "service provider" 👑. Some intro sections got cut because they weren't needed to implement the protocol:
- 1.3. Attack Types and RID Messaging,
- 2. RID Integration with Network Provider Technologies,
- 3.1. Integrating Trace Approaches, and
- 3.2. Superset of Packet Information for Traces.
there's a new star topology option in an informational section, because people who report incident info need it now 🌟
the schema version got bumped 🔥. Big changes:
- IODEF [RFC5070] now gets enveloped in RID inside the RIDPolicy class, using the new ReportSchema class
- one verified erratum got folded in
- more enumerations were added to the Justification attribute
- the AcrossNationalBoundaries region enumeration got removed
- DataWithHandlingRequirements was added to TrafficTypes
- the RequestAuthorization MsgType is now Acknowledgement, which better matches what it actually does 💜

Some enumerated values got clearer definitions too, and lang was added at the RID class level for language support 🌈. Also, the note now says this message can be used in response to Query and Report messages.

TraceRequest and Investigation got smooshed into ONE message 🫶. You set the MsgType based on what automation you need. Since both were Requests, Investigation is now InvestigationRequest, and the content can vary inside the IODEF doc depending on the Request type.
IncidentQuery is now just Query (the message name and MsgType value both) 🍓
guidance on XML encryption for confidentiality got way better, based on data markers, specifically the iodef:restriction attribute in the IODEF and IODEF-RID schemas 🔐. That attribute can also show up in IODEF extension schemas, and the same guidance applies there. More XML requirements and restrictions were added too.
all the normative text from the Security Considerations section moved into a brand new section, Security Requirements 🛡️
the RID schema order in Section 5 now matches the IODEF-RID schema 🧚
there's extra text explaining the content and the interactions between entities in the examples 💖
more references were added for interoperability, with stricter guidance on XML digital signatures and encryption 🔏

1.2. Normative and Informative 📚

okay the vibe here is: Sections 1, 2, 3, and 12 are the helpful background and considerations stuff 🌸. But RID systems in a consortium are REQUIRED to fully implement Sections 4, 5, 6, 7, 8, 9, 10, and 11 so nobody has interop drama 😭.

1.3. Terminology 🎀

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in [RFC2119] 💜. Read them like the rules they are, bestie.

2. Characteristics of Incidents 🔍

so an incident can be a benign configuration issue 🧸, an IT incident, an SLA infraction, a system compromise, a worm or Trojan infection, or a single- or multiple-source denial-of-service attack 💀. The goal of tracing a security incident might be to find the source, or to find a point on the network as close to the origin as possible 🦋. Incident tracing can be used to identify the source(s) of an attack so you can halt or mitigate the bad behavior, or fix an identified issue ✨. RID messages can move between entities to report or investigate ANY kind of incident, and they allow actions to be taken once the source (or a point closer to it) is known or identified 🫶. Mitigation can look like fixing a configuration issue, filtering or rate-limiting traffic close to the source, or taking the host or network offline 🔥. Also, you gotta make sure the systems involved in RID communications aren't abused 🚫, and that proper analysis happens at each SP involved in the investigation to figure out whether the attack traffic is, in fact, attack traffic 🧐.

Investigating security incidents is honestly a hard job 😩 because attackers go to great lengths to hide who they are 🥷. In a security incident, the true source might be found through an existing established connection to the attacker's point of origin. BUT the attacker might not connect to the compromised system for a long time after the initial compromise, or they might get in through a chain of compromised hosts spread across the network 🌐. Other ways to hide the source include hitting the host with the same attack from multiple sources, using both valid and spoofed source addresses 🎭. That tactic can compromise a machine and leave the admins with the tough job of finding the true origin 💔. Attackers use lots of techniques, which can vary between individuals or even organized groups 🕵️. Through analysis, those techniques can be grouped into indicators of compromise, which get shared via IODEF and RID to help improve detection capabilities 📈. Security incidents, including distributed denial-of-service (DDoS) attacks, can be super hard or nearly impossible to trace because of how the attack works 😵. Some of the difficulties in investigating attacks include the following:

the incident or attack comes from multiple sources 🌀
the incident may use social-engineering techniques or other methods to get into resources and intellectual property, using what looks like legit access methods, like outbound web sessions from user systems 🎣
the attack may include various types of traffic meant to eat up server resources, like a SYN flood attack without a big jump in bandwidth utilization 🌊
the traffic could include valid destination services that can't be blocked because they're essential to business, like DNS servers at an SP or HTTP requests sent to an organization connected to the Internet 🙈
the attack may use varying kinds of packets, including TCP, UDP, ICMP, or other IP protocols 📦
the attack may come from "zombies" or large botnets, which then need extra searching to find the controlling server as the true origin of the attack 🧟
the attack may use a very small number of packets from any particular source, which makes a trace after the fact nearly impossible 👻
the indicators of a compromise may be hard to detect 🫥

If the source(s) of an incident can't be figured out from IP address info, you might still be able to trace the traffic based on incident characteristics, like tracing the increased bandwidth utilization or the type of packets the client saw 🧩. With spoofed source addresses, though, finding the source of an attack is NOT a trivial task 💅.

IODEF, any IODEF extensions, and RID can be used to detail an incident 📝. That covers its characteristics (as they evolve), its history, and the communications about it, so the incident can be resolved and reported properly 🎀.

3. Communication between CSIRTs and Service Providers ✨

okay bestie, this part is all about how CSIRTs and SPs talk to each other fast when there's a security incident 🚨 Incidents can cross network access points between service providers, so the chat has to be lightning quick 💨 That urgency means there must be an effective system in place to make the interaction happen 💅 The communication policy or method should use multiple ways to talk so there's no single point of failure 🫶 Email is one option for sending incident info, packet traces, etc. 📧 But ngl, email may not get read in a timely fashion or be taken as seriously as a phone call or another channel like RID 😭

A technical solution for tracing traffic across one SP can use homegrown or commercial systems, and RID messaging must play nice with their input requirements 🎀 The incident-handling system on the SP's backbone, which the CSIRT uses to coordinate the trace across that single network, needs a way to accept, process, and relay RID messages to the system 💖 It also needs to wait for the system's responses so the RID request process can keep going as appropriate 🦋 In this setup, each service provider runs its own system that can talk RID and plugs into a management station for monitoring and analysis 🧚 Providers without enough resources could instead use a neutral third party that has access to the provider's network resources and can run the incident-handling functions for them 🌸 That could be a function of a central organization acting as a CSIRT for whole countries, or of a consortium that can offer centralized resources 👑

Consortiums can be a federation or a group of service providers or CSIRTs that agrees to use the RID communication protocol 🌈 They'd have an agreed-upon policy and communication protocol to keep IODEF-RID XML documents moving securely 🔐 Transport for RID messages is specified in [RFC6546] 📦

One big goal of RID is to avoid needing to let anyone into other networks' equipment 🙅‍♀️ RID gives everyone a standard messaging mechanism so they can share incident-handling info with other providers in a consortium or in neighboring networks 💜 The third party mentioned above can help with incident handling and possibly traceback through smaller providers 🦋 The RID messaging mechanism may be a logical or physical out-of-band network, so the communication stays secure and unaffected by the state of the network under attack 🛡️ The two management methods cover both needs: larger providers keep full management of their own network, and the third-party option is there for smaller providers who don't have the human resources to do incident-handling operations 🥹 With the first method, individual providers can involve their network operations staff (through a notification and alerting system) to authorize continuing a trace or any other necessary response to a RID communication request through their network 👀

The network used for communication should be made of out-of-band or protected channels (direct communication links), or encrypted channels dedicated to moving RID messages 🔒 These communication links would be direct connections, virtual or physical, between peers who have agreed on use and abuse policies through a consortium 🤝 Consortiums might link up through policy comparisons and extra agreements to form a bigger web or iterative network of peers 🕸️ That web would match the traffic paths available across the larger web of networks, or be organized by region and logical groups 🗺️ Contact info, IP addresses of RID systems, and other information must be coordinated between bilateral peers by a consortium, and may use existing databases like the routing arbiter 📚 The security, configuration, and Confidence rating schemes of RID messaging peers must be negotiated by the peers themselves, and must meet certain overall requirements of the fully connected network (Internet, government, education, etc.) through the peering and/or a consortium-based agreement 💅

RID messaging set up with clients of an provider may be negotiated in a contract as part of a value-added service, or through a service level agreement (SLA) 📝 Anything further is beyond the scope of this document and may be handled better in peering or service level agreements 🫶

Procedures for incident handling need to be established and well known by anyone who might be involved in incident response 📣 The procedures should also list contact info for internal escalation procedures, plus external assistance groups like a CSIRT, CERT Coordination Center (CERT/CC), Global Information Assurance Certification (GIAC), and the U.S. Federal Bureau of Investigations (FBI), or another assisting government organization in the country of the investigation 🕵️‍♀️✨

3.1. Inter-Service-Provider RID Messaging

RID gives you a protocol and format that keeps everything interoperable across vendors, so an incident messaging mechanism can be built without drama 🌸 The messages should meet several requirements to stay meaningful as they travel across multiple networks 🧵 RID provides the framework networks need to communicate during incident handling, possible traceback, and mitigation of a security incident 🦋 Several message types, described in Section 4.2, are needed to handle a security incident 💜 The message types are Report, Query, Request, Acknowledgement, and Result 🎀

A Report message is used when an incident is filed on a RID system or associated database, and no further action is required 📁

A Query message is used to request information about a particular incident 🔍 A Request message with options set to TraceRequest is used when the source of the traffic may have been spoofed 🕵️ In that case, each SP in the upstream path who receives this Request will issue a trace across its network to find the upstream source of the traffic 🛤️ The Acknowledgement and Result messages communicate the status and result of a Request 📬 A Request message with options set to InvestigationRequest may be sent to any party assisting in an incident investigation 🫶 The InvestigationRequest leverages bilateral relationships or a consortium's interconnections to mitigate or stop problematic traffic close to the source 🎯 Routes could determine the fastest path to a known source IP address for an InvestigationRequest 🏃‍♀️ A Request message (set to TraceRequest or InvestigationRequest) sent between RID systems to stop traffic at the source through a bordering network requires the information listed below 📋

Enough information to let the network administrators decide whether continuing the trace is important 🧐
The incident or IP packet information needed to carry out the trace or investigation 🔎
Contact information for the origin of the RID communication 📇 That contact info could come through the Autonomous System Number (ASN) [RFC1930] or Network Information Center (NIC) handle information listed in the Registry for Internet Numbers or other Internet databases 🌐
Network path information to help prevent routing loops from keeping a trace going forever 🔁 If a RID system receives a Request with MsgType set to TraceRequest that contains its own information in the path, the trace must cease, and the RID system should generate an alert to tell the network operations staff that a tracing loop exists 🚨
A unique identifier for a single attack 🆔 This identifier should be used to correlate traces to multiple sources in a DDoS attack 🧩

Use of the communication network and the RID protocol must be for pre-approved, authorized purposes only 🙅‍♀️ Each participating party is responsible for following the guidelines in both a global use policy, set up through the peering agreements for each bilateral peer, and agreed-upon consortium guidelines 📜 These policies exist to avoid abuse of the system, and the policies shall be developed by a consortium or the participating entities 🤓 The global policy may depend on the domain it operates under: for example, a government network and a commercial network such as the Internet would follow different guidelines to address their individual concerns 🏛️ Privacy issues must be considered in public networks such as the Internet 🔐 Privacy issues are discussed in the Security Requirements section, along with other requirements that participating entities must agree upon 💜

RID requests must be legitimate incidents and must not be used for things like sabotage or censorship 🚫 An example of this kind of abuse would be asking for legitimate traffic to be rate-limited so information can't be shared between users on the Internet (restricting access to online versions of papers), or blocking access to a competitor's product to sabotage their business 😤

The RID system should be configurable to either require user input or automatically continue traces ⚙️ That lets a network manager check the available resources before continuing a Request message set to InvestigationRequest or TraceRequest 🧠 If the Confidence rating (provided in IODEF) is low, it may not be in the provider's best interest to continue a Request with options set to InvestigationRequest or TraceRequest 📉 The Confidence ratings must follow the specifications for selecting the percentage used, so the system isn't abused 🛑 Requests must be issued by authorized individuals from the initiating CSIRT, as set out in policy guidelines established through peering or an SLA 👑

3.2. RID Communication Topology

okay so the simplest setup is a direct connection, aka a bilateral relationship, just two RID systems talking one-on-one 💖 it looks like this:

            ___________                                  __________
            |         |                                  |        |
            |  RID    |__________-------------___________|  RID   |
            |_________|          | SP Border |           |________|
                                 -------------

Figure 1: Direct Peer Topology

Within the consortium model, a few topologies might get agreed on and used 🦋 One option leans on the bilateral network peering relationships between consortium members. The RID peers would match the routing peers, and the logical network borders would be used. This approach may be necessary for an iterative trace where the source is unknown. It basically looks like the diagram above, but there may be a LOT of bilateral relationships hooked up together 😭 Also, inside a consortium, it may be useful to build an integrated mesh of networks to pass RID messages. This may be beneficial when the source address is known, since an interconnection may give a faster route to the closest upstream peer to the source of the attack traffic, if direct communication between SPs is not possible. Here's an example:

       _______                     _______                     _______
       |     |                     |     |                     |     |
     __| RID |____-------------____| RID |____-------------____| RID |__
       |_____|    | SP Border |    |_____|    | SP Border |    |_____|
          |       -------------               -------------       |
          |_______________________________________________________|

Direct connection to network that is not an immediate network peer

Figure 2: Mesh Peer Topology

ngl, fully meshing everything in a consortium means broadcasting RID requests is possible, but not advisable 🙈 If you broadcast a request, RID peers that may not have carried the attack traffic on their network would get asked to run a trace, in the hope of cutting down the time it takes to find the true source. The result? Lots of networks burning resources on a Request that may have been unnecessary in the first place. Not it 💅

A star topology may be desirable in cases where a peer is a provider of incident information. This requires trust relationships to be established between the provider of information and each of the consumers of that information. Examples may include country-level CSIRTs or service providers distributing incident information to organizations 🌸

4. Message Formats ✨

4.1. RID Data Types

RID is derived from the IODEF data model and inherits all of the data types defined in the IODEF model. RID only adds one data type of its own: BOOLEAN 🎀

4.1.1. Boolean

A boolean value is represented by the BOOLEAN data type.

The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in the schema. Note that there are two lexical representations for boolean in [XMLschema]: '1' or 'true' for TRUE, and '0' or 'false' or FALSE. 🧚

4.2. RID Message Types

The five RID message types described below MUST be implemented 👑 RID messages use both the IODEF [RFC5070] and RID document, and those MUST be encapsulated for transport as specified in [RFC6546]. The messages are generated and received on designated systems for RID communications. Each RID message type, along with an example, is described in the following sections. The IODEF-RID schema is introduced in Section 5 to support the described RID message types.

Request. This message type is used when a request ('InvestigationRequest' or 'TraceRequest') is needed. The purpose of the Request message (set to InvestigationRequest) is to leverage the existing peer relationships so that the SP closest to the source of the valid traffic gets notified of a security-related incident and can take any necessary actions. The Request (set to TraceRequest) is used when the traffic has to be traced iteratively through networks to find the source, by setting the MsgType to TraceRequest. The InvestigationRequest MsgType is used for all other Request messages.
Acknowledgement. This message is sent to the initiating RID system from each of the upstream provider's RID systems to provide information on the status of a Request. The Acknowledgement is also used to provide a reason why a Request, Report, or Query was not accepted.
Result. The Result message is used to provide a final report and the notification of actions taken for a Request. This message is sent to the initiating CSIRT through the network of RID systems in the path of the trace, as notification that the source of the attack was located. ✨
Report. This message is used to report a security incident for which no action is requested. This may be used for correlating attack information by CSIRTs, sharing incident information, statistics and trending information, etc. 📊
Query. This message is used to request information about an incident or incident type from a trusted system communicating via RID. The response is provided through the Report message. 🔍

When an application receives a RID message, it must be able to determine the type of message and parse it accordingly. The message type is specified in the RIDPolicy class. The RIDPolicy class may also be used by the transport protocol to facilitate the communication of security incident data to trace, investigate, query, or report information regarding security incidents.

5. IODEF-RID Schema

There are three classes included in the RID extension that are required to facilitate RID communications. The RequestStatus class indicates the approval status of a Request message. The IncidentSource class reports whether or not a source was found and identifies the source host(s) or network(s). The RIDPolicy class provides information on the agreed-upon policies and specifies the type of communication message being used. Three classes, one job each, very organized 🫶

The RID schema defines communication-specific metadata to support the exchange of incident information in an IODEF document. The intent behind keeping a separate schema, instead of using the AdditionalData extension of IODEF, is flexibility when sending messages between RID hosts. Since RID is a separate schema and RID messages include both the RID and IODEF documents, the RID message acts as an envelope: policy and security defined at the RID message layer are applied to both documents. Another reason for separate schemas is flexibility, since the RIDPolicy class can be easily extracted for use in the RID message and by the transport protocol.

The security requirements of sending incident information between entities include the use of encryption. The RIDPolicy information is not required to be encrypted, so separating that data from the IODEF XML document removes the need to decrypt and parse the IODEF document just to figure out how it should be handled at each RID host. Brilliant, honestly 🌈

The purpose of the RIDPolicy class is to specify the message type for the receiving host, facilitate the policy needs of RID, and provide routing information in the form of an IP address of the destination RID system.

The security requirements and policy guidelines are discussed in Section 9. The policy is defined between RID peers and within or between consortiums. RIDPolicy is meant to be a tool that facilitates the defined policies. This MUST be used in accordance with the policy set between clients, peers, consortiums, and/or regions. Security, privacy, and confidentiality MUST be considered as specified in this document. Main character rules, no skipping 🎀

The RID schema is defined as follows:

           +------------------+
           |        RID       |
           +------------------+
           |                  |
           | ENUM lang        |<>---{0..1}----[ RIDPolicy      ]
           |                  |
           |                  |<>---{0..1}----[ RequestStatus  ]
           |                  |
           |                  |<>---{0..1}----[ IncidentSource ]
           +------------------+

Figure 3: The RID Schema

The aggregate classes that make up the RID schema in the iodef-rid namespace are as follows:

RIDPolicy

Zero or One. The RIDPolicy class is used by all message types to facilitate policy agreements between peers, consortiums, or federations, as well as to properly route messages. 🦋

RequestStatus

Zero or One. The RequestStatus class is used only in Acknowledgement messages. The message reports back to the CSIRT or SP in the Acknowledgement message to provide status on a Request, or if an error or problem occurs with the receipt or processing of a Report, Query, or Result message.

IncidentSource

Zero or One. The IncidentSource class is used in the Result message only. The IncidentSource provides the information on the identified source host or network of an attack trace or investigation. 🔥

Each of the three listed classes may be the only class included in the RID class, hence the option for zero or one. In some cases, RIDPolicy MAY be the only class in the RID definition when used by the transport protocol [RFC6546], since that information should be as small as possible and may not be encrypted. The RequestStatus message MUST be able to stand alone without the need for an IODEF document to facilitate the communication, limiting the data transported to the required elements per [RFC6546]. Okay, that one's a big deal 😤

The RID class has one attribute:

lang

One. REQUIRED. ENUM. A valid language code per [RFC5646], constrained by the definition of "xs:language" inherited from [XML1.0]. 🌍

5.1. RIDPolicy Class

The RIDPolicy class facilitates the delivery of RID messages and is also referenced for transport in the transport document [RFC6546]. The RIDPolicy class includes the ability to embed an IODEF document, or XML documents that conform to schemas other than IODEF, in the ReportSchema element. 🧚

          +------------------------+
          | RIDPolicy              |
          +------------------------+
          |                        |
          | ENUM restriction       |<>-------------[ Node         ]
          | ENUM MsgType           |
          | ENUM MsgDestination    |<>---{0..1}----[ IncidentID   ]
          | ENUM ext-MsgType       |
          | ENUM ext-MsgDestination|<>---{1..*}----[ PolicyRegion ]
          |                        |
          |                        |<>---{1..*}----[ TrafficType  ]
          |                        |
          |                        |<>---{0..1}----[ ReportSchema ]
          +------------------------+

Figure 4: The RIDPolicy Class

The aggregate elements that make up the RIDPolicy class are as follows:

Node

One. The Node class is used to identify a host or network device, in this case to identify the system communicating RID messages, and the usage is determined by the MsgDestination attribute. The base definition of this class is reused from the IODEF specification [RFC5070], Section 3.16. See Section 11 of this document for Internationalization considerations. 🌸

IncidentID

Zero or one. 💖 This is a global reference that points back to the IncidentID from the IODEF data model ✨. The IncidentID includes the name of the CSIRT, an incident number, and an instance of that incident. The instance number gets a dash in front of it, and it's useful when you want to group incidents together 🧚. Stuff that might get grouped includes botnets, polymorphic attacks, DDoS attacks, multiple hops of compromised systems found during an investigation, etc. 💀

PolicyRegion

One or many. REQUIRED. 🎀 This is how you figure out which policy area might need a look before a trace gets approved 👀. You can pick several values from the attribute list so every policy consideration is covered when info crosses regions, consortiums, or networks 🌈.

region

One or many. REQUIRED. ENUM. 🦋 The attribute region tells you how far the incident info is allowed to travel. It can stay within a region, or follow existing relationships like a consortium or a client-to-service-provider link 💅.

ClientToSP. A client started the request to their service provider (SP) 🙌. A client can be an individual, an enterprise, or another kind of entity like a government, a business, or a school. An SP can be a network, telecom, infrastructure, or other kind of provider where a client-to-vendor relationship exists. That relationship usually comes with contracts or agreements that set expectations and trust.
SPToClient. An SP started an RID request or report aimed at a client 📨. Clients and SPs can be the same kinds of entities as above. The client-to-vendor relationship usually has contracts or agreements that spell out expectations and trust.
IntraConsortium. Incident info with no restrictions inside a consortium, as long as the agreed use and abuse guidelines are followed 🫶. A consortium is a well-defined group with established members and trust that's specific to sharing within that group. It usually decides ahead of time what kinds of data can be shared, what's expected for protecting that data, and has contractual agreements in place. Examples include industry-focused sharing communities (financial, government, research and education, etc.) or cross-industry sharing communities (for instance, organizations in the same local area that form a sharing group) ✨.
PeerToPeer. Incident info with no restrictions between two peers 🤝. It may still need further evaluation before going any further than that, and the agreed use and abuse guidelines still apply. PeerToPeer communication can involve any two individuals or entities that decide to share directly with each other 🍓.
BetweenConsortiums. Incident info with no restrictions between consortiums that have agreed use and abuse guidelines 🌸. This one is used when two consortiums (as defined in IntraConsortium above) share data. The types of data they can share should be listed in their agreements and contracts, along with expectations for how that data gets handled and protected.
ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.

TrafficType

One or many. REQUIRED. 🔥 The attribute type helps decide whether a trace is a good fit for the SP that received the request, so it knows if it should keep the trace going. You can pick multiple values here, but where possible, narrow it down to the one that most accurately describes the traffic type 🎯.

type

One or many. REQUIRED. ENUM. 💜 The attribute type tells you what kind of info is in the RID message or what kind of incident it is.

Attack. Only pick this one if the traffic is related to an information security incident or attack 🛡️. This option SHOULD only be selected in that case. The type of attack MUST also be spelled out in more detail in the IODEF Method and Impact classes, so people can figure out whether the trace can continue ([RFC5070], Sections 3.9 and 3.10.1) 💅.
Network. This option MUST only be selected when the trace is about network traffic or routing issues 🌐.
Content. This category MUST be used only when the request is about content and there are regional restrictions on accessing that content 📰. It's not malicious traffic. It's used to find out which sources or destinations accessed certain materials on the Internet, including, but not limited to, news, technology, or inappropriate content 👀.
DataWithHandlingRequirements. Use this when shared data might come with extra rules for handling, protection, and processing based on the type of data and where it lives 🔐. Regulatory or legal restrictions can be placed on certain types of data, and they can vary depending on the location, region or nation, or where the data came from. The IODEF document, along with any extensions, that's included with the RID message should point out the specific restrictions to think about. Using this flag is not legally binding 🙃.
AudienceRestriction. This tells everyone the message has data meant for a restricted audience 🤫. It should not be used for normal incidents or reporting, because it could slow down response times. The content might be a business-relevant notification or request. This option MAY be used by a business partner to report or ask for help if an incident has affected a supply chain 🚚. It can also be used if the content is relevant to regulatory obligations, legal matters (eDiscovery), or other use cases that need management attention 🧾.
Other. If you select this one, you MUST include a description of the traffic type so policy decisions can be made about whether to continue or stop the investigation 📝. That info should go in the IODEF message, either in the Expectation class or in the History class using a HistoryItem log. This can also be used for incident types that aren't information-security-related 🧚.
ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.

ReportSchema

Zero or One. 📚 The ReportSchema class is for message types that need the full IODEF schema included in the RID envelope. Alternate schemas may be included if the Designated Reviewer approves them and IANA registers them for use with RID 🦄.

The RIDPolicy class has five attributes:

restriction

OPTIONAL. ENUM. 🎀 This attribute says which disclosure guidelines the sender expects the recipient to follow. Real talk, it doesn't give you any real security, because the recipient gets to decide whether to honor it 🙈. It follows the same guidelines as "restriction" in IODEF.

MsgType

One. REQUIRED. ENUM. 📬 This is the type of RID message being sent. The five types are described in Section 4.2, and they can be written as one of the six selections below, where a Request is set to either 'InvestigationRequest' or 'TraceRequest' 🌸.

TraceRequest. This Request can start a TraceRequest, or keep one going to an upstream network that's closer to the source address where the security incident began 🕵️‍♀️.
Acknowledgement. Each upstream RID system sends this back to the initiating RID system to share the status of the request in its own network 👍.
Result. This message says the source of the attack was found. It gets sent back to the initiating RID system through the RID systems along the trace path 🏁.
InvestigationRequest. This Request type is for when the traffic source is believed to be valid 💁‍♀️. It uses existing peer or consortium relationships to let the SP closest to the valid traffic's source know that some event happened, which might be security-related.
Report. This reports a security incident where no action is requested in the IODEF Expectation class 📊. It can be used to correlate attack info across CSIRTs, gather statistics, track trends, etc.
Query. This asks a trusted RID system for info about an incident or incident type 🔍.

There's also an extension attribute for adding new enumerated values:

ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1. 🧩

MsgDestination

One. REQUIRED. ENUM. 📍 The destination at this level is either the RID messaging system that's supposed to receive the request, or, when a Request has MsgType set to 'InvestigationRequest', the source of the incident. With an InvestigationRequest, the RID system that can help stop or mitigate the traffic might not be known, so the message may have to travel through RID messaging systems by following the routing path to the one closest to the source of the attack traffic 🛤️. The Node element lists either the RID system or the IP address of the source, and MsgDestination decides what the value in the Node element means 💜.

RIDSystem. The IP address of the next upstream system that accepts RID communications is REQUIRED, and it's listed in the Node element of the RIDPolicy class 🌐. If the NodeName element of the Node class is used, it holds a DNS domain name. The originating RID system is required to check that this domain name resolves to the IP address the RID message is sent to 🔎. That check can happen before the message is sent, and the result can be saved and reused for later RID messages 🫶.
SourceOfIncident. The Address element of the Node element contains the IP address of the incident source, and the NodeName element of the Node class is not used. The IP address is REQUIRED when this option is selected. The IP address is used to determine the path of systems accepting RID communications that will be used to find the closest RID system to the source of an attack in which the IP address used by the source is believed to be valid and a Request message with MsgDestination set to 'InvestigationRequest' is used. This is not to be confused with the IncidentSource class, as the defined value here is from an initial Request ('InvestigationRequest' or 'TraceRequest'), not the source used in a Result message. 🧭
ext-value. An escape value used to extend this attribute. All extensions shall specify the contents and meaning of the Node element of RIDPolicy. See IODEF [RFC5070], Section 5.1, on extensibility. If the NodeName element of the Node class is used by an extension, NodeName may contain an Internationalized Domain Name (IDN); see Section 11 for applicable requirements. All extensions SHOULD use an IP address in the Address element of the Node class as the primary means of Node identification. 🌸

MsgType-ext

OPTIONAL. STRING. A means by which to extend the MsgType attribute. See IODEF [RFC5070], Section 5.1. 🎀

MsgDestination-ext

OPTIONAL. STRING. A means by which to extend the MsgDestination attribute. See IODEF [RFC5070], Section 5.1 🦋

5.1.1. ReportSchema ✨

okay so the ReportSchema class is an aggregate class in the RIDPolicy class, and the IODEF schema is the approved schema for inclusion in RID messages via the ReportSchema class. bestie, look at this diagram 👀

          +-------------------------+
          |      ReportSchema       |
          +-------------------------+
          |                         |
          |  ENUM Version           |
          |  STRING ext-Version     |<>---{1}-------[ XMLDocument   ]
          |  ENUM XMLSchemaID       |
          |  STRING ext-XMLSchemaID |<>---{0..1}----[ URL           ]
          |                         |
          |                         |<>---{0..*}----[ Signature     ]
          |                         |
          +-------------------------+

                     Figure 5: The ReportSchema Class

the elements that make up the ReportSchema class go like this 💖

XMLDocument

One. The XMLDocument is a complete XML document defined by the iodef:ExtensionType class. This class follows the guidelines in [RFC5070], Section 5, where the data type is set to 'xml' and meaning is set to 'xml' to include an XML document. 💅

URL

Zero or One. URL. A reference to the XML schema of the XML document included. The URL data type is defined in [RFC5070], Section 2.15, as "xs:anyURI" in the schema. The schemaLocation for IODEF is already included in the RID schema, so this is not necessary to include a URL for IODEF documents. The list of registered schemas for inclusion will be maintained by IANA. 🧚

Signature

Zero to many. The Signature uses the iodef:ExtensionType class to enable this element to contain a detached or enveloped signature. This class follows the guidelines in [RFC5070] Section 5 where the data type is set to 'xml' and meaning is set to 'xml' to include an XML document. This element is used to encapsulate the detached signature based on the iodef:RecordItem class within the IODEF document to verify the originator of the message or to include the enveloped signature. If other schemas are used instead of IODEF, they MUST provide guidance on what class to use if a detached signature is provided for this purpose. 🔐

The ReportSchema class has four attributes 🍓

Version

OPTIONAL. One. The Version attribute is the version number of the specified XML schema. That schema must be an approved version of IODEF or a schema registered with IANA for use with RID. The IANA registry for managing schemas other than IODEF is specified in Section 12.

ext-value: an escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.

ext-Version

OPTIONAL. One. The ext-Version attribute is the version number of the included XML schema. This attribute is used if a schema other than IODEF or an IANA-registered schema that has been added to the enumerated list for Version is included. 🌈

XMLSchemaID

OPTIONAL. One. The XMLSchemaID attribute is the identifier, the defined namespace [XMLNames], of the XML schema of the XML document included. The XMLSchemaID and Version specify the format of the XMLDocument element. The only permitted values include the namespace for IODEF [RFC5070], "urn:ietf:params:xml:ns:iodef-1.0", any future IETF-approved versions of IODEF, and any namespace included in the IANA-managed list of registered schemas for use with RID. The IANA registry for managing schemas other than IODEF is specified in Section 12.

ext-value: an escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.

ext-XMLSchemaID

OPTIONAL. One. The ext-XMLSchemaID attribute is the identifier (defined namespace) of the XML schema of the XML document included. The ext-XMLSchemaID and ext-Version specify the format of the XMLDocument element and are used if the included schema is not IODEF version 1.0 or an IANA-registered schema that has been added to the enumerated list for XMLSchemaID. ⭐

5.2. RequestStatus 👑

The RequestStatus class is an aggregate class in the RID class. 🫶

                       +--------------------------------+
                       | RequestStatus                  |
                       +--------------------------------+
                       |                                |
                       | ENUM restriction               |
                       | ENUM AuthorizationStatus       |
                       | ENUM Justification             |
                       | STRING ext-AuthorizationStatus |
                       | STRING ext-Justification       |
                       |                                |
                       +--------------------------------+

                     Figure 6: The RequestStatus Class

the RequestStatus class has five attributes, and they are giving main character energy 🎬

restriction

OPTIONAL. ENUM. This attribute indicates the disclosure guidelines to which the sender expects the recipient to adhere. This guideline provides no real security since it is the choice of the recipient of the document to honor it. This attribute follows the same guidelines as "restriction" used in IODEF. 🙈

AuthorizationStatus

One. REQUIRED. ENUM. The listed values are used to provide a response to the requesting CSIRT of the status of a Request, Report, or Query. 💀

Approved. The trace was approved and will begin in the current SP. ✅
Denied. The trace was denied in the current SP. The next closest SP can use this message to filter traffic from the upstream SP using the example packet to help mitigate the effects of the attack as close to the source as possible. The Acknowledgement message must be passed back to the originator and a Result message must be used from the closest SP to the source in order to indicate actions taken in the IODEF History class. 🚫
Pending. Awaiting approval; a timeout period has been reached, which resulted in this Pending status and Acknowledgement message being generated. ⏳
ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1. 🌟

Justification

OPTIONAL. ENUM. Provides a reason for a Denied or Pending message. 🧐

SystemResource. A resource issue exists on the systems that would be involved in the request. 🖥️
Authentication. The enveloped digital signature [RFC3275] failed to validate. 🔏
AuthenticationOrigin. The detached digital signature for the original requestor on the RecordItem entry failed to validate. 📝
Encryption. The recipient was unable to decrypt the request, report, or query. 🔓
UnrecognizedFormat. The format of the provided document was unrecognized. 🤷‍♀️
CannotProcess. The document could not be processed. Reasons may include legal or policy decisions. Resolution may require communication outside of this protocol to resolve legal or policy issues. No further messages SHOULD be sent until resolved. 🛑
Other. There were other reasons this request could not be processed. 🌀
ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1. 🎀

AuthorizationStatus-ext

OPTIONAL. STRING. A means by which to extend the AuthorizationStatus attribute. See IODEF [RFC5070], Section 5.1. 💜

Justification-ext

OPTIONAL. STRING. A means by which to extend the Justification attribute. See IODEF [RFC5070], Section 5.1. 🦋

5.3. IncidentSource 🕵️‍♀️

okay so the IncidentSource class is an aggregate class living inside the RID class, and it's the bit that tells you who the bad actor was 👀 Here's the vibe:

          +-------------------+
          | IncidentSource    |
          +-------------------+
          |                   |
          | ENUM restriction  |
          |                   |<>-------------[ SourceFound    ]
          |                   |
          |                   |<>---{0..*}----[ Node           ]
          |                   |
          +-------------------+

                    Figure 7: The IncidentSource Class

Figure 7 is basically the whole family tree of the class 🌳 Okay, now the elements that make it up:

SourceFound 🔍 One, and it's a BOOLEAN. This one is the yes-or-no check for whether the source got identified. If it did, the source is listed in the Node element of this class.

True. Source of incident was identified. ✅
False. Source of incident was not identified. 🙅‍♀️

Node 🖥️ Zero or many. The Node class is for flagging a system that got caught up in the incident. If you use this element, the Address element of the Node element MUST contain the IP address of the system. Lowkey the most important rule here. If the NodeName element of the Node class is used, it holds a DNS domain name that was checked to make sure it resolved to that IP address at the time of the check 🫶 For internationalization stuff about NodeName, go to Section 11 of this document. The base definition of this class from the IODEF ([RFC5070], Section 3.16) can be expanded to include other identifiers, so it's extendable, bestie 🧚

The IncidentSource class has one attribute, and it's a big one:

restriction 🔒 OPTIONAL. ENUM. This attribute tells the recipient what disclosure guidelines the sender expects them to follow. ngl, this guideline gives you no real security, because it's totally up to the recipient whether they honor it 💀 This attribute follows the same guidelines as "restriction" used in IODEF.

5.4. RID Name Spaces 🎀

The RID schema declares the namespace urn:ietf:params:xml:ns:iodef-rid-2.0 and registers it per [RFC3688]. Every IODEF-RID document MUST use the iodef-rid-2.0 namespace in the top-level element RID-Document. Here's how you reference it:

<RID-Document version="2.0" lang="en-US"
   xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
   xmlns:xsi="http://www.w3c.org/2001/XMLSchema-instance"
   xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-rid-2.0.xsd">

5.5. Encoding 💌

RID documents MUST begin with an XML declaration, and MUST specify the XML version they use. Also, UTF-8 encoding is REQUIRED ([RFC3470], Section 4.4) 🌸 RID follows all XML data encoding conventions and constraints, so no surprises there.

The XML declaration with no character encoding will read like this:

<?xml version="1.0" encoding="UTF-8"?>

Some characters have special meaning in XML, so they MUST be escaped with their entity reference equivalent. Those are "&", "<", ">", "\"" (double quotation mark), and "'" (apostrophe). Their entity references are &, <, >, ", and ', in that order 💅

5.6. Including IODEF or Other XML Documents 🧩

Okay, CSIRTs' needs keep changing, so the RID schema can include an IODEF or other data model. IODEF is extensible too, so the schemas can evolve right alongside what CSIRTs need 🦋 This section covers how to include an IODEF XML document or other XML documents, so you get to use the security and trust relationships that RID already set up. The best part is that adding new data won't require a change to the RID schema. This also makes it possible to exchange private XML documents that only matter to a closed consortium 🤫

XML documents can be included through the ReportSchema class in the RIDPolicy class. The XMLDocument attribute is set to 'xml' so you can include full IODEF or other XML documents. The following guidelines MUST be followed:

The included schema MUST define a separate namespace, such as the declared namespace for IODEF of urn:ietf:params:xml:ns:iodef-1.0.
When a parser runs into an included XML document it doesn't understand, that included document MUST be ignored (and not processed), but the remainder of the document MUST be processed. Parsers can spot the XML documents they have no processing logic for through the namespace declaration 👀 Parsers that hit an unrecognized element in a namespace they do support SHOULD reject the document as a syntax error.
Implementations SHOULD NOT download schemas at runtime, due to the security implications 🚫 And included documents MUST NOT be required to provide a resolvable location for their schema.

The examples in Section 7 show how an IODEF document gets included. The included IODEF schema is represented in ReportSchema like this:

Version: "1.0"

XMLSchemaID: "urn:ietf:params:xml:ns:iodef-1.0"

URL: "http://www.iana.org/assignments/xml-registry/schema/
iodef-1.0.xsd"

The URL is optionally included for IODEF, since it's already in the RID schema and the schemaLocation is defined ✨

5.6.1. Including XML Documents in RID 📚

XML schemas can be registered for inclusion in a RID message. That can cover schemas other than IODEF, or updated versions of IODEF. The registered IANA information for additional schemas MUST include the specification name, version, specification Uniform Resource Identifier (URI), and namespace. Here's an example of the info you need for additional schemas beyond IODEF:

Example Name (XXXX)

   Schema Name:   XXXX_1.1
   Version:       1.1
   Namespace:     <registered namespace>
   Specification URI:  http://www.example.com/XXXX

The version attribute of the ReportSchema class gets populated with the approved versions of IODEF, or any additional schemas IANA has registered. See Section 12 for those 🌈

The XMLSchemaID of the ReportSchema class gets populated with the namespace of the included schema. The attribute enumeration values include the namespace for IODEF and any schema IANA has registered; see Section 12 again, because it's important 💜

The URL element of the ReportSchema class gets populated with the Specification URI value of the included schema.

6. RID Messages 💬

The IODEF model is followed as specified in [RFC5070] for each of the RID message types. The RID schema works together with IODEF documents to make RID communications happen 🫶 Each message type varies a little in format and purpose, so the requirements vary too, and they're specified for each type. All classes, elements, attributes, and so on that are defined in the IODEF-Document are valid in the context of a RID message. Some things that are optional in IODEF are mandatory for RID, though, and those are listed for each message type 🍓 The IODEF model MUST be fully implemented for RID messages that include IODEF payloads, so they parse properly.

Note: RID implementations may automate filling in the content each message type needs, using packet input, incident data, situational awareness information, or default values like the ones used in the EventData class. Lowkey a huge time-saver 🧚

6.1. Request 💅

Okay bestie, this is the message you send when you need backup on a computer security investigation 🔥. It can go to another party who can do forensics and keep the investigation going. The incident might have started on the SP network the Request was sent to, so they're the ones to pick it up 🫶. It can also go to an SP so they can trace traffic back to an unknown source 🕵️‍♀️. A Request with MsgType set to InvestigationRequest uses your existing bilateral peer relationships to tell the SP closest to the source of the valid traffic that something happened, which might be a security-related incident 🚨. A Request with MsgType set to TraceRequest goes upstream to a peer so it can trace back through the network and locate the source of the malicious traffic 🙈. Here's what's REQUIRED for Request messages, and how each piece gets delivered:

RID Information:
- RIDPolicy
  - RID message type, IncidentID, and destination policy information
IODEF Information:
- Timestamps (DetectTime, StartTime, EndTime, ReportTime).
- Incident Identifier (Incident class, IncidentID).
- Confidence rating of security incident (Impact and Confidence class).
- System class is used to list both the Source and Destination.
- Expectation class should be used to request any specific actions to be taken close to the source.
- Path information of nested RID systems, beginning with the request originator used in the trace using IODEF EventData with category set to infrastructure.
- Event, Record, and RecordItem classes to include example packets and other information related to the incident. Note: Event information included here requires a second instance of EventData in addition to that used to convey SP path contact information.
Standards for encryption and digital signatures [RFC3275] [XMLsig] [XMLencrypt]:
- Digital signature from initiating CSIRT or provider system sending the RID message, passed to all systems receiving the Request using a detached XML digital signature on a RecordItem entry, placed in an instance of the Signature element.
- Digital signature of sending CSIRT or SP for authenticity of the RID message, from the CSIRT or provider creating this message using an enveloped XML digital signature on the IODEF document, placed in an instance of the Signature element.
- XML encryption as required by policy, agreements, and data markers.

Security requirements include the ability to encrypt [XMLencrypt] the contents of the Request message using the public key of the destination RID system. The incident number increases whether the Request message has the MsgDestination set to InvestigationRequest or TraceRequest, so every one stays unique within the system ✨. The relaying peers also append their Autonomous System (AS) or RID system information to the path information as the Request gets relayed through SPs. This lets the response (Result message) use the same path and trust relationships on the way back, indicating any actions taken 🦋. The request gets recorded in the state tables of both the initiating and destination SP RID systems. The destination SP is responsible for any actions taken because of the request, following any service level agreements or policies. The SP MUST confirm that the traffic actually originated from the suspected system before taking any action, and it MUST confirm the reason for the request 💖. The request may be sent directly to a known RID system, or it may be routed by the source address of the attack using the MsgDestination of RIDPolicy set to SourceOfIncident. Note: Any intermediate parties in a TraceRequest MUST be able to view RIDPolicy information of responding message types in order to properly direct RID messages 👑.

A DDoS attack can have a ton of sources, which means multiple traces to find them all. It may be valid to continue multiple traces for a single attack 🌈. The path information lets administrators figure out whether the exact trace already passed through a single network. The Incident Identifier must also be used to identify multiple Requests from a single incident. If a single Request results in divergent paths of Requests, a separate instance number MUST be used under the same IncidentID 🧚. The IncidentID instance number of IODEF can be used to correlate related incident data that is part of a larger incident.

6.2. Acknowledgement 🫶

Description: The Acknowledgement is also how you give a status for any message type. It's also where you put a Justification if the message couldn't be processed for any reason 💅. It gets sent to the initiating RID system from the next upstream provider's application or system that's set up to accept RID communications, and it tells you the status of the request in the current SP ✨.

The following information is REQUIRED for Acknowledgement messages, and it comes through these structures:

RID Information:
- RIDPolicy
  - RID message type, IncidentID, and destination policy information
- RequestStatus class:
  - Status of Request
Standards for encryption and digital signatures [RFC3275], [XMLsig], [XMLencrypt]:
- Digital signature of responding CSIRT or provider for authenticity of Trace Status Message, from the CSIRT or provider creating this message using an enveloped XML digital signature.
- XML encryption as required by policy, agreements, and data markers.

A message goes back to the initiating CSIRT or provider's system, which accepts RID communications of the trace as a status notification 💜. This message verifies that the next RID system in the path has received the message from the previous system in the path. It also verifies that the trace is continuing, has stopped, or is pending in the next upstream CSIRT or provider's RID system 🌸. The Pending status is generated automatically after a 2-minute timeout without a system-predefined or administrator action to approve or disapprove the trace continuance ⏳. If a Request is denied, the originator and sending peer (if they are not the same) MUST both receive the message 🚫. This gives the sending peer the option to stop or mitigate the traffic as close to the source as possible 🎀.

6.3. Result 👑

Description: This message says the trace or investigation is finished and gives you the result 🎉. The Result message says whether or not a source was found, and the source info comes through the IncidentSource class. The Result information MUST go back to the originating RID system that started the investigation or trace. A provider can use any number of incident-handling data sources to figure out the true source of an attack, though not all of those sources are necessarily tied into the RID communications system 🔍.

The following information is REQUIRED for Result messages, and it will be provided through these structures:

RID Information:
- RIDPolicy
  - RID message type, IncidentID, and destination policy information
- Incident Source
  - The IncidentSource class of the RID schema is used to note if a source was identified and to provide the source address(es) or other Node information.
IODEF Information:
- Timestamps (DetectTime, StartTime, EndTime, ReportTime).
- Incident Identifier (Incident class, IncidentID).
  - Trace number is used for multiple traces of a single incident. It MUST be included if the response is specific to an instance of an incident.
- Confidence rating of security incident (Impact and Confidence class).
- System class is used to list both the Source and Destination Information used in the attack, and it must note if the traffic is spoofed, which means an upstream Request set to TraceRequest is required in RID.
- History class "atype" attribute is used to note any actions taken.
- History class also notes any other background information, including notes about the Confidence level or rating of the result information.
- Path information of nested RID systems, beginning with the request originator used in the trace using IODEF EventData with category set to infrastructure. The last SP listed is the SP that located the source of the traffic (the provider sending the Result message).
- Event, Record, and RecordItem classes to include example packets and other information related to the incident (optional). Note: Event information included here requires a second instance of EventData in addition to that used to convey SP path contact information.
Standards for encryption and digital signatures [RFC3275], [XMLsig], [XMLencrypt]:
- Digital signature of source CSIRT or provider for authenticity of Result message, from the CSIRT or provider creating this message using an enveloped XML digital signature.
- XML encryption as required by policy, agreements, and data markers.

A message goes back to the initiating CSIRT or provider's RID system to let the CSIRT know the source has been located 🥳. The actual source information may or may not be included, depending on the policy of the network where the client or host is attached. Any action the SP takes after finding the source of a trace should be included 💖. The SP may be able to automate adjusting filters on their border router to block outbound access for the machine(s) discovered as part of the attack 🛡️. The filters may be comprehensive and block all Internet access until the host has taken the appropriate action to resolve any security issues. The SP may be limited in its filtering options because of agreements or other restrictions, which can lead to less comprehensive filters, such as rate-limiting the ingress traffic as close to the source as possible 🌈.

Security and privacy requirements discussed in Section 9 MUST be taken into account 🔐.

Note: The History class has been expanded in IODEF to cover all the possible actions taken as a result of a RID Request, using the iodef:atype (action type) attribute ✨. The History class should be used to note all actions taken close to the source of a trace or incident, using the most appropriate option for the type of action along with a description. The atype attribute in the Expectation class can also be used to request an appropriate action when a Request is made 🦋.

6.4. Report 🎀

Okay so Report is the message you send to a RID system to spill the tea on a security incident 🫶 It doesn't ask anyone to do anything. The receiver just files it on their RID system or associated database 📁 Literally just filing, no cap.

The following must-haves are REQUIRED for Report messages, and here's how they're packed:

RID Information:
- RIDPolicy RID message type, IncidentID, and destination policy information

Next, these are RECOMMENDED if you have them 🌸 Here's how they get packed:

IODEF Information:
- Timestamps (DetectTime, StartTime, EndTime, ReportTime).
- Incident Identifier (Incident class, IncidentID).
  - The trace number is used for multiple traces of a single incident. It MUST be included if the Report is specific to an instance of an incident. 🚨
- Confidence rating of the security incident (Impact and Confidence class).
- System class, which lists both the Source and Destination Information used in the attack.
- Event, Record, and RecordItem classes, which can include example packets and other info about the incident (optional) 🍓
Standards for encryption and digital signatures [RFC3275], [XMLsig], [XMLencrypt]:
- A digital signature from the initiating RID system, passed to all systems receiving the report using an enveloped XML digital signature, placed in an instance of the Signature element ✨
- XML encryption as required by policy, agreements, and data markers 🔐

Security is a big deal here 💜 Encrypting the Report contents with [XMLencrypt] using the public key of the destination RID system is something you should be able to do. Senders should also know the info may be used to correlate incident data for trending, pattern detection, and similar stuff, and it may be shared with other parties unless the receiving RID system has agreed otherwise. So sending parties may obfuscate or remove destination addresses or other sensitive info before sending a Report. A Report can be sent either to file an incident report or to respond to a Query, and data sensitivity matters in both cases 🛡️ The SP path information isn't needed for this message, since it gets communicated directly between two trusted RID systems 🦋

6.5. Query 🦋

The Query message is how you ask a trusted RID system for incident info 🔍 You can include the incident number if you know it, or describe the incident in detail. If you know the incident number, the Report with the incident info can easily come back to the trusted requestor through automated methods 🤖 If you include an example packet or other unique info, the return report may be automated too. Otherwise, an analyst might need to step in 🧑‍💻

The following is REQUIRED for a Query message and is provided through these data structures:

RID Information:
- RIDPolicy
  - RID message type, IncidentID, and destination policy information
IODEF Information (optional):
- Timestamps (DetectTime, StartTime, EndTime, ReportTime).
- Incident Identifier (Incident class, IncidentID).
  - The trace number is used for multiple traces of a single incident. It MUST be included if the Query is an instance of an incident. 🚨
- Confidence rating of the security incident (Impact and Confidence class).
- System class, which lists both the Source and Destination Information used in the attack.
- Event, Record, and RecordItem classes, which can include example packets and other info about the incident (optional) 🍓
Standards for encryption and digital signatures [RFC3275], [XMLsig], [XMLencrypt]:
- A digital signature from the CSIRT or SP starting the RID message, passed to all systems receiving the Query using an enveloped XML digital signature, placed in an instance of the Signature element ✨
- XML encryption as required by policy, agreements, and data markers 🔐

The proper response to a Query is a Report 💌 You can get back multiple incidents from one query if you request an incident type. In that case, the receiver sends an IODEF document with multiple incidents or all instances of an incident. The system sending the reply can set a limit on how many documents it returns in one report, and the recommended limit is 5 so the documents don't get too chunky 🍰 For big transfers, other methods may suit you better than RID. You can also use the Confidence rating in a Query to only pick incidents with an equal or higher rating than the one you name. That's handy when you've gathered info on a type of incident but not the specifics of one incident 💅 Source and Destination Information might not be needed if the Query is only collecting data about a specific type of incident.

7. RID Communication Exchanges 🧚

This section lays out how RID conversations flow and gives examples of messages 💖

The possible message exchanges include:

Request: An asynchronous request for help and/or action to be taken. It MAY involve multiple systems and iterative Requests 🔁
- MsgType set to 'InvestigationRequest' or 'TraceRequest'
- Possible responses:
  - Acknowledgement (OPTIONAL for InvestigationRequest)
  - Result (REQUIRED unless Acknowledgement was set to 'no')
  - Report (OPTIONAL; zero or more; a Report can be sent unsolicited) 📨
Query: A synchronous request for info 🔍
- MsgType set to 'Query'
- Possible responses:
  - Acknowledgement (OPTIONAL if yes; REQUIRED if no Report will be sent)
  - Report (REQUIRED unless Acknowledgement was set to 'no')
Report: An asynchronous info report. It may be pushed to systems or sent as a response to a Query 📬
- MsgType set to 'Report'
- Possible responses:
  - Acknowledgement (OPTIONAL)

Processing the IODEF document and any IODEF-included elements or attributes MUST follow the guidelines in [RFC5070], Section 4 🧐 [RFC3023] and [RFC3470] lay out requirements and best practices for using XML in IETF application protocols 📚 RID and IODEF documents MUST be well-formed (see [RFC3470], Section 4.1) and MUST be validated against the right schema ✅ Internal or external DTD subsets are prohibited in RID. See [RFC3023], Section 3 🚫

Conformant processors can ignore comments in RID or IODEF documents (see [RFC3470], Section 4.6). The examples below include comments for info only 💬 The first example shows a detached digital signature. The later examples leave out the detached signature that some message types need. The signature gets applied after the message is created, as shown in the first example ✍️

Note: For each example below, [RFC5735] addresses were used. Pretend each IP address is actually a separate network range held by a different SP. The addresses come from /27 network ranges 🌈

7.1. Upstream Trace Communication Flow ✨

okay so this diagram is giving TraceRequest communication flow 🕵️‍♀️ It shows how a RID Request for a TraceRequest moves between RID systems on different networks while they trace an attack. The Request with MsgDestination set to 'TraceRequest' shows up in the diagram as "TraceRequest". SP-1, SP-2, and SP-3 are the service providers in this example trace flow 🦋

Attack Dest      SP-1            SP-2        SP-3        Attack Src

1. Attack    |  Attack
   reported  |  detected

2.              Initiate trace

3.              Locate origin
                through
                upstream SP

4.              o---TraceRequest----->

5.                              Trace
                                Initiated

6.              <---Acknowledgement--o

7.                              Locate origin
                                through
                                upstream SP

8.                              o---TraceRequest--->

9.                                             Trace Initiated

10.             <----------Acknowledgement----o
                                 <-Acknowledgement-o

11.                                            Locate attack
                                               source on network   X

12.             <------------Result----------------o

13.             o- - - - -Acknowledgement- - - - - >


             Figure 8: TraceRequest Communication Flow

Before a trace gets initiated, the RID system should check that an instance of the trace or a similar request is not already active 🙈 Traces can be resource intensive, so providers need to be able to spot potential abuse of the system or accidental resource drains 💅 Stuff like the Source and Destination Information, the associated packets, and the incident may be desirable to keep around for a period of time that administrators decide 🍓

The flow shows that an Acknowledgement message gets sent to both the downstream peer and the original requestor 🫶 If a Request in a traceback is denied, the downstream peer has the option to take action and respond with a Result message 👑 The originator of the request may follow up with the downstream peer of the SP involved, using a Request with the MsgType set to 'InvestigationRequest', to make sure something gets done if no response comes back 😭 Nothing precludes the originator from starting a brand new Request with the MsgType set to 'TraceRequest', which bypasses the SP that denied the request, if a trace is needed past that point 🦋 Another option is for the initiator to send an 'InvestigationRequest' to an SP upstream of the SP that denied the request. This only works if enough info was gathered to figure out the true source of the attack traffic from the incident-handling information 🔥

The proper response to a TraceRequest is an Acknowledgement message ✨ The Acknowledgement lets the requestor know whether the trace will keep going through the next upstream network. If there's a problem with the request, like failing to validate the digital signature or decrypt the request, an Acknowledgement MUST be sent to the requestor and the downstream peer (if they are not one and the same), giving the reason the message couldn't be processed. No skipping this one, bestie 💀 If the trace does continue, more TraceRequests carrying an Acknowledgement response happen, passing the request upstream along the path toward the source of the incident traffic 🌈 Once a source is found, a Result message gets sent to the trace originator. The SP path information in the document instance of EventData, where contact is set to 'infrastructure', tells you who that is 🧚 The same SP path info is used when sending the Acknowledgement messages to the first entry (the trace originator) and the last nested entry (the downstream peer) 💜

The Result message is encrypted [XMLencrypt] for the originator, and it carries info about the incident source and any actions taken 🔐 If the originator fails to decrypt or authenticate the Result message, an Acknowledgement gets sent back. Otherwise, no return message is sent. The final Acknowledgement to the Result message is shown as optional in the diagram above 🙈 If an Acknowledgement message is sent with the RequestStatus set to Denied, a downstream peer receiving it may choose to act to stop or mitigate the traffic at that point in the network, as close to the source as possible 🌸 If the downstream peer picks this option, it sends a Result message to the trace originator 🎀

7.1.1. RID TraceRequest Example 🎀

The example below is a Request message with MsgDestination set to 'TraceRequest', based on the incident report example from the IODEF document 💖 The RID classes were included as appropriate for a Request message of this type, using the RIDPolicy class. In this example, a CSIRT is reporting a DoS attack in progress to the upstream SP. The request asks the next SP to keep the trace going and get the traffic mitigated closer to the source 🌈

This Request is the first step of a TraceRequest, as shown in the previous diagram, where 'Attack Dest' is represented by 192.0.2.67 (and SP-1). The 'Attack Src' is identified later, in the Result message example, as 192.0.2.37, and at first it's traced to somewhere closer to 192.0.2.35 🕵️‍♀️ SP-1 is identified in the Request as CSIRT-FOR-OUR-DOMAIN. SP-2 is identified in the RID document for the Request as the 'RIDSystem' in 'MsgDestination', at 192.0.2.3, using the Node class ✨ SP-3 shows up later in the Result message, and the administrator is identified as Admin-contact@10.1.1.2 because they searched for 192.0.2.35 🦋 The administrator may be different from the constituency contact. An additional Request with MsgDestination set to 'TraceRequest' happened between SP-2 and SP-3, but it isn't included here 💅 SP-3 is the service provider for 192.0.2.32/27 and was able to take the action to rate-limit their traffic 🔥

The SP-1, SP-2, and SP-3 info would be swapped out for the appropriate (and valid) email and other contact information in real usage 💜 The Node class lets you identify a system in multiple ways, such as a fully qualified domain name or an IP address provided for the SP 🧚 Any mapping of existing relationships from the SP Node info to the name, contact, digital signature verification info, and other identifying or trust info is handled at the application layer, to support end users of the incident management system 🌸 A packet is included in this example so SP-2 and SP-3 can perform traces to the attack source before taking the requested action to 'rate-limit' the traffic 🫶 The subnet of 192.0.2.0 uses a 27-bit mask in the examples below 🍓

In the following example, use of [XMLsig] to generate digital signatures follows the guidance of [XMLsig] 1.0. Version 1.1 of [XMLsig] supports additional digest algorithms. Reference [RFC4051] for URIs intended for use with XML digital signatures, encryption, and canonicalization 🌈 SHA-1 SHOULD NOT be used; see [RFC6194] for further details 🙈

Note: Due to the limit of 72 characters per line, some line breaks were added in the examples and schemas in this document 💖

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<iodef-rid:RID lang="en-US"
 xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
 xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-rid-2.0">
 <iodef-rid:RIDPolicy MsgDestination="RIDSystem" MsgType="TraceRequest">
   <iodef-rid:PolicyRegion region="IntraConsortium"/>
     <iodef:Node>
      <iodef:Address category="ipv4-addr">192.0.2.3</iodef:Address>
     </iodef:Node>
     <iodef-rid:TrafficType type="Attack"/>
     <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
            CERT-FOR-OUR-DOMAIN#207-1
     </iodef:IncidentID>
     <!-- IODEF-Document included in RID -->
     <iodef-rid:ReportSchema Version="1.0">
      <iodef-rid:XMLDocument dtype="xml" meaning="xml">
       <IODEF-Document lang="en">
        <iodef:Incident purpose="traceback" restriction="need-to-know">
          <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
                           CERT-FOR-OUR-DOMAIN#207-1
          </iodef:IncidentID>
          <iodef:DetectTime>2004-02-02T22:49:24+00:00</iodef:DetectTime>
          <iodef:StartTime>2004-02-02T22:19:24+00:00</iodef:StartTime>
          <iodef:ReportTime>2004-02-02T23:20:24+00:00</iodef:ReportTime>
          <iodef:Description>
                           Host involved in DoS attack
          </iodef:Description>
          <iodef:Assessment>
            <iodef:Impact completion="failed" severity="low"
                          type="dos"/>
          </iodef:Assessment>
          <iodef:Contact role="creator" type="organization">
            <iodef:ContactName>Constituency-contact for 192.0.2.35
            </iodef:ContactName>
            <iodef:Email>Constituency-contact@192.0.2.35</iodef:Email>
          </iodef:Contact>
          <iodef:EventData>
            <iodef:Flow>
              <iodef:System category="source">
                <iodef:Node>
                  <iodef:Address category="ipv4-addr">192.0.2.35
                  </iodef:Address>
                </iodef:Node>
                <iodef:Service ip_protocol="6">
                  <iodef:Port>38765</iodef:Port>
                </iodef:Service>

              </iodef:System>
              <iodef:System category="target">
                <iodef:Node>
                  <iodef:Address category="ipv4-addr">192.0.2.67
                  </iodef:Address>
                </iodef:Node>
                <iodef:Service ip_protocol="6">
                  <iodef:Port>80</iodef:Port>
                </iodef:Service>
              </iodef:System>
            </iodef:Flow>
            <iodef:Expectation action="rate-limit-host" severity="high">
              <iodef:Description>
                     Rate-limit traffic close to source
            </iodef:Description>
          </iodef:Expectation>
          <iodef:Record>
            <iodef:RecordData>
              <iodef:Description>
               The IPv4 packet included was used in the described attack
              </iodef:Description>
              <iodef:RecordItem dtype="ipv4-packet">450000522ad9
                0000ff06c41fc0a801020a010102976d0050103e020810d9
                4a1350021000ad6700005468616e6b20796f7520666f7220
                6361726566756c6c792072656164696e6720746869732052
                46432e0a
              </iodef:RecordItem>
             </iodef:RecordData>
            </iodef:Record>
           </iodef:EventData>
           <iodef:History>
             <iodef:HistoryItem action="rate-limit-host">
               <iodef:DateTime>
                      2001-09-14T08:19:01+00:00
               </iodef:DateTime>
               <iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
                      CSIRT-FOR-OUR-DOMAIN#207-1
               </iodef:IncidentID>
               <iodef:Description>
              Notification sent to next upstream SP closer to 192.0.2.35
               </iodef:Description>
              </iodef:HistoryItem>
             </iodef:History>
            </iodef:Incident>
           </IODEF-Document>
         </iodef-rid:XMLDocument>
       <!-- End of IODEF-Document included in RID -->
       <!-- Start of detached XML signature included in RID -->
       <iodef-rid:Signature dtype="xml" meaning="xml">
        <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"
                   Id="dsig-123456">
        <SignedInfo>
<CanonicalizationMethod
  Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod
  Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
    <Reference URI="">
    <Transforms>
     <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
     <Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2">
     <XPath xmlns="http://www.w3.org/2002/06/xmldsig-filter2"
       xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
       xmlns:dsig-trans="http://www.w3.org/2002/06/xmldsig-filter2"
       Filter="intersect">
       //dsig:Signature[@Id = 'dsig-123456']/
       ancestor::iodef-rid:ReportSchema/
       iodef-rid:XMLDocument/IODEF-Document[1]/iodef:Incident[1]/
       iodef:EventData[1]/iodef:Record[1]/iodef:RecordData[1]/
       iodef:RecordItem[1]</XPath></Transform></Transforms>
    <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
    <DigestValue>
       NQuIhPjdZuZJnPi/hW62dwJT1dR+vqcZV8mpemCVN5g=
    </DigestValue>
   </Reference></SignedInfo>
   <SignatureValue>
lnq/ePQ4AVpxCR0ifCp9sMsW0r/AdT3C2GR/zaN1V+hZ/NApOygUjMzTCQnx+RvGPNkO/RVq
BEIDgZQUEnQZn/uSbmr0tQ6xpBfaxF1DCosLgiZy+2jFzpXrwoN/jHNgtxR/9QLW9mZ+I7V6
LEEJ73Kut+d0naTGHlyi64ab2PqsVuRXQ4pXUKbhMkhzeTIqvFLK93KGfsIMd6Cb+n2u/ABy
Lkc+gflJYUWVP4DxkQ4cyex6hM6RYTRUSr7jVD9K4d8KFP2g85i69YLtSu01W1Np0afpJ4a9
MK0E7ISMNRmC8wIklCAsSXiBRqyaEwaSy/clybI0vCTPqGOYh3/SZg==
   </SignatureValue>
   <KeyInfo>
    <KeyValue>
      <RSAKeyValue>
       <Modulus>
z8adrX9m0S8OxIxN+fui33wiz4ZYgb4xPbR9MS5pOp1A8kVpH5Ew3N6O3/dMs2a4diIxyGLV
h0r86QXWH/W6T2IC2ny+hi+jWRwXrvgTY3ZAFgePvz2OdRhVN/cUbOto4Pa4I2mVZWW+/Q0F
n7YpqPBDDxlGq/xyFPuYq/4y7Y+Ah+vHO2ZSaiQjbj8F38XrGhwlcbFVyK8AmxK3z0zWwX86
uMEqVCjW6s6j2KAWdbAjEpgZHlJY87i/DqnFgxfmdg3oru+YeiEPVRY8hyQpYbtgryveZOHT
gnCHmS/53U9jSS0cyb/ADuj1upfyNoOiMMgQr7Olhc5pTvuWAl4Fnw==</Modulus>
       <Exponent>AQAB</Exponent>
      </RSAKeyValue>
      </KeyValue>
    </KeyInfo>
   </Signature>
  </iodef-rid:Signature>
  <!-- End of detached XML signature included in RID -->
      </iodef-rid:ReportSchema>
   </iodef-rid:RIDPolicy>
</iodef-rid:RID>

7.1.2. Acknowledgement Message Example ✨

Okay so this is the Acknowledgement example, and it's literally answering the Request we just looked at 💅 The SP that got the request is saying "yep, we're cool with keeping this trace going in our network" 🫶

<iodef-rid:RID lang="en"
               xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
               xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
  <iodef-rid:RIDPolicy MsgType="Acknowledgement"
                       MsgDestination="RIDSystem">
    <iodef-rid:PolicyRegion region="IntraConsortium"/>
    <iodef:Node>
      <iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address>
    </iodef:Node>
    <iodef-rid:TrafficType type="Attack"/>
    <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
      CERT-FOR-OUR-DOMAIN#207-1
    </iodef:IncidentID>
  </iodef-rid:RIDPolicy>
  <iodef-rid:RequestStatus AuthorizationStatus="Approved"/>
</iodef-rid:RID>

7.1.3. Result Message Example 🦋

Now the Result example! It's replying to the same Request up above, and it's giving closure 🔥 This message type only shows up after an Acknowledgement, and only inside a Request flow where a TraceRequest is in progress. It can also be a direct response to a Request whose MsgType is set to 'InvestigationRequest' 🧚 The Result tells you about where the attack came from and what got done to mitigate the traffic. Usually it's the last message in the Request flow, the final boss 👑 Okay but here's the lowkey plot twist: an Acknowledgement MAY follow if there are any issues receiving or processing the Result 💀

<iodef-rid:RID lang="en"
               xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
               xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
  <iodef-rid:RIDPolicy MsgType="Result"
                       MsgDestination="RIDSystem">
    <iodef-rid:PolicyRegion region="IntraConsortium"/>
    <iodef:Node>
      <iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address>

    </iodef:Node>
    <iodef-rid:TrafficType type="Attack"/>
    <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
      CERT-FOR-OUR-DOMAIN#207-1
    </iodef:IncidentID>

<!-- IODEF-Document included in RID -->
    <iodef-rid:ReportSchema Version="1.0">
     <iodef-rid:XMLDocument dtype="xml" meaning="xml">
      <iodef:IODEF-Document lang="en">
      <iodef:Incident restriction="need-to-know" purpose="traceback">
        <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
          CERT-FOR-OUR-DOMAIN#207-1
        </iodef:IncidentID>
      <iodef:DetectTime>2004-02-02T22:49:24+00:00</iodef:DetectTime>
      <iodef:StartTime>2004-02-02T22:19:24+00:00</iodef:StartTime>
      <iodef:ReportTime>2004-02-02T23:20:24+00:00</iodef:ReportTime>
      <iodef:Description>Host involved in DoS attack</iodef:Description>
      <iodef:Assessment>
        <iodef:Impact severity="low" completion="failed"
                      type="dos"/>
      </iodef:Assessment>
      <iodef:Contact role="creator" type="organization">
        <iodef:ContactName>Constituency-contact for 192.0.2.35
        </iodef:ContactName>
        <iodef:Email>Constituency-contact@192.0.2.35</iodef:Email>
      </iodef:Contact>
      <iodef:EventData>
        <iodef:Contact role="admin" type="organization">
          <iodef:ContactName>Admin-contact for 192.0.2.35
          </iodef:ContactName>
          <iodef:Email>Admin-contact@10.1.1.2</iodef:Email>
        </iodef:Contact>
        <iodef:Flow>
          <iodef:System category="intermediate">
            <iodef:Node>
              <iodef:Address category="ipv4-addr">192.0.2.35
              </iodef:Address>
            </iodef:Node>
          </iodef:System>
        </iodef:Flow>
        <iodef:EventData>
          <iodef:Contact role="admin" type="organization">
            <iodef:ContactName>Admin-contact for 192.0.2.3
            </iodef:ContactName>
            <iodef:Email>Admin-contact@192.0.2.3</iodef:Email>
          </iodef:Contact>
          <iodef:Flow>
            <iodef:System category="intermediate">

              <iodef:Node>
                <iodef:Address category="ipv4-addr">192.0.2.3
                </iodef:Address>
              </iodef:Node>
            </iodef:System>
          </iodef:Flow>
        </iodef:EventData>
      </iodef:EventData>
      <iodef:EventData>
        <iodef:Flow>
          <iodef:System category="source">
            <iodef:Node>
              <iodef:Address category="ipv4-addr">192.0.2.35
              </iodef:Address>
            </iodef:Node>
            <iodef:Service ip_protocol="6">
              <iodef:Port>38765</iodef:Port>
            </iodef:Service>
          </iodef:System>
          <iodef:System category="target">
            <iodef:Node>
              <iodef:Address category="ipv4-addr">192.0.2.67
              </iodef:Address>
            </iodef:Node>
            <iodef:Service ip_protocol="6">
              <iodef:Port>80</iodef:Port>
            </iodef:Service>
          </iodef:System>
        </iodef:Flow>
        <iodef:Expectation severity="high" action="rate-limit-host">
          <iodef:Description>
            Rate-limit traffic close to source
          </iodef:Description>
        </iodef:Expectation>
        <iodef:Record>
          <iodef:RecordData>
            <iodef:Description>
              The IPv4 packet included was used in the described attack
            </iodef:Description>
            <iodef:RecordItem dtype="ipv4-packet">450000522ad9
            0000ff06c41fc0a801020a010102976d0050103e020810d9
            4a1350021000ad6700005468616e6b20796f7520666f7220
            6361726566756c6c792072656164696e6720746869732052
            46432e0a
            </iodef:RecordItem>
          </iodef:RecordData>
        </iodef:Record>
      </iodef:EventData>
      <iodef:History>
        <iodef:HistoryItem action="rate-limit-host">
          <iodef:DateTime>2004-02-02T22:53:01+00:00</iodef:DateTime>
          <iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
            CSIRT-FOR-OUR-DOMAIN#207-1
          </iodef:IncidentID>
          <iodef:Description>
            Notification sent to next upstream SP closer to 192.0.2.35
          </iodef:Description>
        </iodef:HistoryItem>
        <iodef:HistoryItem action="rate-limit-host">
          <iodef:DateTime>2004-02-02T23:07:21+00:00</iodef:DateTime>
          <iodef:IncidentID name="CSIRT-FOR-SP3">
            CSIRT-FOR-SP3#3291-1
          </iodef:IncidentID>
          <iodef:Description>
            Host rate-limited for 24 hours
            </iodef:Description>
          </iodef:HistoryItem>
        </iodef:History>
      </iodef:Incident>
      </iodef:IODEF-Document>
     </iodef-rid:XMLDocument>
<!-- End of IODEF-Document included in RID -->
   </iodef-rid:ReportSchema>
  </iodef-rid:RIDPolicy>
  <iodef-rid:IncidentSource>
    <iodef-rid:SourceFound>true</iodef-rid:SourceFound>
    <iodef:Node>
      <iodef:Address category="ipv4-addr">192.0.2.37</iodef:Address>
    </iodef:Node>
  </iodef-rid:IncidentSource>
</iodef-rid:RID>

7.2. Investigation Request Communication Flow ✨

Okay bestie, so this diagram shows a RID Request flying between RID systems on different networks 🦋 The situation is a security incident where we already know the source address, so MsgDestination gets set to 'InvestigationRequest' for the Request message, and the diagram labels that step as "Investigation" 🔥 The proper reply to a Request with MsgDestination set to 'InvestigationRequest' is a Result message 💅 But if something's wrong with the Request, like the digital signature won't validate or it can't be decrypted, an Acknowledgement message goes back to the requestor 🙈 The Acknowledgement should provide the reason why the message couldn't be processed 💖

    Attack Dest      SP-1              SP-2        Attack Src

    1. Attack    |  Attack
       reported  |  detected

    2.              Determine source
                    of security incident

    3.              o---Investigation---->

    4.                              Research
                                    incident and
                                    determine appropriate
                                    actions to take

    5.              <-------Result-------o

Figure 9: Investigation Request Communication Flow 🌸

7.2.1. Investigation Request Example 🎀

Quick heads-up: this example only shows the RID-specific bits 🧚 The IODEF and security measures look a lot like the TraceRequest, with a few differences: the source is known, the receiving RID system is known to be close to the source, and MsgDestination is set to 'InvestigationRequest' ✨ Knowing the source is indicated in the IODEF document, which lets incident sources be listed as spoofed, if that's appropriate 🫶

This flow doesn't include a Result message, because the request gets denied, as the Acknowledgement response shows 😭

Here's the cast: SP-1 is represented by CERT-FOR-OUR-DOMAIN and 192.0.2.67. SP-2 is identified by 192,0.2.98. In this example, SP-2 is the service provider for systems on the 192.0.2.32/27 subnet. The contact for the host 192.0.2.35 is known at the start of the request as 'Constituency-contact@10.1.1.2' 👑

  <iodef-rid:RID lang="en"
                 xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
                 xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
    <iodef-rid:RIDPolicy MsgType="InvestigationRequest"
                         MsgDestination="SourceOfIncident">
      <iodef-rid:PolicyRegion region="PeerToPeer"/>
      <iodef:Node>
        <iodef:Address category="ipv4-addr">192.0.2.98</iodef:Address>
      </iodef:Node>
      <iodef-rid:TrafficType type="Attack"/>
      <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
        CERT-FOR-OUR-DOMAIN#208-1
      </iodef:IncidentID>
  <!-- IODEF-Document included in RID -->
      <iodef-rid:ReportSchema Version="1.0">
       <iodef-rid:XMLDocument dtype="xml" meaning="xml">
    <iodef:IODEF-Document lang="en">
    <iodef:Incident restriction="need-to-know" purpose="other">
      <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
        CERT-FOR-OUR-DOMAIN#208-1
      </iodef:IncidentID>
      <iodef:DetectTime>2004-02-05T08:13:33+00:00</iodef:DetectTime>
      <iodef:StartTime>2004-02-05T08:13:31+00:00</iodef:StartTime>
      <iodef:EndTime>2004-02-05T08:13:33+00:00</iodef:EndTime>
      <iodef:ReportTime>2004-02-05T08:13:35+00:00</iodef:ReportTime>
      <iodef:Description>Host involved in DoS attack</iodef:Description>
      <iodef:Assessment>
        <iodef:Impact severity="low" completion="failed" type="recon"/>
      </iodef:Assessment>
      <iodef:Contact role="creator" type="organization">
        <iodef:ContactName>Constituency-contact for 192.0.2.35
        </iodef:ContactName>
        <iodef:Email>Constituency-contact@10.1.1.2</iodef:Email>
      </iodef:Contact>
      <iodef:EventData>
        <iodef:Flow>
          <iodef:System category="source">
            <iodef:Node>
              <iodef:Address category="ipv4-addr">192.0.2.35
              </iodef:Address>
            </iodef:Node>
            <iodef:Service ip_protocol="6">
              <iodef:Port>41421</iodef:Port>
            </iodef:Service>
          </iodef:System>
          <iodef:System category="target">
            <iodef:Node>
              <iodef:Address category="ipv4-addr">192.0.2.67
              </iodef:Address>
            </iodef:Node>
            <iodef:Service ip_protocol="6">
              <iodef:Port>80</iodef:Port>
            </iodef:Service>
          </iodef:System>
        </iodef:Flow>
        <iodef:Expectation severity="high" action="investigate">
          <iodef:Description>
            Investigate whether source has been compromised

          </iodef:Description>
        </iodef:Expectation>
      </iodef:EventData>
      <iodef:History>
        <iodef:HistoryItem action="block-host">
          <iodef:DateTime>2004-02-05T08:19:01+00:00</iodef:DateTime>
          <iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
            CSIRT-FOR-OUR-DOMAIN#208-1
          </iodef:IncidentID>
          <iodef:Description>
            Investigation request sent to SP for 192.0.2.35
          </iodef:Description>
        </iodef:HistoryItem>
      </iodef:History>
    </iodef:Incident>
    </iodef:IODEF-Document>
       </iodef-rid:XMLDocument>
  <!-- End of IODEF-Document included in RID -->
      </iodef-rid:ReportSchema>
    </iodef-rid:RIDPolicy>
  </iodef-rid:RID>

7.2.2. Acknowledgement Message Example 🙅‍♀️

This Acknowledgement is the reply to the Request we just looked at 💀 The SP that got the request couldn't validate the digital signature that authenticates the sending RID system, so it's a no-go 😭

  <iodef-rid:RID lang="en"
                 xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
                 xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
    <iodef-rid:RIDPolicy MsgType="Acknowledgement"
                         MsgDestination="RIDSystem">
      <iodef-rid:PolicyRegion region="IntraConsortium"/>
      <iodef:Node>
        <iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address>
      </iodef:Node>
      <iodef-rid:TrafficType type="Attack"/>
      <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
        CERT-FOR-OUR-DOMAIN#208-1
      </iodef:IncidentID>
    </iodef-rid:RIDPolicy>
    <iodef-rid:RequestStatus AuthorizationStatus="Denied"
                             Justification="Authentication"/>
  </iodef-rid:RID>

7.3. Report Communication Flow ✨

okay so this is the Report flow, and it's giving "I'm sharing the tea with the group so everyone's on the same page" 💅 The diagram shows how RID systems on different SPs pass it along 🦋

     SP-1                           SP-2

  1. Generate incident information
     and prepare Report message

  2.              o-------Report------->

  3.                          File report in database

             Figure 10: Report Communication Flow

bestie, the Report flow is how you pass incident information around. CSIRTs (and other entities) can share stuff using this format 🫶 When a report shows up, the RID system must verify that it hasn't already been filed. To check, it can compare the incident number and incident data, like the hexadecimal packet and incident class info, against what's already in the database 🔍 The Report message typically doesn't get a response. But if something goes wrong, like the digital signature [RFC3275] fails to validate or the request can't be decrypted, an Acknowledgement message gets sent back to the requestor. That Acknowledgement should explain why the message couldn't be processed 😭

7.3.1. Report Example

ngl this example only has the RID-specific bits 🎀 It's an unsolicited Report message that carries an IPv4 packet. The IODEF document and digital signature look a lot like the Request example, except MsgDestination is set to 'TraceRequest' 💜

This one is a message from SP-1, CERT-FOR-OUR-DOMAIN at 192.0.2.67, to SP-2 at 192.0.2.130, just for informational purposes about an attack that happened 🌸

<iodef-rid:RID lang="en"
               xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
               xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
  <iodef-rid:RIDPolicy MsgType="Report" MsgDestination="RIDSystem">
    <iodef-rid:PolicyRegion region="PeerToPeer"/>
    <iodef:Node>
      <iodef:Address category="ipv4-addr">192.0.2.130</iodef:Address>
    </iodef:Node>
    <iodef-rid:TrafficType type="Attack"/>
    <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
      CERT-FOR-OUR-DOMAIN#209-1
    </iodef:IncidentID>
<!-- IODEF-Document included in RID -->
    <iodef-rid:ReportSchema>
     <iodef-rid:XMLDocument dtype="xml" meaning="xml">
  <iodef:IODEF-Document lang="en">
  <iodef:Incident restriction="need-to-know" purpose="reporting">
    <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
      CERT-FOR-OUR-DOMAIN#209-1
    </iodef:IncidentID>
    <iodef:DetectTime>2004-02-05T10:21:08+00:00</iodef:DetectTime>
    <iodef:StartTime>2004-02-05T10:21:05+00:00</iodef:StartTime>
    <iodef:EndTime>2004-02-05T10:35:00+00:00</iodef:EndTime>
    <iodef:ReportTime>2004-02-05T10:27:38+00:00</iodef:ReportTime>
    <iodef:Description>Host illicitly accessed admin account
    </iodef:Description>
    <iodef:Assessment>
      <iodef:Impact severity="high" completion="succeeded"
                    type="admin"/>
      <iodef:Confidence rating="high"/>
    </iodef:Assessment>
    <iodef:Contact role="creator" type="organization">
      <iodef:ContactName>Constituency-contact for 192.0.2.35
      </iodef:ContactName>
      <iodef:Email>Constituency-contact@10.1.1.2</iodef:Email>
    </iodef:Contact>
    <iodef:EventData>
      <iodef:Flow>
        <iodef:System category="source">
          <iodef:Node>
            <iodef:Address category="ipv4-addr">192.0.2.35
            </iodef:Address>
          </iodef:Node>
          <iodef:Service ip_protocol="6">
            <iodef:Port>32821</iodef:Port>
          </iodef:Service>
        </iodef:System>
        <iodef:System category="target">
          <iodef:Node>
            <iodef:Address category="ipv4-addr">192.0.2.67
            </iodef:Address>
          </iodef:Node>
          <iodef:Service ip_protocol="6">
            <iodef:Port>22</iodef:Port>
          </iodef:Service>
        </iodef:System>

      </iodef:Flow>
    </iodef:EventData>
    <iodef:History>
      <iodef:HistoryItem action="rate-limit-host">
        <iodef:DateTime>2004-02-05T10:28:00+00:00</iodef:DateTime>
        <iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
          CSIRT-FOR-OUR-DOMAIN#209-1
        </iodef:IncidentID>
        <iodef:Description>
          Incident report sent to SP for 192.0.2.35
        </iodef:Description>
      </iodef:HistoryItem>
    </iodef:History>
  </iodef:Incident>
  </iodef:IODEF-Document>
     </iodef-rid:XMLDocument>
<!-- End of IODEF-Document included in RID -->
    </iodef-rid:ReportSchema>
    </iodef-rid:RIDPolicy>
</iodef-rid:RID>

7.4. Query Communication Flow 🔎

okay this is the Query flow, and it's so iconic because one RID system asks another for info 👑 The diagram below shows how RID systems on different networks handle it 🌈

     SP-1                           SP-2

  1. Generate a request for
     information on a specific
     incident number or incident type

  2.              o-------Query------->

  3.                              Verify policy information
                                  and determine if matches exist
                                  for requested information

  4.              <-------Report------o

  5.  Associate report to request
      by incident number or type
      and file report(s).

              Figure 11: Query Communication Flow

so the Query message gets a Report message back as its response 🦋 If that Report is empty, it means the responding host didn't have anything to share with the requestor 🙈 The incident number, the responding RID system, and the transport all help match the request to the response. That matters because a report can get filed without being solicited, so you can't just assume every report is an answer 💖 If there's a problem with the Query message, like the digital signature failing to validate or the request not being decrypted, an Acknowledgement message is sent to the requestor. That Acknowledgement should give the reason the message couldn't be processed 😭

7.4.1. Query Example

the Query request can show up in a few different formats depending on what kind of query it is ✨ If the incident number is the only thing provided, the IODEF document and IP packet data might not be needed to finish the request 🧚 But if a type of incident is requested, the incident number stays NULL, and the IP packet data won't be included in the IODEF RecordItem class. Then the other incident information is the main thing to compare against 🍓 And if an incident number isn't the same between CSIRTs, the incident number and/or IP packet info can be sent over and used for comparison on the receiving RID system, so it can generate (a) Report message(s) 🫶

this query goes to 192.0.2.3, asking about the incident with the identifier CERT-FOR-OUR-DOMAIN#210-1 💜 The Report will be given to the requestor, who gets identified and verified through the authentication and digital signature info in the RID message. There's an example Report up above 🎀

<iodef-rid:RID lang="en"
               xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
               xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
  <iodef-rid:RIDPolicy MsgType="Query"
                       MsgDestination="RIDSystem">
    <iodef-rid:PolicyRegion region="PeerToPeer"/>
    <iodef:Node>
      <iodef:Address category="ipv4-addr">192.0.2.3</iodef:Address>
    </iodef:Node>
    <iodef-rid:TrafficType type="Attack"/>
    <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
      CERT-FOR-OUR-DOMAIN#210-1
    </iodef:IncidentID>
  </iodef-rid:RIDPolicy>
</iodef-rid:RID>

8. RID Schema Definition 💖

Okay bestie, the schema is finally here, and it's giving full XML realness 💅🎀

<?xml version="1.0" encoding="UTF-8"?>
 <xs:schema xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
  xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
  targetNamespace="urn:ietf:params:xml:ns:iodef-rid-2.0"
  elementFormDefault="qualified" attributeFormDefault="unqualified">
 <xs:import namespace="urn:ietf:params:xml:ns:iodef-1.0"
 schemaLocation="http://www.iana.org/assignments/xml-registry/schema/
 iodef-1.0.xsd"/>
 <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
 schemaLocation="http://www.w3.org/TR/xmldsig-core/
 xmldsig-core-schema.xsd"/>

 <!-- ****************************************************************
 *********************************************************************
 ***  Real-time Inter-network Defense - RID XML Schema             ***
 ***    Namespace - iodef-rid, April 2012                        ***
 ***    The namespace is defined to support transport of IODEF     ***
 ***     documents for exchanging incident information.            ***
 *********************************************************************
 -->
 <!--RID messages act as an envelope for IODEF and RID documents
     to support the exchange of incident information-->
 <!--
 ====== Real-Time Inter-network Defense - RID ======
 ====  Suggested definition for RID messaging ======

  -->

 <xs:annotation>
   <xs:documentation>XML Schema wrapper for IODEF</xs:documentation>
 </xs:annotation>
 <xs:element name="RID" type="iodef-rid:RIDType"/>
   <xs:complexType name="RIDType">
     <xs:sequence>
       <xs:element ref="iodef-rid:RIDPolicy" minOccurs="0"/>
       <xs:element ref="iodef-rid:RequestStatus" minOccurs="0"/>
       <xs:element ref="iodef-rid:IncidentSource" minOccurs="0"/>
     </xs:sequence>
     <xs:attribute name="lang"
                    type="xs:language" use="required"/>
   </xs:complexType>

 <!--Used in Acknowledgement Message for RID-->
 <xs:element name="RequestStatus" type="iodef-rid:RequestStatusType"/>
   <xs:complexType name="RequestStatusType">
      <xs:attribute name="AuthorizationStatus" use="required">
         <xs:simpleType>
           <xs:restriction base="xs:NMTOKEN">
           <xs:whiteSpace value="collapse"/>
             <xs:enumeration value="Approved"/>
             <xs:enumeration value="Denied"/>
             <xs:enumeration value="Pending"/>
             <xs:enumeration value="ext-value"/>
           </xs:restriction>
         </xs:simpleType>
      </xs:attribute>
      <xs:attribute name="ext-AuthorizationStatus"
                    type="xs:string" use="optional"/>
      <xs:attribute name="Justification">
         <xs:simpleType>
           <xs:restriction base="xs:NMTOKEN">
           <xs:whiteSpace value="collapse"/>
             <xs:enumeration value="SystemResource"/>
             <xs:enumeration value="Authentication"/>
             <xs:enumeration value="AuthenticationOrigin"/>
             <xs:enumeration value="Encryption"/>
             <xs:enumeration value="UnrecognizedFormat"/>
             <xs:enumeration value="CannotProcess"/>
             <xs:enumeration value="Other"/>
             <xs:enumeration value="ext-value"/>
           </xs:restriction>
         </xs:simpleType>
      </xs:attribute>
      <xs:attribute name="ext-Justification"
                    type="xs:string" use="optional"/>
     <xs:attribute name="restriction" type="iodef:restriction-type"/>
   </xs:complexType>

 <!--Incident Source Information for Result Message-->

 <xs:element name="IncidentSource" type="iodef-rid:IncidentSourceType"/>
   <xs:complexType name="IncidentSourceType">
     <xs:sequence>
       <xs:element ref="iodef-rid:SourceFound"/>
       <xs:element ref="iodef:Node" minOccurs="0"
           maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:attribute name="restriction" type="iodef:restriction-type"/>
   </xs:complexType>
   <xs:element name="SourceFound" type="xs:boolean"/>

 <!--
 ====== Real-Time Inter-network Defense Policy - RIDPolicy ======
 ======  Definition for RIDPolicy for messaging
  -->

 <xs:annotation>
  <xs:documentation>RID Policy used for transport of
      messages</xs:documentation>
 </xs:annotation>

 <!-- RIDPolicy information with setting information listed in RID
      documentation -->

 <xs:element name="RIDPolicy" type="iodef-rid:RIDPolicyType"/>
   <xs:complexType name="RIDPolicyType">
     <xs:sequence>
       <xs:element ref="iodef-rid:PolicyRegion" maxOccurs="unbounded"/>
       <xs:element ref="iodef:Node"/>
       <xs:element ref="iodef-rid:TrafficType" maxOccurs="unbounded"/>
       <xs:element ref="iodef:IncidentID" minOccurs="0"/>
       <xs:element ref="iodef-rid:ReportSchema" minOccurs="0"/>
     </xs:sequence>
    <xs:attribute name="MsgType" use="required">
     <xs:simpleType>
       <xs:restriction base="xs:NMTOKEN">
       <xs:whiteSpace value="collapse"/>
         <xs:enumeration value="TraceRequest"/>
         <xs:enumeration value="Acknowledgement"/>
         <xs:enumeration value="Result"/>
         <xs:enumeration value="InvestigationRequest"/>
         <xs:enumeration value="Report"/>
         <xs:enumeration value="Query"/>
         <xs:enumeration value="ext-value"/>
       </xs:restriction>
     </xs:simpleType>
    </xs:attribute>
   <xs:attribute name="ext-MsgType" type="xs:string" use="optional"/>
   <xs:attribute name="MsgDestination" use="required">
     <xs:simpleType>
       <xs:restriction base="xs:NMTOKEN">
       <xs:whiteSpace value="collapse"/>
         <xs:enumeration value="RIDSystem"/>
         <xs:enumeration value="SourceOfIncident"/>
         <xs:enumeration value="ext-value"/>
       </xs:restriction>
     </xs:simpleType>
    </xs:attribute>
   <xs:attribute name="ext-MsgDestination" type="xs:string"

                 use="optional"/>
   <xs:attribute name="restriction" type="iodef:restriction-type"/>
    </xs:complexType>
   <xs:element name="PolicyRegion">
     <xs:complexType>
      <xs:attribute name="region" use="required">
       <xs:simpleType>
        <xs:restriction base="xs:NMTOKEN">
        <xs:whiteSpace value="collapse"/>
          <xs:enumeration value="ClientToSP"/>
          <xs:enumeration value="SPToClient"/>
          <xs:enumeration value="IntraConsortium"/>
          <xs:enumeration value="PeerToPeer"/>
          <xs:enumeration value="BetweenConsortiums"/>
          <xs:enumeration value="ext-value"/>
        </xs:restriction>
       </xs:simpleType>
      </xs:attribute>
      <xs:attribute name="ext-region"
                    type="xs:string" use="optional"/>
     </xs:complexType>
   </xs:element>
   <xs:element name="TrafficType">
     <xs:complexType>
      <xs:attribute name="type" use="required">
       <xs:simpleType>
        <xs:restriction base="xs:NMTOKEN">
        <xs:whiteSpace value="collapse"/>
          <xs:enumeration value="Attack"/>
          <xs:enumeration value="Network"/>
          <xs:enumeration value="Content"/>
          <xs:enumeration value="DataWithHandlingRequirements"/>
          <xs:enumeration value="AudienceRestriction"/>
          <xs:enumeration value="Other"/>
          <xs:enumeration value="ext-value"/>
        </xs:restriction>
       </xs:simpleType>
      </xs:attribute>
      <xs:attribute name="ext-type"
                    type="xs:string" use="optional"/>
     </xs:complexType>
   </xs:element>
 <!--Used to include an enveloped XML document in RID-->
 <xs:element name="ReportSchema" type="iodef-rid:ReportSchemaType"/>
   <xs:complexType name="ReportSchemaType">
     <xs:sequence>
       <xs:element ref="iodef-rid:XMLDocument" minOccurs="1"
                   maxOccurs="1"/>

       <xs:element ref="iodef-rid:URL" minOccurs="0"
                   maxOccurs="1"/>
       <xs:element ref="iodef-rid:Signature" minOccurs="0"
                   maxOccurs="unbounded"/>
     </xs:sequence>
      <xs:attribute name="Version" use="optional">
       <xs:simpleType>
        <xs:restriction base="xs:NMTOKEN">
        <xs:whiteSpace value="collapse"/>
          <xs:enumeration value="1.0"/>
               <xs:enumeration value="ext-value"/>
        </xs:restriction>
       </xs:simpleType>
      </xs:attribute>
      <xs:attribute name="ext-Version"
                    type="xs:string" use="optional"/>
      <xs:attribute name="XMLSchemaID" use="optional">
       <xs:simpleType>
        <xs:restriction base="xs:anyURI">
        <xs:whiteSpace value="collapse"/>
          <xs:enumeration value="urn:ietf:params:xml:ns:iodef-1.0"/>
               <xs:enumeration value="ext-value"/>
        </xs:restriction>
       </xs:simpleType>
      </xs:attribute>
      <xs:attribute name="ext-XMLSchemaID"
                    type="xs:string" use="optional"/>
     </xs:complexType>
   <xs:element name="XMLDocument"
               type="iodef:ExtensionType"/>
   <xs:element name="URL"
               type="xs:anyURI"/>
   <xs:element name="Signature"
               type="iodef:ExtensionType"/>
 </xs:schema>

9. Security Requirements ✨

9.1. XML Digital Signatures and Encryption ✨

okay bestie, RID is built on top of existing security standards and data markings in RIDPolicy 🔒 so it can hit the security levels it needs for swapping incident info. it uses TLS plus the XML security features of encryption [XMLencrypt] and digital signatures [RFC3275] [XMLsig] 💅 these give clear ways to keep messages secure, authenticated, and authorized, meet policy and privacy guidelines, and maintain integrity 🫶 implementers should check out XML Signature Best Practices [XMLSigBP] for more info on leveling up security and mitigating attacks 🛡️

As the relevant sections of this doc spell out, the XML digital signature [RFC3275] and XML encryption [XMLencrypt] get used in these cases:

XML Digital Signature

The originator of a Request MUST use a detached signature to sign at least one of the original elements contained in the RecordItem class 🖊️ this gives authentication to all upstream participants in the trace or anyone involved in the investigation. all instances of RecordItem the originator provides may be individually signed, and extra RecordItem entries added by upstream peers in the trace or investigation may be signed by the peer adding the data, while the original RecordItem entry(s) and detached signature(s) from the original requestor stay put 🦋 it's important to know the data is signed at the RecordItem level. multiple RecordItems can live in one IODEF document and come from different sources, so the signature goes on the RecordItem level to make an XML detached signature work 🧩 Exclusive canonicalization [XMLCanon] is REQUIRED for the detached signature and not the references, because the XML document generated then gets included in the RID message inside the Signature element of the ReportSchema class. this signature MUST be passed to all recipients of the Request message 💌
if a Request doesn't include a RecordItem entry, a timestamp MUST be used so there's data to sign for the multi-hop authentication use case ⏰ the DateTime element of the iodef:RecordData class ([RFC5070], Section 3.19.1) is used for this 🌸
for all message types, the full IODEF-RID document MUST be signed using an enveloped signature by the sending peer to give authentication and integrity to the receiving RID system 👑 the signature goes in an instance of the Signature element
XML Signature Best Practices [XMLSigBP] guidance SHOULD be followed to prevent or mitigate security risks ✨ examples include authenticating a signature before processing (since processing can run potentially dangerous operations) and limiting the use of URIs, since they may enable cross-site scripting attacks or access to local information 🙈
XML Path Language (XPath) 2.0 [XMLPath] MUST be followed to specify the portion of the XML document to be signed. XPath is used to specify a location within an XML document 🗺️ best practice recommendations for using XPath [XMLSigBP] SHOULD be referenced to reduce the risk of denial-of-service attacks 🧯 the use of XSLT transforms MUST be restricted according to security guidance in [XMLSigBP]

XML Encryption

the IODEF-RID document MAY be encrypted to add an extra layer of security between peers, so the message isn't just encrypted for transport 🔐 this would be agreed upon between peers or a consortium, or decided on a per-message basis, depending on security requirements. it should be noted that there are transport cases where the RIDPolicy class needs to be presented in clear text, as detailed in the transport document [RFC6546] 📄
a Request, or any other message type that may get relayed through RID systems before reaching the intended destination because of trust relationships, MAY be encrypted specifically for the intended recipient 🎀 this might be needed if the RID network is being used for message transfer, the intermediate parties don't need to know the request contents, and there's no direct communication path. in that case, the RIDPolicy class is used by intermediate parties, so RIDPolicy is kept in clear text 🫧
the action taken in the Result message may be encrypted using the key of the request originator 🗝️ then intermediate parties can view the RIDPolicy info and know the trace has been completed without needing to see the action. if encryption is limited to sections of the message, the History class information would be encrypted. otherwise, it is RECOMMENDED to encrypt the entire IODEF-RID document and use an enveloped signature for the originator of the request 💜 the existence of the Result message for an incident would tell any intermediate parties in the path of the incident investigation that the incident handling is done ✅
the iodef:restriction attribute sets expectations for the privacy of an incident and is defined in Section 3.2 of RFC 5070 🕵️‍♀️ following the XML encryption guidance in the Security Requirements section, iodef:restriction can be set in any of the RID classes to define restrictions and encryption requirements for exchanging incident info. the restriction options enable encryption for the complete exchange of an IODEF document (including any extensions), or within specific IODEF classes or IODEF extensions where more limited restrictions are wanted 🌈 the restriction attribute is in each of the RID classes and MUST be used in accordance with confidentiality expectations for either sections of the IODEF document or the complete IODEF document. consortiums and organizations should consider this guidance when creating exchange policies 📋
expectations based on how restriction is set:
- if restriction is set to 'private', the class or document MUST be encrypted for the recipient using XML encryption and the public key of the recipient. see Section 9.3 for a discussion on public key infrastructure (PKI) and other security requirements 🔑
- if restriction is set to 'need-to-know', the class or document MUST be encrypted so only those with need-to-know access can decrypt the data 🧁 the document can either be encrypted for each individual who should have access, or be encrypted with a single group key. the method used SHOULD adhere to any certificate policy and practices agreements between entities for using RID. a group key here means a single symmetric key used to encrypt the block of data. users with need-to-know access may be given the shared key through a secure distribution method, for example by providing the symmetric key encrypted with each user's public key 🤫
- if restriction is set to 'public', the class or document MUST be sent in clear text 🌷 this can be critical if certain sections or an entire document are to be shared without restrictions. it gives flexibility to share certain info freely within an incident where that makes sense 🦋
- if restriction is set to 'default', the information can be shared according to an information disclosure policy pre-arranged by the communicating parties 🤝
expectations based on where the restriction setting is placed:
- if restriction is set within one of the RID classes, the restriction applies to the entire IODEF document 📜
- if restriction is set within individual IODEF classes, the restriction applies to that specific IODEF class and its children 🧸

forming policies is a seriously important part of using a messaging system like RID to exchange potentially sensitive info 🥹 lots of things should be considered for peering parties, and this section covers some guidelines to protect the data, systems, and transport. policies should provide guidelines for communication methods, security, and fall-back procedures 🛟 see Sections 9.4 and 9.5 for more on consortiums and PKI considerations 🎀

the security considerations for storing and exchanging info in RID messaging may include following local, regional, or national regulations, on top of the obligations to protect client info during an investigation 🏛️ RIDPolicy is a necessary tool for listing the requirements of messages, giving a way to categorize data elements for proper handling 🗂️ the sending entity also gets controls to protect messages from third parties through XML encryption 🔒

RID gives a method to exchange incident-handling requests and Report messages between entities 📨 admins get to base decisions on available resources and other factors in their network, and keep control of incident investigations inside their own network 🏰 so RID lets participating networks manage their own security controls, using the info listed in RIDPolicy 💅

RID is used to transfer or exchange XML documents in an IODEF format or using another IANA-registered format 📦 implementations SHOULD NOT download schemas at runtime because of the security implications, and included documents MUST NOT be required to provide a resolvable location for their schema 🚫✨

9.2. Message Transport ✨

okay so the actual transport details live in their own doc, [RFC6546] 🚚. The transport protocols MUST use encryption for an extra layer of security and integrity 🔐, and they also need to support mutual authentication through bidirectional certificate usage 🫶. Any new transport method that gets defined should take advantage of existing standards, so RID systems are easier to implement and plug in. Session encryption for RID message transport is enforced in the transport spec 💅. The privacy and security stuff is handled fully in RID itself, which protects the sensitive parts of documents and gives a way to authenticate the messages. So RID messages do not rely on the security provided by the transport layer alone 🙈. The encryption requirements and considerations for RID messages are discussed in Section 9.1 of this document 🎀.

Consortiums can vary their transport mechanisms, so they decide on a shared protocol when they talk to peers in a neighboring consortium using RID 🌈. RID systems MUST implement and deploy HTTPS as defined in the transport document [RFC6546], and they can optionally MAY support other protocols, like the Blocks Extensible Exchange Protocol (BEEP) [RFC3080] ✨. Other transport protocols would need bindings defined before they can be supported 🧚.

Systems that send authenticated RID messages between networks MUST use a secured system and interface to connect to a border network's RID systems 🔒. Every connection to a RID system MUST meet the security requirements agreed upon through consortium regulations, peering, or SLAs 📜. The RID system MUST listen for and send RID messages on only the designated port, and that port MUST also be over an encrypted tunnel that meets the minimum algorithm and key length requirements set by the consortium, peering, or SLA 🦋. The cryptographic algorithms picked for symmetric encryption, digital signatures, and hash functions MUST meet the minimum security levels of the times ⏰. And the encryption strength MUST adhere to the import and export regulations of the countries involved in the data exchange 🌍.

Out-of-band communications dedicated to SP interaction for RID messaging would give extra security and guaranteed bandwidth during a denial-of-service attack 🛡️. For example, an out-of-band channel could be made of logical paths defined over the existing network 🛤️. Out-of-band communications may not be practical or possible between service providers, but provisions should be considered to protect the incident management systems used for RID messaging 🫶. Methods to protect the data transport may also be provided through session encryption 💜.

9.3. Public Key Infrastructure 🔑

It is RECOMMENDED that RID, the XML security functions, and the transport protocols properly integrate with a PKI managed by the consortium, federate PKIs within a consortium, or use a PKI managed by a trusted third party 🤝. Entities MAY use shared keys as an alternate option, although this may limit the ability to validate certificates and could introduce risk ⚠️. For the Internet, a few existing efforts could be leveraged to provide the supporting PKI, including the Regional Internet Registry's (RIR's) PKI hierarchy, vendor issued certificates, or approved issuers of Extended Validation (EV) Certificates 🌸. Security and privacy considerations related to consortiums are discussed in Sections 9.4 and 9.5 📖.

Using PKI between entities or through a consortium SHOULD adhere to any applicable certificate policy and practices agreements for the use of RID 📋. [RFC3647] specifies a commonly used format for certificate policy (CP) and certification practices statements (CPS) 📝. Systems with predefined RID relationships include those that peer directly or through a consortium with agreed-upon appropriate use agreements 🤝. Agreements to trust other entities may be based on assurance levels, which could be determined by comparing the CP, CPS, and/or RID operating procedures 🔍. The initial comparison of policies, plus the ability to audit controls, gives a baseline assurance level for entities forming and maintaining trust relationships 💖. Trust relationships may also be defined through a bridged or hierarchical PKI that both peers belong to 🌳. If shared keys or keys issued from a common CA are used, verifying controls to determine the assurance level for trusting other entities may be limited to the RID policies and operating procedures 🫧.

XML security functions used in RID require a trust center, such as a PKI, to distribute credentials and provide the necessary level of security for this protocol 🏰. Layered transport protocols also use encryption and rely on a trust center 🔐. Public key certificate pairs issued by a trusted Certification Authority (CA) MAY be used to provide the necessary level of authentication and encryption for the RID protocol 🎀. The CA used for RID messaging must be trusted by all involved parties, and it may take advantage of similar efforts, such as the Internet2 federated PKI or the ARIN/RIR effort to provide a PKI to service providers 🌈. The PKI used for authentication also provides the certificates needed for encryption in the RID transport protocol [RFC6546] 🦋.

9.3.1. Authentication

Hosts receiving a RID message MUST be able to verify that the sender of the request is valid and trusted 🕵️‍♀️. Digital signatures on a hash of the RID message, using an X.509 version 3 certificate issued by a trusted party, MUST be used to authenticate the request ✍️. The X.509 version 3 specifications, along with the digital signature specifications and path validation standards set forth in [RFC5280], MUST be followed so things interoperate with a PKI designed for similar purposes 🧩. Full path validation verifies the chaining relationship to a trusted root and also performs a certificate revocation check 🔁. The use of digital signatures in RID XML messages MUST follow the World Wide Web Consortium (W3C) recommendations for signature syntax and processing when either the XML encryption [XMLencrypt] or digital signature [XMLsig] [RFC3275] is used within a document 🌟.

It might be helpful to define an extension to the authentication scheme that uses attribute certificates [RFC5755], so an application could automatically determine whether human intervention is needed to authorize a request 🤔. The specification of such an extension is out of scope for this document, though 🙃.

Pre-shared keys may be considered for authentication at the transport layer 🗝️. If this option is selected, the specifications set forth in "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)" [RFC4279] MUST be followed 📚. Transport specifications are detailed in a separate document [RFC6546] 🚚.

9.3.2. Multi-Hop Request Authentication

Multi-hop authentication is used when a Request goes to multiple entities or SPs in an iterative manner 🪄. It is REQUIRED in Requests that involve multiple SPs, where Requests are forwarded iteratively through peers 🔥. Bilateral trust relationships MAY be used between peers, but multi-hop authentication MUST be used when the originator of a message is authenticated several hops into the message flow 🦋.

For practical reasons, SPs may want to prioritize incident-handling events based on the immediate peer for a Request, the originator of the Request, and the listed Confidence rating for the incident 📊. To give a higher assurance level of the Request's authenticity, the originating RID system is included in the Request along with contact information and the information for all RID systems in the path the trace has taken 🗺️. This information comes through the IODEF EventData class, which nests the list of systems and contacts involved in a trace while setting the category attribute to "infrastructure" 🧚.

To provide multi-hop authentication, the originating RID system MUST include a digital signature in the Request sent to all systems in the upstream path ✍️. The signature is applied to the RecordItem class of the IODEF, following the XML digital signature specifications from W3C [XMLsig], using a detached signature 💌. The signature MUST be passed to all parties that receive a Request, and each party MUST be able to perform full path validation on the digital signature [RFC5280] 🔗. To make that work, the RecordItem data MUST remain unchanged as the Request is passed along between providers, and it is the only element the signature is applied to 🧊. If additional RecordItem elements are included in the document at upstream peers, the initial RecordItem entry MUST still remain with the detached signature 🫶. Subsequent RecordItem elements may be signed by the peer adding the incident information for the investigation 🌷. Another benefit of this requirement is that the integrity of the filter used is ensured as it passes to subsequent SPs in the upstream trace of the incident 💜. The trusted PKI also provides the keys used to digitally sign the RecordItem class for a Request, which meets the requirement of authenticating the original request 🔑. Any host in the path of the trace should be able to verify the digital signature using the trusted PKI 🕵️‍♀️.

When an enterprise using RID sends a Request to its provider, the enterprise's signature MUST be included in the initial request 🏢. The SP may generate a new request to send upstream to members of the SP consortium to continue the investigation 🌊. If the original request is sent, the originating SP, acting on behalf of the enterprise network under attack, MUST also digitally sign the full IODEF document with an enveloped signature to assure the authenticity of the Request 🖊️. An SP that offers RID as a service may use its own PKI to secure RID communications between its RID system and the attached enterprise networks 🎀. SPs participating in the trace MUST be able to determine the authenticity of RID requests 👑.

9.4. Consortiums and Public Key Infrastructures

okay bestie, consortiums are literally the ideal way to build a communication web of trust for RID messaging 🕸️💖 ngl it's giving teamwork. Direct relationships can still be the move for some comms though, like between a provider of incident information and a subscriber of the incident reports 🎀. The consortium could bring centralized resources, like a PKI 🔐, plus established guidelines and control requirements for using RID 💅. It may help set up trust relationships between the participating SPs so they reach the level of cooperation and experience-sharing they need ✨. This can be done through PKI certificate policy [RFC3647] reviews, which figure out the right trust levels between organizations or entities 🧠. A consortium may also be used for other purposes to make communication among SPs in a common area (Internet, region, government, education, private networks, etc.) way smoother 🌈.

Using a PKI to distribute the certificates used by RID systems is an already established way to link trust relationships between consortiums that peer with SPs belonging to a separate consortium 🦋. In other words, consortiums can peer with other consortiums so RID messages can flow between the participating SPs 🫶. The PKI, along with Memorandums of Agreement, could be used to link border directories and share public key information in a bridge, a hierarchy, or a single cross-certification relationship 🌸.

Consortiums also need to establish guidelines for each participating SP to adhere to. The RECOMMENDED guidelines include:

Physical and logical practices to protect RID systems;
Network- and application-layer protection for RID systems and communications;
Proper use guidelines for RID systems, messages, and requests; and
A PKI, certificate policy, and certification practices statement to provide authentication, integrity, and privacy.

The functions of a consortium's role are basically the same as those of a PKI federation 👑. The PKI federations that exist today are responsible for setting security guidelines and PKI trust models, and those trust models are what support applications sharing information through trusted methods and protocols 🔥.

A PKI can also give the same level of security for communication between an end entity (an enterprise, educational, or government customer network) and the SP 💜.

9.5. Privacy Concerns and System Use Guidelines

okay real talk, privacy issues get messy fast when information-sharing is needed to stop or mitigate a security incident 😭. The RIDPolicy class is used to automate enforcement of the privacy concerns listed in this document 🤖. The privacy and system use concerns for the system communicating RID messages, and for other integrated components, include the following 🧁:

Service Provider Concerns:

Privacy of data monitored and/or stored on Intrusion Detection Systems (IDSs) for attack detection.
Privacy of data monitored and stored on systems used to trace traffic across a single network.
Privacy of incident information stored on incident management systems participating in RID communications.

Customer Attached Networks Participating in RID with SP:

Customer networks may include enterprise, educational, government, or other networks attached to an SP participating in RID. Customers should review data handling policies to understand how data will be protected by a service provider 🛡️. This information will help customers decide what types of data, at what sensitivity level, can be shared with service providers 📋. It could be used at the application layer to set up sharing profiles for entities and groups; see Section 9.6 💅.
Customers should request information on the security and privacy considerations in place at their SP and at the consortium the SP belongs to 🙈. Customers should understand, if their data were forwarded, how it might be sanitized and how it will be protected 🔒. Before sharing data with their SP, customers should also understand whether limitations can be placed on how it will be used ✨.
Customers should be aware that their data can and will be sent to other SPs in order to complete a trace, unless an agreement stating otherwise is made in the service level agreements between the customer and SP 😳. Customers who are thinking about privacy options may limit the use of this feature if they don't want their data forwarded 🦋.

Parties Involved in the Attack:

Privacy of the identity of a host involved in an attack, or of any indicators of compromise 🕵️.
Privacy of information such as the source and destination used for communication over the monitored or RID-connected network(s) 👀.
Protection of data from being viewed by intermediate parties in the path of an Request request should be considered 🧱.

Consortium Considerations:

System use restrictions for security incident handling within the local region's definitions of appropriate traffic. When participating in a consortium, appropriate use guidelines should be agreed upon and entered into contracts 📜.
System use that prohibits the consortium's participating SPs from inappropriately tracing traffic to locate sources or mitigating traffic unlawfully within the jurisdiction or region 🚫.

Inter-Consortium Considerations:

System use between peering consortiums should consider any government communication regulations that apply between those two regions, such as encryption export and import restrictions 🌍.
System use between consortiums SHOULD NOT request traffic traces and actions beyond the scope intended and permitted by law or inter-consortium agreements ⚠️.
System use between consortiums should consider national boundary issues and request limits in their appropriate system use agreements. Appropriate use should include restrictions that prevent the protocol from being used to limit or restrict traffic that is otherwise permitted within the country where the peering consortium resides 🗺️.

The security and privacy considerations listed above are for the consortiums, SPs, and enterprises to agree upon 🤝. The agreed-upon policies may be facilitated through the RIDPolicy class and application-layer options. Some privacy considerations are addressed through the RID guidelines for encryption and digital signatures, as described in Section 9.1 💖.

RID is useful for determining the true source of an incident that traverses multiple networks, and for communicating security incidents and automating the response 🔍. The information obtained from the investigation may determine the identity of the source host or the SP used by the source of the traffic 🎯. It's worth noting that the trace mechanism used across a single SP may also raise privacy concerns for the clients of that network 😬. Methods that may raise concern include those that store packets for some length of time so they can be traced after the fact 📦. Monitoring networks for intrusions, and for tracing capabilities, also raises concerns about potentially sensitive valid traffic traversing the monitored network 👻. IDSs and single-network tracing are outside the scope of this document, but the concern should be noted and addressed within the use guidelines of the network 📝. Some IDSs and single-network trace mechanisms try to properly address these issues ✅. RID is designed to provide the information needed by any single-network trace mechanism 🧩. The provider's choice of a single trace mechanism depends on resources, existing solutions, and local legislation ⚖️. Privacy concerns about the single-network trace must be dealt with at the client-to-SP level and are out of scope for RID messaging 🙅‍♀️.

The identity of the true source of an attack being traced through RID could be sensitive 🫣. The true identity listed in a Result message can be protected by encrypting the IODEF document and RID Result information with [XMLencrypt] enveloping, using the public encryption key of the originating SP 🔐. Alternatively, the action taken may be listed without revealing the identity to the originating SP 🎭. The ultimate goal of the RID communication system is to stop or mitigate attack traffic, not to make sure the identity of the attack traffic is known to everyone involved 💅. The SP that identifies the source should deal directly with the involved parties and proper authorities to set the guidelines for releasing that information, if it's considered sensitive 🧑‍⚖️. In some situations, systems used in attacks are compromised by an unknown source and then used to attack other systems 😵. In that case, the reputation of a business or organization may be at stake, and the action taken may be the only additional information reported in the Result message to the originating system 💼. If the security incident is minor, such as a zombie system used in part of a large-scale DDoS attack, making sure the system is taken off the network until it has been fixed may be enough 🧟. The decision is left to system users and consortiums to determine the appropriate data to share, since the goal of the specification is to provide the right technical options to stay compliant 🌷. The textual descriptions should include details of the incident in order to protect the reputation of the unknowing attacker and prevent the need for additional investigation 🙏. Local, state, or national laws may dictate the appropriate reporting action for specific security incidents 📚.

Privacy becomes an issue whenever sensitive data traverses a network 🚨. For example, if an attack occurred between a specific source and destination, then every SP in the path of the trace becomes aware that the cyber attack happened 😱. In a targeted attack, it may not be desirable for information about two nation states battling a cyber war to become general knowledge to all intermediate parties 🌐. However, it's important to allow the traces to take place in order to halt the activity, since the health of the networks in the path could also be at stake during the attack 🛟. This gives a second reason for letting the Result message include only an action taken and not the identity of the offending host 🎀. In the case of a Request or Report, where the originating SP knows which SP will receive the request for processing, the free-form text areas of the document could be encrypted [XMLencrypt] using the public key of the destination SP, so that no other SP in the path can read the contents 🔏. The encryption is accomplished through the W3C [XMLencrypt] specification for encrypting an element 🧁.

In some situations, all network traffic of a nation may be routed through a single SP 🇺🇳. In that situation, options must support sending Result messages from a downstream peer of that SP 🪞. That option adds an extra level of abstraction to hide the identity and the SP of the identified source of the traffic 🥷. Legal action may override this technical decision after the trace has taken place, but that is outside the technical scope of this document ⭐.

Okay so picking up right where we left off 💅 The privacy worry here is about sending a Request message to ask for action close to where the attack traffic is actually coming from 🫶 Intermediate SPs can relay the request if there's no direct trust relationship with the SP closest to the source, but they don't need to peek inside the packet or read the text description field(s) in the request 🙈 This message type doesn't require any action from intermediate RID systems except passing the packet along to the next SP in the path ✨ So the contents of the request can be encrypted for the destination system 🔐 The intermediate SPs only need to know how to direct the request to the manager of the ASN that the source IP address belongs to 🧚

Traces have to be legit security-related incidents, never used for sabotage or censorship 💀 Like, blocking or rate-limiting legit traffic so people can't share info (think restricting access to online versions of papers), or restricting a competitor's product just to tank their business? Absolutely not 😤

Intra-consortium RID comms get extra messy, especially when the peering consortiums are in different regions or nations 🌍 Request messages and the requested actions to mitigate or stop traffic have to follow the appropriate use guidelines and still prevent abuse of the system 🚫 First, the peering consortiums need to figure out which types of traffic can be traced between the borders of each consortium's participating SPs 🗺️ The traced traffic should be limited to security-incident-related traffic 💖 Second, a trace allowed inside one consortium might, if passed to a peering consortium, bump up against that consortium's freedom-of-information laws 📜 For example, a consortium in one country allows tracing traffic containing objectionable material that's outlawed in that country. That trace might be a valid use inside that country's network border, but it may not be permitted to continue across network boundaries where that content is allowed by law 🙅‍♀️ Continuing the trace into another country's network could improperly restrict access to data, and a continued trace into a second country may break that nation's laws and regulations 😬

Any such traces MUST cease at the country's border. 🛑

The privacy concerns in this section cover issues among the trusted parties in a trace within an SP, a RID consortium, and peering RID consortiums 👯 Data used for RID communications must also be protected from parties that aren't trusted 🔒 That protection comes from authenticating and encrypting documents as they travel the path of trusted servers, plus the local security controls in place for the incident management systems 🛡️ Each RID system MUST perform a bidirectional authentication when sending a RID message, and use the public encryption key of the upstream or downstream peer to send a message or document over the network 🔑 This means the document gets decrypted and re-encrypted at each RID system via TLS over a transport protocol such as [RFC6546] 🔁 RID messages may be decrypted at each RID system so it can properly process the request or relay the information 📬 And honestly? Today's processing power is more than sufficient to handle the minimal burden of encrypting and decrypting relatively small typical RID messages 💪

The application layer can be used to set up workflows and rulesets for sharing profiles, specific to entities or consortiums 🧩 Profiles can lean on sharing agreements to restrict which data types or classifications of data get shared 🔏 The level of information or classification shared with any entity may depend on the protection levels the receiving entity offers, plus periodic validation of those controls 🔍 A profile may also say how far information can be shared according to the entity and data type, and whether requests to share data from an entity have to go directly to that entity 📨

Pre-defined sharing profiles will be possible in some cases 📋 These include any use case where an agreement is in place before sharing happens, like between clients and SPs, partners, or consortiums 🤝 There may also be cases where sharing profiles can't be set up in advance, like an organization dealing with an incident that needs help from an entity it has never worked with before 🆘 An organization may want to set up sharing profiles for possible user groups so it's ready for different incident scenarios 🗂️ Those user groups could include business partners, industry peers, service providers, experts who aren't part of a service provider, law enforcement, or regulatory reporting bodies 👮‍♀️

Workflows to approve transactions may be specific to sharing profiles and data types 🚦 Application developers should include capabilities that enable these decision points for users of the system 🛠️

Any expectations between entities for preserving the weight and admissibility of evidence should be handled at the policy and agreement level ⚖️ A sharing profile may include notes or an indicator for approvers in workflows to show whether such agreements exist 🏷️

10. Security Considerations 🔐

RID has tons of security requirements and considerations built into the protocol design, several of which are covered in the Security Requirements section 🧠 For a complete view of security, you have to think about availability, confidentiality, and integrity for the transport, storage, and exchange of information 🛡️

Protected tunnels between systems accepting RID communications provide confidentiality, integrity, authenticity, and privacy for the data at the transport layer 🚇 Encryption and digital signatures are also used at the IODEF document level through RID options, giving confidentiality, integrity, authenticity, privacy, and traceability of the document contents at the application layer ✨ Trust relationships are based on PKI and on comparing and validating the security controls of the incident management systems communicating via RID 🤝 Trust levels can be set up through cross-certification, where entities compare PKI policies covering how an entity's PKI and the certificates issued under that policy are managed and handled 📜 [RFC3647] defines an Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework that can be used to compare policies and set up trust levels and agreements between entities, between an entity and a consortium, and between consortiums 🧾 The agreements SHOULD consider key management practices, including the ability to perform path validation on certificates [RFC5280], key distribution techniques [RFC2585], and Certificate Authority and Registration Authority management practices 🔑

The agreements between entities SHOULD also include a shared understanding of how RID security, policy, and privacy options from the Security Requirements and Security Considerations sections get used 💬 The formality, requirements, and complexity of agreements covering the certificate policy, practices, supporting infrastructure, and use of RID options SHOULD be decided by the entities or consortiums writing those agreements 📝

11. Internationalization Issues 🌏

The Node class identifies a host or network device 💻 This document reuses the definition of Node from the IODEF specification [RFC5070], Section 3.16 📖 However, that document didn't clearly specify whether a NodeName could be an Internationalized Domain Name (IDN) 🤔 RID systems MUST treat the NodeName class as a domain name slot [RFC5890] 🏷️ RID systems SHOULD support IDNs in the NodeName class 🌍 If they do, the UTF-8 representation of the domain name MUST be used, meaning all of the domain name's labels MUST be U-labels expressed in UTF-8 or NR-LDH labels [RFC5890], and A-labels MUST NOT be used 🙅‍♀️ An application communicating via RID can convert between A-labels and U-labels using the Punycode encoding [RFC3492] for A-labels, as described in the protocol specification for Internationalized Domain Names in Applications [RFC5891] 🔄✨

12. IANA Considerations ✨

Okay, IANA time 🗂️ This document uses URNs to describe XML namespaces and XML schemas [XMLschema] that follow a registry mechanism from [RFC3688]. Very organized, very iconic.

Here's the registration request for the iodef-rid namespace:

URI: urn:ietf:params:xml:ns:iodef-rid-2.0
Registrant Contact: IESG.
XML: None. Namespace URIs do not represent an XML specification.

And here's the one for the iodef-rid XML schema 🎀

URI: urn:ietf:params:xml:schema:iodef-rid-2.0
Registrant Contact: IESG.
XML: See Section 8, "RID Schema Definition", of this document.

Next up, a brand new registry gets created and IANA is the one managing it 🌸 It's called "XML Schemas Exchanged via RID", and here's how each entry is set up:

Name of the registry: "XML Schemas Exchanged via RID"

Namespace details: A registry entry for an XML Schema Transferred
via RID consists of:

   Schema Name: A short string that represents the schema
   referenced.  This value is for reference only in the table.
   The version of the schema MUST be included in this string to
   allow for multiple versions of the same specification to be in
   the registry.

   Version: The version of the registered XML schema.  The version
   is a string that SHOULD be formatted as numbers separated by a
   '.' (period) character.

   Namespace: The namespace of the referenced XML schema.  This is
   represented in the RID ReportSchema class in the XMLSchemaID
   attribute as an enumerated value is represented by a URN or
   URI.

   Specification URI: A URI [RFC3986] from which the registered
   specification can be obtained.  The specification MUST be
   publicly available from this URI.

   Reference: The reference to the document that describes the
   schema.

Information that must be provided to assign a new value: The above
list of information.

Fields to record in the registry: Schema Name, Version, Namespace,
Specification URI, Reference

Initial registry contents: See Section 5.6.1.

Allocation Policy: Expert Review [RFC5226] and Specification
Required [RFC5226].

So the Designated Expert is basically the hero here 🦸‍♀️ They're expected to chat with the MILE (Managed Incident Lightweight Exchange) working group, or its successor if one exists (e.g., over email to the working group's mailing list). They also have to pull the XML schema specification from the provided URI, to check that it's publicly available and that the URI is correct. The biggest job? Making sure the XML schema is actually appropriate for use in RID 💖

Now for the second registry, "RID Enumeration List" 📋 It's there so people can add enumeration values to attributes in the iodef-rid XML schema. It starts out totally empty:

Name of the registry: "RID Enumeration List"

Fields to record in the registry: Attribute Name, Attribute Value,
Description, Reference

Initial registry content: none.

Allocation Policy: Expert Review [RFC5226]

The Designated Expert should again check in with the MILE (Managed Incident Lightweight Exchange) working group or its successor if one exists (e.g., over email to the working group's mailing list). They're also expected to review each request and confirm that the enumeration fits the attribute 🔍 And if a specification is attached to the request, it MUST be reviewed by the Designated Expert. No skipping that one, periodt 💅

13. Summary

Okay, tracing security incidents has always been a nightmare 😭 Spoofed sources, limited resources, and bandwidth hogging all make it so much harder. Response is slow too, even when the IP address is legit, because you need resources to tell the responsible party about the attack and then actually stop or mitigate the attack traffic.

Identifying and tracing attacks in near real time is essential for shutting down attack attempts 🛡️ SPs need policies and automated methods to fight back against the hacker's efforts, plus automated monitoring and response so they can spot and trace attacks quickly without resource-heavy side effects.

Hooking everything up to a centralized communication system is a must 🫶 That's what lets detection, tracing, and identification of attack sources on a single network get coordinated. RID is the thing that lets SP resources plug together for every part of attack detection, tracing, and source identification, and it levels up the communication between SPs ✨

The chat happens through flexible IODEF XML-based documents passed between incident-handling systems or RID systems 💌 A Request gets sent to an upstream SP, and it might lead to an upstream trace or an action to stop or mitigate the attack traffic 🏃‍♀️ Messages go between peers, and the security is built right into the RID messaging scheme through existing standards like XML encryption and digital signatures 🔐 Policy info rides along inside the RID message itself via the RIDPolicy 📜

Basically, RID keeps SPs talking in a timely way, and that's essential for incident handling 👑

14. References

14.1. Normative References

[RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2585]     Housley, R. and P. Hoffman, "Internet X.509 Public Key
              Infrastructure Operational Protocols: FTP and HTTP",
              RFC 2585, May 1999.

[RFC3023]     Murata, M., St. Laurent, S., and D. Kohn, "XML Media
              Types", RFC 3023, January 2001.

[RFC3275]     Eastlake, D., Reagle, J., and D. Solo, "(Extensible
              Markup Language) XML-Signature Syntax and Processing",
              RFC 3275, March 2002.

[RFC3470]     Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines
              for the Use of Extensible Markup Language (XML)
              within IETF Protocols", BCP 70, RFC 3470, January 2003.

[RFC3492]     Costello, A., "Punycode: A Bootstring encoding of
              Unicode for Internationalized Domain Names in
              Applications (IDNA)", RFC 3492, March 2003.

[RFC3688]     Mealling, M., "The IETF XML Registry", BCP 81,
              RFC 3688, January 2004.

[RFC4051]     Eastlake, D., "Additional XML Security Uniform Resource
              Identifiers (URIs)", RFC 4051, April 2005.

[RFC4279]     Eronen, P. and H. Tschofenig, "Pre-Shared Key
              Ciphersuites for Transport Layer Security (TLS)",
              RFC 4279, December 2005.

[RFC5070]     Danyliw, R., Meijer, J., and Y. Demchenko, "The
              Incident Object Description Exchange Format", RFC 5070,
              December 2007.

[RFC5226]     Narten, T. and H. Alvestrand, "Guidelines for Writing
              an IANA Considerations Section in RFCs", BCP 26,
              RFC 5226, May 2008.

[RFC5280]     Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation
              List (CRL) Profile", RFC 5280, May 2008.

[RFC5646]     Phillips, A. and M. Davis, "Tags for Identifying
              Languages", BCP 47, RFC 5646, September 2009.

[RFC5755]     Farrell, S., Housley, R., and S. Turner, "An Internet
              Attribute Certificate Profile for Authorization",
              RFC 5755, January 2010.

[RFC5890]     Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document
              Framework", RFC 5890, August 2010.

[RFC5891]     Klensin, J., "Internationalized Domain Names in
              Applications (IDNA): Protocol", RFC 5891, August 2010.

[RFC6546]     Trammell, B., "Transport of Real-time Inter-network
              Defense (RID) Messages over HTTP/TLS", RFC 6546,
              April 2012.

[XML1.0]      Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C.,
              and F. Yergeau, "Extensible Markup Language (XML) 1.0",
              W3C Recommendation XML 1.0, November 2008,
              <http://www.w3.org/TR/xml/>.

[XMLCanon]    Boyer, J., "Canonical XML 1.0", W3C Recommendation 1.0,
              December 2001, <http://www.w3.org/TR/xml-c14n>.

[XMLPath]     Berglund, A., Boag, S., Chamberlin, D., Fernandez, M.,
              Kay, M., Robie, J., and J. Simeon, "XML Schema Part 1:
              Structures", W3C Recommendation Second Edition,
              December 2010, <http://www.w3.org/TR/xpath20/>.

[XMLSigBP]    Hirsch, F. and P. Datta, "XML-Signature Best
              Practices", W3C Recommendation, August 2011,
              <http://www.w3.org/TR/xmldsig-bestpractices/>.

[XMLencrypt]  Imaura, T., Dillaway, B., and E. Simon, "XML Encryption
              Syntax and Processing", W3C Recommendation,
              December 2002, <http://www.w3.org/TR/xmlenc-core/>.

[XMLschema]   Thompson, H., Beech, D., Maloney, M., and N.
              Mendelsohn, "XML Schema Part 1: Structures", W3C
              Recommendation Second Edition, October 2004,
              <http://www.w3.org/TR/xmlschema-1/>.

[XMLsig]      Bartel, M., Boyer, J., Fox, B., LaMaccia, B., and E.
              Simon, "XML-Signature Syntax and Processing", W3C
              Recommendation Second Edition, June 2008,
              <http://www.w3.org/TR/xmldsig-core/>.

14.2. Informative References

[RFC1930]     Hawkinson, J. and T. Bates, "Guidelines for creation,
              selection, and registration of an Autonomous System
              (AS)", BCP 6, RFC 1930, March 1996.

[RFC3080]     Rose, M., "The Blocks Extensible Exchange Protocol
              Core", RFC 3080, March 2001.

[RFC3647]     Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
              Wu, "Internet X.509 Public Key Infrastructure
              Certificate Policy and Certification Practices
              Framework", RFC 3647, November 2003.

[RFC3986]     Berners-Lee, T., Fielding, R., and L. Masinter,
              "Uniform Resource Identifier (URI): Generic Syntax",
              STD 66, RFC 3986, January 2005.

[RFC5735]     Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
              BCP 153, RFC 5735, January 2010.

[RFC6045]     Moriarty, K., "Real-time Inter-network Defense (RID)",
              RFC 6045, November 2010.

[RFC6194]     Polk, T., Chen, L., Turner, S., and P. Hoffman,
              "Security Considerations for the SHA-0 and SHA-1
              Message-Digest Algorithms", RFC 6194, March 2011.

[XMLNames]    Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
              Thomson, "Namespaces in XML 1.0 (Third Edition)", W3C
              Recommendation , December 2009,
              <http://www.w3.org/TR/xml-names/>.

Appendix A. Acknowledgements 🫶

Huge thanks to all the colleagues and the wider Internet community who reviewed and commented on the document, and who shared recommendations to improve, simplify, and secure the protocol 💜 Steve Bellovin, David Black, Harold Booth, Paul Cichonski, Robert K. Cunningham, Roman Danyliw, Yuri Demchenko, Sandra G. Dykes, Stephen Farrell, Katherine Goodier, Cynthia D. McLain, Thomas Millar, Jean-Francois Morfin, Stephen Northcutt, Damir Rajnovic, Tony Rutkowski, Peter Saint-Andre, Jeffrey Schiller, Robert Sparks, William Streilein, Richard Struse, Tony Tauber, Brian Trammell, Sean Turner, Iljitsch van Beijnum, and David Waltermire 🌈

Author's Address ✨

okay so this is the bit where the author tells you where to find her, bestie 💅 Kathleen M. Moriarty was at EMC Corporation, and you can reach her at the address below 🎀

Kathleen M. Moriarty
EMC Corporation
176 South Street
Hopkinton, MA
United States

EMail: Kathleen.Moriarty@emc.com

that's the whole RFC, babe 🦋 we made it through all 20 parts together 🫶

📦 where this page comes from

ietf: rfc6545 2012-04
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms