[dhcwg] Methods of protecting DHCP relay-agent information options

This is the summary I promised in Atlanta.

Two methods to protect the contents of the relay-agent information option (RAIO) have been proposed: (1) encapsulating the DHCP message in IPsec (RA-IPsec) [draft-droms-dhcp-relay-agent-ipsec-00.txt] and (2) including a message authentication sub-option (AuthSO) [draft-ietf-dhc-auth-suboption-01.txt] similar to the authentication option for protecting options between clients and servers [RFC 3118]. Which method is suitable depends on different circumstances.

Both methods employ keyed message authentication codes, and require distribution of key material. Both methods must also support the separate insertion of RAIO by a "trusted" device closer to the client and GIADDR by a subsequent relay agent, specified in section 2.1 of RFC 3046. AuthSO accommodates this separation the same way that RFC 3118 does, by excluding mutable fields from the integrity computation. Because RA-IPsec necessarily covers the entire message, it must establish IPsec security associations (SA) between each pair of relay agents in the path as well as the SA between the last relay agent and the DHC server. In circumstances where the deployment of DHCP involves this separation of relay-agent function, the RA-IPsec method would entail more configuration of these SAs than the equivalent key management for AuthSO.

In circumstances where the "trusted" device requires protection for RAIO, and does not already have the machinery for IPsec Encapsulating Security Payload the AuthSO method might entail less implementation than RA-IPsec. Where IPsec is already in all relay agents, the IPsec method would avoid implementing AuthSO.

IPsec is based on existing protocols and technology, and can leverage key distribution mechanisms and other future improvements.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg