Security of Messages Exchanged between Servers and Relay Agents
draft-ietf-dhc-relay-server-security-05

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, tomasz.mrugalski@gmail.com, dhc-chairs@ietf.org, draft-ietf-dhc-relay-server-security@ietf.org, suresh.krishnan@gmail.com, Tomek Mrugalski <tomasz.mrugalski@gmail.com>, dhcwg@ietf.org, rfc-editor@rfc-editor.org
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/

Ballot Text

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.

RFC Editor Note