XML Pipelining with Chunks for the Internet Registry Information Service
updated by
- rfc-8996 — Deprecating TLS 1.0 and TLS 1.1
updates
- rfc-3981 — IRIS: The Internet Registry Information Service (IRIS) Core Protocol
Extracted elements (31)
XPC uses chunk-based framing so that XML fragments can be acted upon (pipelined) before reception of the entire XML instance. This allows the server to begin processing individual search results and stream them back incrementally rather than waiting for a complete XML document.
Although XPC and XPCS have separate URI scheme names and S-NAPTR application protocol labels, both are identified with the same <transferProtocol> value "iris.xpc1" in version information chunks. Implementers must not assume separate protocol identifiers based on the URI scheme alone.
This document updates RFC 3981 (IRIS-CORE) by changing the default IRIS transport from IRIS-BEEP to IRIS-XPC. The well-known TCP port for XPC is TCP/713 (Section 13.5).
After SASL success, new security layers take effect on the first octet following the authentication success (as) chunk sent by the server and on the first octet sent after receipt of the as chunk by the client.
Authentication success (as) and authentication failure (af) chunks are server-to-client only. If a client sends either, the server will respond with a block-error and MAY close the session.
Clients MUST NOT send size information (si) chunks; servers MAY close the session per Section 8 if such a chunk is received. Clients MUST NOT send other information (oi) chunks; servers MAY close similarly.
Clients MUST NOT use SASL/PLAIN without first encrypting the TCP session (e.g., with TLS). Clients MUST implement SASL/PLAIN and TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher.
During SASL exchange, clients MUST NOT send subsequent requests until they have received either an authentication success or authentication failure chunk from the server.
If a server needs to close a connection due to error, it SHOULD send a response block with a block-error, data-error, or version information chunk with KO=0, then close the TCP connection. For unsupported protocol versions, the server SHOULD follow this same procedure.
If an idle timeout occurs on an incomplete data block (block received but no terminating chunk), a block-error SHOULD be sent. Two minutes is RECOMMENDED for this timeout value. For idle sessions between transactions, an idle-timeout chunk SHOULD be sent with KO=0 before closing.
Non-empty authorization identity strings used within IRIS-XPC MUST be normalized according to RFC 4013 (SASLprep). Clients MUST use these strings as given by configuration or the user.
Request and response blocks MUST always have a minimum of 1 chunk.
Reserved bits (bits 3–7 of the block header and bits 2–4 of the chunk descriptor) MUST be set to 0. If a server receives a request with any reserved block header bits set to 1 and does not understand the purpose, it SHOULD follow the error-close procedure in Section 8.
Servers SHOULD NOT send an RSB to a client until they have received the entire RQB, because clients will not start processing the RSB until the full RQB is sent and the RSB may fill TCP buffers.
The number of octets in the authority field of an RQB MUST be no more and no less than the number specified by the authority length field.
When TLS and SASL are used together, TLS MUST always be applied before any SASL mechanism. IRIS-XPC does not support multiple SASL authentications.
XML used in IRIS-XPC (via RFC 4991 schema) MUST NOT use any character encodings other than UTF-8 or UTF-16.
Eight chunk types are defined (bits 5–7 of the descriptor): 000=no data (nd), 001=version information (vi), 010=size information (si), 011=other information (oi), 100=SASL data (sd), 101=authentication success (as), 110=authentication failure (af), 111=application data (ad).
The Connection Response Block (CRB) is sent by the server immediately upon connection. It either contains a single version-information chunk with KO=1 (service available) or a single system-error chunk with KO=0 (server cannot process requests).
Within a block, chunks of the same type MUST be contiguous and ordered: authentication chunks (sd, as, or af) first, then data chunks (nd or ad), then information chunks (vi or oi). At most one variant per category may appear in a single block.
This document registers four IANA entries: URI schemes iris.xpc (TCP) and iris.xpcs (TLS), and corresponding S-NAPTR application protocol labels iris.xpc and iris.xpcs for DDDS-based service discovery of IRIS servers.
Well-known TCP port 713 is registered for IRIS over XPC (iris.xpc) and TCP port 714 for IRIS over XPCS (iris.xpcs).
Clients SHOULD be prepared to support SASL/DIGEST-MD5 and SASL/OTP for user authentication, and TLS with cipher suites TLS_RSA_WITH_3DES_EDE_CBC_SHA and TLS_RSA_WITH_AES_{128,256}_CBC_SHA (with and without client certificates) for encryption and mutual authentication. Anonymous access may be handled via no authentication or SASL/ANONYMOUS.
The SASL service name for IRIS-XPC is "iris-xpc". SASL mechanism negotiation occurs via version information (vi) chunks and may be used both before and after security mechanism installation. To abort an ongoing SASL exchange, clients or servers MUST close the connection.
XPC may be tunneled over TLS (XPCS) by establishing TLS immediately after TCP connection and before any blocks are sent. Server authentication for XPCS follows the convention described in IRIS-BEEP (RFC 3983 Section 6). TLS enables both authentication and confidentiality.
An XPC session has six phases: (1) client establishes TCP connection; (2) server sends CRB; (3) client sends RQB with optional keep-open flag; (4) server responds with RSB indicating whether session stays open; (5) if session continues, repeat from step 3; (6) TCP connection is closed.
Each chunk consists of a 1-octet chunk descriptor, a 2-octet chunk data length, and variable-length chunk data. The chunk descriptor encodes: bit 0 = last chunk (LC), bit 1 = data complete (DC), bits 2–4 = reserved (MUST be 0), bits 5–7 = chunk type (CT).
The block header is a 1-octet field shared by RQB, RSB, and CRB. Bits 0–1 are the version (V) field; bit 2 is the keep-open (KO) flag; bits 3–7 are reserved and MUST be 0.
The Request Block (RQB) layout is: 1-octet header, 1-octet authority length, 0–255 octet authority string, followed by one or more variable-length chunks.
The Response Block (RSB) layout is: 1-octet header followed by one or more variable-length chunks. The Connection Response Block (CRB) uses the same format but is constrained to a single chunk containing either version information (KO=1) or a system-error (KO=0).
The SASL chunk data format is: 1-octet mechanism name length, variable mechanism name, 2-octet mechanism data length, variable mechanism data. All four fields MUST NOT span multiple chunks.