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

Request Review of draft-ietf-dhc-dhcpv6-active-leasequery
Requested rev. no specific revision (document currently at 04)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-07-07
Requested 2015-06-23
Authors Dushyant Raghuvanshi, Kim Kinnear, Deepak Kukrety
Draft last updated 2015-07-13
Completed reviews Genart Last Call review of -03 by Francis Dupont (diff)
Opsdir Last Call review of -03 by Scott Bradner (diff)
Assignment Reviewer Scott Bradner
State Completed
Review review-ietf-dhc-dhcpv6-active-leasequery-03-opsdir-lc-bradner-2015-07-13
Reviewed rev. 03 (document currently at 04)
Review result Has Issues
Review completed: 2015-07-13

Review
review-ietf-dhc-dhcpv6-active-leasequery-03-opsdir-lc-bradner-2015-07-13

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