Summary

  • RFC 3495 made DHCP option 122 a pre-authentication routing surface: it could name permitted DHCP servers, the provisioning server, the Kerberos realm and the retry and deadline policy that governed an MTA’s next steps.
  • A later valid-certificate requirement could prevent service enablement at a hostile destination, but it could not authenticate the earlier DHCP selector, recover customer choice or erase the network and validation work already consumed.

Kerberos is often described as the judge in a ticket system. The client finds an authentication service, proves a credential, receives a ticket-granting ticket and later asks for a service ticket. RFC 3495 exposed an earlier question: who tells a new client which court to approach? For a PacketCable Media Terminal Adapter, the answer could arrive in the CableLabs Client Configuration option of DHCP, before any KDC had evaluated anything.

The setting was cable telephony. A cable modem carried data access, while an MTA supplied the media and signalling functions needed for voice. The two could share a box, but they remained distinct IP devices with separate MAC and IP configuration. They could also answer to different commercial authorities. A Data Access Provider configured the modem; a Telephony Service Provider configured the MTA.

RFC 3495 therefore described more than a packet format. The entity controlling modem configuration could determine which business entities were allowed to configure the MTA. The document compared that position with a local carrier influencing the long-distance carrier available to a customer. A DHCP option sat at the boundary between network admission and commercial delegation.

IANA assigned code 122 to CableLabs Client Configuration. Inside it, tagged and length-delimited sub-options carried primary and secondary TSP DHCP-server addresses, a provisioning-server address, a Kerberos realm, rules for using a ticket-granting server, AS and AP retry parameters, and a provisioning timer. The earlier site-specific code 177 was deprecated. If the option grew beyond 255 octets, RFC 3396 supplied the concatenation rule.

These fields were precise without being proofs. An IPv4 value occupied four octets in network byte order. A provisioning FQDN used RFC 1035 encoding, ended with zero and could not use DNS compression. The realm was represented as an upper-case domain-style name. Correct bytes established that a value could be parsed. They did not establish that the host existed, that DNS answered honestly, that a KDC would accept the device or that a telephone call would ever complete.

The direction of delivery matters. CableLabs clients used the parameter request list and a vendor-class identifier to ask for the configuration. The server chose which sub-options to populate under the project specifications. Clients did not populate option 122 in their requests. Seeing a realm in a trace is thus a receipt for what a responding configuration authority supplied, not proof that the device independently selected or authenticated the provider behind it.

RFC 3495 named the resulting dangers unusually plainly. Incorrect DHCP-server or provisioning-server addresses could deny service or send traffic to a snooper. A false realm could direct an MTA toward the wrong KDC. A malicious TSP might alter the designation to take a customer from the TSP that customer selected. The same syntax could support necessary provisioning or a commercial redirection.

The mitigations belonged to several owners. A CMTS was expected to forward requests only to explicitly configured DHCP servers and to allow downstream traffic only from approved address ranges. Those are operator-controlled conditions, not properties carried in option 122. “Correctly configured CMTS” is a premise that needs its own configuration and traffic evidence.

Later authentication supplied another boundary. Even after spoofed addresses or a false realm led the MTA to a KDC, the device had to present valid certificates before being service-enabled. That could stop an uncertified destination. Yet validation itself cost computation, so repeated attempts could become denial of service. A rejected certificate proved that the later gate rejected a credential; it did not prove that the earlier realm or route had been authentic.

Nor did a valid certificate settle the commercial question. The RFC contemplated a malicious but certified TSP and assumed that providers admitted to the access network would coexist peacefully. Customer redirection was left to administration between the access provider and the TSP. Cryptography could authenticate an admitted credential while the customer’s choice was still wrong.

Retry policy multiplied the distinction. The option separately configured initial timeout, maximum timeout and retry count for the AS exchange and for the AP exchange. It also set a maximum provisioning time; expiry reset the timer and restarted provisioning from the beginning. A bad destination could therefore attract several rounds of traffic and certificate work. A zero timer disabled that outer deadline; it did not certify completion.

This is different from adjacent DHCP history. RFC 3361 concerned discovery of SIP-server candidates. RFC 3396 concerned reconstruction of a long option from fragments. RFC 3397 concerned a domain-search list. RFC 3442 concerned classless routes. RFC 3495’s distinctive contribution was to put the realm, endpoints and timing of a later authentication process into a configuration channel that preceded it.

The durable receipt chain is longer than the word “authenticated”: option bytes received; sub-options parsed; realm and endpoint selected; name resolved and route found; KDC contacted; certificate and Kerberos exchange accepted; service ticket acquired; provisioning finished before the deadline; the customer-authorized TSP retained; telephony delivered. No rung silently proves the next.

Sources