Session Peering Provisioning Framework (SPPF)
Extracted elements (29)
SED Groups provide indirect linking between Public Identifiers and SED Records, significantly improving scalability and manageability. A change to a network node used for multiple routes requires only a single SED Record update rather than millions of individual Public Identifier updates.
SPPF is intentionally agnostic to the substrate protocol, separating the data model (specified via XSD) from the protocol transport. This allows multiple substrates to carry SPPF over time while maintaining a single interoperable data model; SOAP (RFC 7878) is the required initial substrate.
A DRINKS substrate protocol MUST support near real-time responses to requests submitted by the client, in the range of a few multiples of round-trip time between server and client.
A substrate protocol for SPPF MUST allow responses to be correlated with requests and MUST provide a response for each request so that a client can identify whether a request succeeded or failed.
All OrgIdType instances MUST follow the textual convention 'namespace:value' (e.g., 'iana-en:32473'), where namespace conforms to ABNF: ALPHA *(ALPHA/DIGIT/'-').
Delete operations in SPPF MUST be atomic. When an object is deleted, all cross-references to it (e.g., Destination Group membership, SED Group associations, related SED Group Offers) must be automatically removed by the SPPF implementation.
'Name' attributes used as components of object key types MUST be compared using the Unicode toCasefold() function (Section 3.13 of Unicode 6.1 or newer), performing case-insensitive comparisons.
Response types 'Attribute value invalid' and 'Object does not exist' MUST NOT be used interchangeably. 'Object does not exist' MUST be returned for missing preexisting objects identified by valid keys; 'Attribute value invalid' MUST be returned for malformed object identifiers.
SPPF clients and servers MUST accept a UTF-8 BOM if present, though emitting a UTF-8 BOM is NOT RECOMMENDED. UTF-8 is the RECOMMENDED character encoding for use with SPPF; the encoding attribute in the XML declaration is OPTIONAL if UTF-8 is used.
The Registry MUST store creation and modification timestamps for all objects and MUST include cDate and mDate in Get operation responses. If the client passes in date/time values, the Registry MUST ignore them.
The SPPF server MUST provide support for the SOAP-based substrate protocol defined in RFC 7878. To encourage interoperability, this is the required baseline substrate.
The SPPF substrate protocol MUST provide means for an SPPF server to authenticate an SPPF client. A successfully authenticated SPPF client is designated a Registrar.
The substrate protocol MUST provide means for data integrity protection and confidentiality. Compromise of data in-flight between client and Registry would seriously affect system stability and integrity.
Time attribute values in SPPF messages MUST be expressed in UTC format without time-zone digits (e.g., '2010-05-30T09:30:10Z'). Use of an unqualified local time value is disallowed as it can lead to interoperability issues.
Egress Route (EgrRteType) allows an originating SSP to associate a specific egress SBE with a target ingress SBE. Fields: egrRteName, pref (unsignedShort preference for traffic management), regxRewriteRule (regex to rewrite ingress NAPTR), ingrSedGrp (target SED Group keys), and svcs (ENUM services filter).
Public Identifiers come in five concrete types: TNType (single telephone number), RNType (routing number), TNRType (contiguous TN range with startTn/endTn), TNPType (TN prefix), and URIPubIdType (URI). All extend abstract PubIdType and may be members of zero or more Destination Groups or directly associated with SED Records.
SED Group Offer (SedGrpOfferType) controls peering access to SED Groups. Fields: sedGrpOfferKey, status (offered/accepted — server-controlled, client values ignored), offerDateTime, and acceptDateTime. A peer organization's ID is added to the SED Group's peeringOrg list only after offer and acceptance.
SED Group (SedGrpType) links Destination Groups to SED Records and peering organizations. Key fields: sedGrpName, sedRecRef (prioritized SED Record references), dgName (Destination Group names), peeringOrg (organizations with accepted access), sourceIdent (source-based routing criteria), isInSvc (boolean), priority (unsignedShort).
SED Records are defined in three concrete types extending abstract SedRecType: NAPTRType (NAPTR with order, flags, svcs, regx, repl fields), NSType (DNS name server with hostName and ipAddr), and URIType (URI with ere POSIX Extended Regular Expression and uri fields). All include isInSvc boolean and optional ttl in seconds.
Source-based routing in SED Groups uses SourceIdentType with sourceIdentScheme (enumeration: 'uri', 'ip', 'rootDomain') and sourceIdentRegex. The resolution server includes a SED Group's data in responses only if one or more source criteria match characteristics of the resolution request.
SPPF defines eleven mandatory response message types for all substrate protocols: Request succeeded, Request syntax invalid, Request too large, Version not supported, Command invalid, System temporarily unavailable, Unexpected internal error, Attribute value invalid, Object does not exist, and Object status/ownership does not allow operation.
The SPPF data model defines six first-class object types: Organization, Destination Group, Public Identifier, SED Group, SED Record, SED Group Offer, and Egress Route. All first-class objects extend the abstract BasicObjType containing Registrant ID (rant), Registrar ID (rar), and creation/modification timestamps.
This document establishes an IANA Organization Identifier Namespace Registry for SPPF OrgIdType namespace identifiers, tracking prefixes (e.g., 'iana-en' for IANA Enterprise Numbers) used in the mandatory 'namespace:value' convention for Registrant and Registrar IDs.
This document establishes an IANA URN namespace for SPPF XML schemas under the 'ietf' URN namespace (Section 11.1).
Replay attacks on SPPF provisioning operations could result in unauthorized re-creation or deletion of SED objects. The substrate protocol must include replay protection mechanisms to prevent previously captured messages from being resubmitted.
SPPF faces DoS risks both from the substrate layer (e.g., TCP-level attacks on the SOAP transport) and SPPF-specific attacks such as flooding the Registry with large provisioning requests. The 'Request too large' response code provides a mechanism to reject oversized requests.
SPPF implementations must provide confidentiality and authentication via the substrate protocol (e.g., TLS as used in the RFC 7878 SOAP transport). Without these controls, sensitive SED routing data could be intercepted or tampered with in transit.
SPPF servers must implement authorization rules specifying (1) which Registrars are authorized to create/modify/delete each SPPF object type for a given Registrant, and (2) which Registrars are authorized to view/get each type. These rules are mandatory for safe operation but are a matter of local policy.
SED Group Offer has two states: 'offered' (automatically set when a new offer is Added) and 'accepted' (automatically set when the offer is Accepted). Rejection at any point deletes the offer and removes the data recipient's organization ID from the SED Group's peeringOrg list. Offers may be rejected even after prior acceptance.