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 revision | 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 | |
I-D 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 O. Bradner (diff) |
|
Assignment | Reviewer | Scott O. Bradner |
State | Completed | |
Request | Last Call review on draft-ietf-dhc-dhcpv6-active-leasequery by Ops Directorate Assigned | |
Reviewed revision | 03 (document currently at 04) | |
Result | Has issues | |
Completed | 2015-07-13 |
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