Last Call Review of draft-ietf-dhc-relay-port-06
review-ietf-dhc-relay-port-06-secdir-lc-kelly-2017-10-26-00

Request Review of draft-ietf-dhc-relay-port
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-10-24
Requested 2017-10-10
Other Reviews Intdir Early review of -05 by Ralf Weber (diff)
Opsdir Last Call review of -07 by Victor Kuarsingh
Genart Last Call review of -06 by Francis Dupont (diff)
Review State Completed
Reviewer Scott Kelly
Review review-ietf-dhc-relay-port-06-secdir-lc-kelly-2017-10-26
Posted at https://mailarchive.ietf.org/arch/msg/secdir/-HWV0d6UhSbSFermXaOYXn9r3KY
Reviewed rev. 06 (document currently at 07)
Review result Has Nits
Draft last updated 2017-10-26
Review closed: 2017-10-26

Review
review-ietf-dhc-relay-port-06-secdir-lc-kelly-2017-10-26

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

The summary of the review is "ready" with minor editorial nits.

From the abstract, this document proposes an extension to the DHCP protocols that allows a (DHCP) relay agent to receive packets from a server or an upstream relay agent on any UDP port, not just the default port 67 for IPv4 or default port 547 for IPv6.

Paraphrasing, it allows a relay agent to use any available source port for upstream communications, and to include a DHCP option that can be used to statelessly route responses back to the appropriate source port on downstream communications.

The security considerations section references [RFC3118] and [RFC3315], and adds that any firewalls in the path may need reconfiguration to allow DHCP flows from non-fixed addresses. I don't have anything to add, though I think that section could benefit from a little word-smithing. I'll defer to the RFC editor on that. 

The draft is clear, though a simple ascii diagram illustrating a client, relay, and server (including src/dst ports) might help readers to more immediately understand what this looks like topologically. I read it through, and then went back and drew myself a picture as I read, and that helped. Just a thought.

One minor (non-security) question I had: section 6 illustrates a cascaded IPv6 example wherein Relay1 is using a non-standard port, but Relay2 is not. What happens if both Relay1 and Relay2 are using non-standard source ports? Is this allowed? If not, you might want to call this out. If so, it might be good to describe a general case of n relays with m non-standard source ports.

--Scott