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

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