Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS

HTTP/TLS is not ideally suited for RID transport because HTTP is a client-server protocol while RID is a message-exchange protocol; however, the ease of implementation over HTTP/TLS outweighs these concerns, and a new port (4590) is used to differentiate RID traffic from standard HTTPS.

http, tls

The minimum required TLS version was upgraded from the predecessor RFC 6046 to TLS 1.1 (from no stated minimum), and the minimum recommended version to TLS 1.2, to address known vulnerabilities in earlier protocol versions.

tls, security

The RID-Callback-Token header was added (replacing RFC 6046) to allow matching of RID replies during callback independent of the content of the underlying RID message, addressing the time gap between request and asynchronous response.

http

Any IODEF message (RFC 5070) may be transported using the RID over HTTP/TLS mechanism by sending it as a RID Report message, making this transport applicable beyond RID-specific exchanges.

http

RID systems SHOULD NOT use TCP port 443 for RID messages to avoid being confused with standard HTTP/TLS servers; port 4590 is the designated well-known port for RID over HTTP/TLS.

http, tls

The inclusion of Common Names (CN-IDs) in certificates identifying RID systems is NOT RECOMMENDED; DNS-ID identifiers per RFC 6125 Section 6.4 are the preferred certificate identifier type for RID systems.

tls, pkix

A RID system MUST NOT send an HTTP Response containing any RID message other than the one corresponding to the one sent in the HTTP Request, per the allowable type mappings in Table 1.

http

A RID system SHOULD answer 'GET /' or 'HEAD /' with 204 No Content. Access to Request-URIs other than '/' by any method SHOULD return 404 Not Found.

http

All RID messages sent in HTTP Requests MUST be sent using the POST method with a Request-URI of '/'. The Content-type Request and Response headers MUST be 'text/xml'.

http

Each RID system MUST be prepared to accept HTTP/TLS connections from any RID peer with which it communicates, in order to support callback for delayed replies.

http, tls, security

Every RID system participating in a consortium SHOULD listen for HTTP/TLS connections on port 4590. RID systems SHOULD NOT use TCP port 443 to avoid confusing standard HTTP/TLS servers for RID systems.

http, tls

If a RID system receives an improper RID message in an HTTP Response or cannot process it, it MUST log the error and present it to the RID system administrator for handling.

http

RID systems MUST be prepared for a query to be met with a 202 Accepted, an empty response body, a connection termination, and a callback. All RID messages require a response.

http

RID systems MUST support and SHOULD use HTTP/1.1 persistent connections. RID systems MUST support chunked transfer encoding on the HTTP server side.

http, tcp

RID systems MUST support verification of certificates against an explicit whitelist of peer certificates. RID systems SHOULD support verification by matching DNS-ID or CN-ID with a reverse DNS lookup of the connecting peer.

tls, pkix, security, dns

RID systems MUST use mutual authentication; both HTTPS clients and HTTPS servers MUST be identified by an X.509 certificate with full path validation as defined in RFC 5280.

tls, security, pkix

RID systems MUST use TLS version 1.1 or higher for confidentiality, identification, and authentication. RID systems MUST NOT request, offer, or use any version of SSL or any version of TLS prior to 1.1.

tls, security

RID systems SHOULD NOT return 3xx Redirection response codes and SHOULD NOT follow any 3xx Redirection. The protocol provides no in-band method for handling a change of address.

http, security

The RID callback MUST contain a zero-length entity body and a 'RID-Callback-Token' entity header field containing a unique token generated by the receiving RID system.

http

The TLS session MUST use non-NULL ciphersuites for authentication, integrity, and confidentiality. Sessions MAY be renegotiated within these constraints.

tls, security, crypto

When performing RID callback, a responding system MUST connect to the host at the network-layer address from which the original request was sent; there is no mechanism for redirected callback.

http

Wildcards MUST NOT appear in the DNS-ID or CN-ID of a certificate identifying a RID system. RID systems MUST verify the reference identifiers of their peers against those stored in presented certificates.

tls, pkix, security

Table 1 defines the allowable RID response message types for each request type. InvestigationRequest and TraceRequest may receive Acknowledgement, Result, or Report (200) or empty 202; Query may receive Acknowledgement or Report (200) or empty 202; Acknowledgement/Result callbacks receive empty 200; Report may receive Acknowledgement or empty 200.

http

The RID-Callback-Token is an opaque, whitespace-free string of up to 255 printable ASCII characters used as an entity header field in 202 Accepted responses to uniquely identify a pending callback from the receiving RID system to the sending RID system.

http

IANA assigned TCP port 4590 with service name 'RID over HTTP/TLS' for use by RID systems, consistent with BCP 56 (RFC 3205), because RID over HTTP/TLS is a substantially new service requiring different border control than standard HTTPS.

registry, http, tls

RID systems MUST use TLS 1.1 or higher with mutual X.509 certificate authentication and non-NULL ciphersuites. SSL and TLS versions prior to 1.1 MUST NOT be used due to known security vulnerabilities. Certificate reference identifiers must be verified against a whitelist or via reverse DNS lookup.

tls, security, pkix, crypto

RID systems SHOULD NOT follow or issue HTTP 3xx redirections to prevent misdirection attacks; the protocol has no in-band mechanism to handle address changes of a RID system.

http, security

A RID request-response exchange has two states: (1) immediate response — the receiver returns a RID message with HTTP 200 within the client timeout; (2) deferred callback — the receiver returns HTTP 202 with a RID-Callback-Token, then later initiates a new HTTPS connection to deliver the reply.

http

The RID-Callback-Token is defined in ABNF as: callback-token = 1*255(VCHAR), representing 1 to 255 printable ASCII (VCHAR) characters with no whitespace.

http