Last Call Review of draft-ietf-dhc-dhcpv6-active-leasequery-03
review-ietf-dhc-dhcpv6-active-leasequery-03-opsdir-lc-bradner-2015-07-13-00

I was asked to do a OPSDIR review of  draft-ietf-dhc-dhcpv6-active-leasequery-03

summary: needs work in the security considerations section

I can't say that I like the paradigm of enabling multiple systems requests
update streams from a server - it would seem to be more secure and more
manageable to have a push model where the server is configured to stream to
selected locations - but it seems like that train has left the station.

It does not feel right to have a mechanism that enables anyone without
restriction to get a history of the configurations of a particular node on a
network - I do not come up with specific attacks that might be enabled from
such information but it just does not seem like a good idea.

Both RFC 5007 and this ID play short shrift to discussing restricting this
function to selected requestors - for example, this ID says:

   We recommend that servers offer configuration to limit the sources of
   incoming connections, that they limit the number of accepted connections,
   and that they limit the period of time during which an idle connection will
   be left open.

For what its worth the above does not actually make sense - maybe the work
"options" is missing after the word “configuration"

This is very off hand - it would seem to me that a far more detailed discussion
of these issues would be helpful- for example, I would think that the
recommendation should be that default out-of-the-box configuration would be to
refuse all requestors and to offer configuration options to enable specific
requestors.

I note that neither RFC 5007 nor this ID say what the server should use in a
configuration option to limit the requestors - IP address maybe - but that
would be an issue with autoconfig addresses.

Scott