Security of Messages Exchanged between Servers and Relay Agents
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: The IESG <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Tomek Mrugalski <email@example.com>, firstname.lastname@example.org, email@example.com Subject: Protocol Action: 'Security of Messages Exchanged Between Servers and Relay Agents' to Proposed Standard (draft-ietf-dhc-relay-server-security-05.txt) The IESG has approved the following document: - 'Security of Messages Exchanged Between Servers and Relay Agents' (draft-ietf-dhc-relay-server-security-05.txt) as Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Suresh Krishnan and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-server-security/
Technical Summary DHCPv4 has no guidance for how to secure messages exchanged between servers and relay agents. The DHCPv6 states that IPsec should be used to secure messages exchanged between servers and relay agents, but does not require encryption. And, with recent concerns about pervasive monitoring and other attacks, it is appropriate to require securing relay to relay and relay to server communication for DHCPv4 and DHCPv6. This draft codifies how to use IPsec with encryption to secure that communication. Working Group Summary This draft was created as a result of a concern raised by during IESG review of draft-ietf-dhc-access-network-identifier (https:// mailarchive.ietf.org/arch/msg/dhcwg/17b2yzdJOS1hif95kRIQXidudI8). The issue was the DHCP options could reveal user identifying information when a client communicates with a server via relay(s). This was a generic DHCP issue, so the decision was made to write a separate draft. Using IPsec for that purpose seems to be an obvious choice and that is what the draft proposes. This draft was first presented in Buenos Aires (April 2016) and later in Berlin (July 2016) and got unanimous support in the room on both occasions. It was adopted in Sep. 2016. The draft is very short (a bit over 2 pages of actual content) and changed very little between its first individual revision and the rev that passed WGLC. That is understandable, as it codifies the obvious solution implied by RFC3315 and was written by two experienced engineers (one of them being DHC co-chair). This is also the reason why this draft received fewer comments than average. There were a large number of messages related to this draft posted to DHC list and a handful more circulated off the list. Document Quality This document is of high quality. The reviews it received may seem like not too thorough, but that's because of the draft's shortness and a high quality of its initial version. The document shepherd reviewed -01 version of this draft had some minor comments. They were addressed in -02. Personnel Tomek Mrugalski is the document shepherd. Suresh Krishnan is the responsible AD.