Re: [dhcwg] Alissa Cooper's No Objection on draft-ietf-dhc-rfc3315bis-10: (with COMMENT)

[Tomek Mrugalski <[e-mail]>]

On 01/23/18 16:56, Alissa Cooper wrote:
> Alissa Cooper has entered the following ballot position for
> draft-ietf-dhc-rfc3315bis-10: No Objection

Alissa,
Thank you for your review and your favourable ballot. See my comments below.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Many thanks to the Gen-ART reviewer for a thorough review. It sounds like the
> authors plan to incorporate edits in response but I wanted to particularly call
> out these bits from his summary with which I agree:
> 
> "I also found that the new document did not do a good job on the interactions
> between relay-agents and servers.  Particularly on the processing of options
> between relays and servers and details of reception of Relay-forward messages a
> little more detail would help naive readers.
Understood. How about adding a new Section 19.4 "Interaction between
relay agents and servers" with the following text. The text is a bit
long, but I believe it covers the topic adequately without going into
too much detail and should be easy enough to follow even by naive readers.

Each time a packet is relayed by a Relay Agent towards a server, a new
encapsulation level is added around the packet. Each relay is allowed to
insert additional options on the encapsulation level it added. If there
are multiple relays between a client and a server, multiple
encapsulations are used. Although it makes packet processing
slightly more complex, it has a big advantage of having clear indication
which relay inserted a given option. The response packet is expected to
travel through the same relays, but in reverse order. Each time a
response packet is relayed, one encapsulation level is removed.

In certain cases relays insert additional options. These options can be
inserted for several reasons. First, relays can insert additional
information about the client or how it is connected. That is usually
more trusted by a server administrator as it comes from a network
infrastructure rather then the client himself and cannot be easily
spoofed. These options can be used by the server to determine its
allocation policy.

Second, relay may need some information to send a response back to the
client. Relay agents are expected to be stateless (not retain any state
after a packet has been processed). Relay agent may include an option,
send it to the server and ask the server to echo the option back in the
response. This option will be then used by the relay agent to send the
response back. The client will never see this option. See RFC4994 for
details.

Third, sometimes a relay is the best device to provide values for
certain options. A relay can insert an option to the client packet being
forward and ask the server to pass that option back to the client. The
client will receive that option. See RFC6422 for details.

Servers may want to retain the relay information after the packet
processing is completed for various reasons. One is a bulk leasequery
mechanism that may ask for all addresses and/or prefixes that were
assigned via specific relay. Second reason is reconfigure mechanism. The
server may chose to not send the Reconfigure message directly to the
client, but rather send it via relays. This particular behavior is
considered an implementation details and is out of scope for this document.

> Finally the draft has not made much of an effort to
> support possible alternative security algorithms - IETF policy now encourages
> protocols to deal with algorithm flexibility  - DHCPv6 as it stands is pretty
> thoroughly wedded to HMAC-MD5 and would need some (relatively small) IANA
> improvements plus some thought to cope with different algorithms."
Although getting an algorithm flexibility would be nice, it was never
the goal of this work. Our understanding was that publishing 3315bis
intends to provide cleaner, easier to read somewhat unified text, but
not introduce any new features. If we added this new feature, we'd soon
be dealing with a flood of new proposals.

It is worth mentioning that our hope was the draft-ietf-dhc-sedhcpv6
draft would move forward and solve algorithm flexibility (among many
other security issues), but sadly our hopes were proven futile. The WG
ran out of steam, is no longer able to move forward and the draft is
pretty much dead.

Thanks again for your review,
Tomek