Real-time Inter-network Defense (RID)
obsoletes
- rfc-6045 — Real-time Inter-network Defense (RID)
Extracted elements (30)
A star topology was added as a supported consortium model (in addition to direct peer and mesh topologies) to accommodate use cases such as country-level CSIRTs or service providers that distribute incident information to many consumer organizations, requiring trust relationships only between the central provider and each consumer.
RID maintains a separate schema rather than using IODEF's AdditionalData extension so that the RIDPolicy class can be extracted by the transport protocol without decrypting the IODEF payload. This separation allows routing and policy decisions to operate on unencrypted RIDPolicy metadata while the incident content remains confidential.
The TraceRequest and InvestigationRequest were collapsed from two separate message types (as in RFC 6045) into a single Request message with a MsgType attribute, because the two message descriptions were identical except for MsgType. This simplification reduces implementation complexity while preserving functional distinction.
The IODEF model MUST be fully implemented for RID messages that include IODEF payloads to ensure proper parsing. All IODEF classes, elements, and attributes are valid in a RID message context, though some optional IODEF elements become mandatory for specific RID message types.
Any intermediate parties in a TraceRequest MUST be able to view RIDPolicy information of responding message types in order to properly direct RID messages.
Each IODEF-RID document MUST use the namespace 'urn:ietf:params:xml:ns:iodef-rid-2.0' in the top-level RID-Document element.
If a Request is denied, the originator and sending peer (if they are not the same) MUST both receive the Acknowledgement message, providing the sending peer the option to take action to stop or mitigate traffic as close to the source as possible.
If a RID system receives a TraceRequest that contains its own information in the path, the trace must cease and the RID system should generate an alert to inform network operations staff that a tracing loop exists.
If a single TraceRequest results in divergent paths of Requests (e.g., in a DDoS with multiple sources), a separate instance number MUST be used under the same IncidentID.
RID documents MUST begin with an XML declaration and MUST specify the XML version used; UTF-8 encoding is REQUIRED. The special XML characters '&', '<', '>', '"', and ''' MUST be escaped with their entity reference equivalents.
RID systems participating in a consortium are REQUIRED to fully implement Sections 4, 5, 6, 7, 8, 9, 10, and 11 to prevent interoperability concerns. Sections 1, 2, 3, and 12 are informational background.
The five RID message types (Request, Acknowledgement, Result, Report, Query) MUST be implemented. RID messages use both IODEF and RID documents, which MUST be encapsulated for transport as specified in RFC 6546.
The included XML schema in a ReportSchema MUST define a separate namespace. Parsers that encounter an unrecognized element in a namespace they do support SHOULD reject the document as a syntax error.
The Result information MUST go back to the originating RID system that began the investigation or trace, passing through the RID systems in the path.
The SP MUST confirm that the traffic actually originated from the suspected system before taking any action and confirm the reason for the request.
When a parser encounters an included XML document it does not understand, the included document MUST be ignored and not processed, but the remainder of the RID document MUST be processed. Implementations SHOULD NOT download schemas at runtime due to security implications, and included documents MUST NOT be required to provide a resolvable schema location.
Privacy concerns are significant because RID messages may carry sensitive incident data about individuals or organizations. Privacy issues must be evaluated before sharing; the iodef:restriction attribute governs disclosure guidelines. Policy guidelines for sharing, use, and abuse must be established by consortiums or through peering agreements. Section 9.5 provides detailed privacy and system-use guidelines.
The IncidentSource class, used only in Result messages, contains a BOOLEAN SourceFound element and zero or more Node elements identifying source host(s) or network(s). If Node is used, the Address element MUST contain the IP address of the identified system.
The PolicyRegion element identifies the expected sharing range of incident information using values: ClientToSP, SPToClient, IntraConsortium, PeerToPeer, BetweenConsortiums, or ext-value. Multiple values may be selected to cover all applicable policy considerations.
The ReportSchema class embeds a complete IODEF or other IANA-registered XML document within a RID message via the XMLDocument element. It also supports zero or more Signature elements for detached or enveloped XML digital signatures and an optional URL pointing to the schema.
The RequestStatus class, used only in Acknowledgement messages, carries the required AuthorizationStatus attribute (Approved, Denied, Pending) and an optional Justification attribute explaining the reason (SystemResource, Authentication, AuthenticationOrigin, Encryption, UnrecognizedFormat, CannotProcess, Other).
The RIDPolicy class is the central routing and policy element present in all message types. It carries mandatory attributes MsgType (TraceRequest, Acknowledgement, Result, InvestigationRequest, Report, Query) and MsgDestination (RIDSystem or SourceOfIncident), plus aggregate elements Node, IncidentID, PolicyRegion, TrafficType, and optional ReportSchema.
The TrafficType element in RIDPolicy identifies incident traffic category: Attack (information security incident), Network (routing issues), Content (regional content restrictions), DataWithHandlingRequirements (regulatory/legal data), AudienceRestriction (restricted audience), or Other (requires description). Multiple values may be selected.
IANA maintains a registry of XML schemas approved for inclusion in RID messages via the ReportSchema class. Registered schemas must include schema name, version, namespace, and specification URI. The RID XML namespace 'urn:ietf:params:xml:ns:iodef-rid-2.0' is also registered with IANA per RFC 3688.
RID messages require both enveloped and detached XML digital signatures. An enveloped signature authenticates the sending CSIRT for each hop; a detached signature on a RecordItem entry by the initiating CSIRT is preserved through all relay hops to authenticate the original requestor. XML encryption is applied to message content as required by policy, agreements, and iodef:restriction data markers.
RID relies on a PKI for authentication; each participating entity must hold a certificate. Multi-hop TraceRequests require intermediate RID systems to verify the enveloped signature of the immediate sender and the detached signature of the original requestor. PKI trust anchors and consortium membership must be negotiated in advance.
RID use must be limited to pre-approved, authorized purposes only. Requests must be legitimate incidents and MUST NOT be used for sabotage or censorship (e.g., rate-limiting legitimate traffic to suppress content or sabotage competitors). Abuse prevention policies must be established through peering or consortium agreements.
InvestigationRequest flow: initiating CSIRT sends InvestigationRequest routed toward the source IP address (MsgDestination = SourceOfIncident) through RID systems; the closest SP to the source investigates, takes action, and returns an Acknowledgement and ultimately a Result to the initiator.
TraceRequest flow: initiating RID system sends TraceRequest upstream; each SP generates an Acknowledgement (Approved/Denied/Pending) and, if approved, forwards the TraceRequest further upstream while appending its AS/path information; upon source identification, the terminal SP sends a Result back through the same path to the originator. A Pending Acknowledgement is automatically generated after a 2-minute timeout without administrator action.
RID uses XML 1.0 with mandatory UTF-8 encoding and the namespace 'urn:ietf:params:xml:ns:iodef-rid-2.0'. The Boolean data type is represented as xs:boolean, supporting '1' or 'true' for TRUE and '0' or 'false' for FALSE.