Host Identity Protocol (HIP) Registration Extension
obsoletes
- rfc-5203 — Host Identity Protocol (HIP) Registration Extension
Extracted elements (29)
Lifetime values are encoded as exponents (2^((lifetime-64)/8) seconds) rather than absolute values so that 255 distinct durations spanning milliseconds to months can be compactly represented in a single 8-bit field.
The baseline minimum of 10 seconds and recommended maximum of 120 seconds were chosen to accommodate existing state timeouts in middleboxes such as NATs and firewalls, ensuring registrations survive typical infrastructure constraints.
REG_REQUEST MUST NOT be included in I2 or UPDATE unless the registrar's most recent R1 or UPDATE contained a REG_INFO listing the requested registration types, preventing requests for services the registrar has not advertised.
A registrar SHOULD include REG_INFO in all R1 packets to announce capabilities; if temporarily unable to provide services, it SHOULD include an empty REG_INFO with no service types listed.
A registrar SHOULD support HIP certificates (RFC 8002) to allow certificate-based authentication for requesters whose Host Identities are not preconfigured in the registrar's allowed list.
A requester SHOULD send REG_REQUEST in the I2 packet (earliest opportunity) to minimize the number of round-trips required to complete registration with a registrar.
Non-zero lifetime field values MUST be interpreted as an exponent representing a duration of 2^((lifetime - 64)/8) seconds, covering a range from approximately 4 ms to 178 days in an 8-bit integer.
The minimum lifetime that both registrars and requesters MUST support is 10 seconds; they SHOULD support a maximum lifetime of at least 120 seconds.
The requester MUST be prepared to receive any registration lifetime in REG_RESPONSE, including values outside the min/max range announced in REG_INFO, and MUST NOT expect the returned lifetime to match the requested one.
The requester MUST NOT include more than one REG_REQUEST parameter in its I2 or UPDATE packets, while the registrar MUST be able to process one or more REG_REQUEST parameters in received I2 or UPDATE packets.
The special lifetime value 0 (zero) MUST be interpreted as a lifetime duration of 0 seconds and is used exclusively to request and grant cancellation of a registration.
Upon receiving Failure Type 2 (insufficient resources), the requester MUST NOT reattempt registration for the same services immediately and MAY try a different registrar.
Upon receiving Failure Type 3 (invalid certificate), the requester MUST NOT reattempt registration for the same set of services with the same certificate, but MAY try with a different certificate or a different service set.
When a REG_REQUEST in an UPDATE packet is received, the registrar MUST NOT modify the registrations of types not listed in the parameter, ensuring that only explicitly requested registration types are affected.
When a registrar requires authentication, it MUST first check if the requester's Host Identity is in the allowed list; if not, it MUST check for a CERT parameter and MUST reject requests lacking credentials with Failure Type 0.
REG_FAILED (Type 936) is a variable-length HIP parameter sent by the registrar in R2 or UPDATE packets to communicate which registration types failed and the reason, encoded as an 8-bit Failure Type field followed by the affected registration type identifiers.
REG_INFO (Type 930) is a variable-length HIP parameter used by a registrar to announce its registration capabilities, including the minimum and maximum registration lifetimes it is willing to grant and the list of registration types it offers.
REG_REQUEST (Type 932) is a variable-length HIP parameter sent by a requester in an I2 or UPDATE packet to request registration for one or more service types, including a requested lifetime and an ordered list of registration type identifiers.
REG_RESPONSE (Type 934) is a variable-length HIP parameter sent by the registrar in R2 or UPDATE packets to indicate the registration types for which registration has been successfully granted, along with the granted lifetime.
The REG_REQUIRED NOTIFY error (type 51) may be sent by a registrar in the R2 packet to reject a HIP association that carries no REG_REQUEST, preventing association establishment when registration is required.
The 'Parameter Types' subregistry under 'Host Identity Protocol (HIP) Parameters' is updated: REG_INFO (930), REG_REQUEST (932), REG_RESPONSE (934), and REG_FAILED (936) now reference RFC 8003 instead of RFC 5203.
The 'Registration Failure Types' subregistry is updated: values 2 (insufficient resources), 3 (invalid certificate), 4 (bad certificate), 5 (unsupported certificate), 6 (certificate expired), 7 (certificate other), and 8 (unknown CA) are added; 201-255 remain reserved for private use.
The 'Registration Types' subregistry under 'Host Identity Protocol (HIP) Parameters' reserves values 201-255 for private use; all new types require IETF specifications. RFC 8003 replaces RFC 5203 as the reference.
The registration extension relies entirely on HIP base exchange security (digital signatures, HMAC) and does not modify those properties. The only new threat is the creation of soft, time-limited registration state at the registrar, which registrars can cancel at any time to mitigate resource exhaustion.
Registration state is created at the requester upon successful processing of REG_RESPONSE, and at the registrar (and optionally the service) upon successful processing of REG_REQUEST. Either party may cancel state before expiry; the registrar SHOULD notify registered requesters with a zero-lifetime REG_RESPONSE if it cancels.
REG_FAILED encodes: Type (16-bit, value 936), Length (16-bit), Failure Type (8-bit), followed by a variable-length list of 8-bit Reg Type values that failed for the given reason, padded to a 32-bit boundary.
REG_INFO encodes: Type (16-bit, value 930), Length (16-bit), Min Lifetime (8-bit exponent), Max Lifetime (8-bit exponent), followed by a variable-length list of 8-bit Reg Type values and padding to a 32-bit boundary.
REG_REQUEST encodes: Type (16-bit, value 932), Length (16-bit), Lifetime (8-bit exponent), followed by a variable-length list of 8-bit Reg Type values in preference order, padded to a 32-bit boundary.
REG_RESPONSE encodes: Type (16-bit, value 934), Length (16-bit), Lifetime (8-bit exponent), followed by a variable-length list of granted 8-bit Reg Type values, padded to a 32-bit boundary.