Hi,
here are my substantive comments
Look for [eric].
Eric
7.3.1. Timer Expiration Event
EVE_ENTRY_EXPIRE: The lifetime of an entry expires
[eric] 2 minutes sounds very long. DHCP client timeout is 1 sec for the
first
message. Then multiplied by 2, etc. What is the rational behind this
value, which increase the window for DoS attacks?
8. Supplemental Binding Process
[eric] This section is very unclear. The conditional SHOULD
based on "vendor ability" sounds like a "MAY" to me, which is not
what I remember of the WG consensus. In addition, hosts are not
required to (DHCP) re-configure upon link flapping, even when they
are directly attached. The text seems to indicate otherwise.
In practice, in the absence of such mechanism, traffic will be blocked.
8.1. Binding Recovery Process
[eric] It is unclear what the address is bound to. In the normal case,
the entry is created upon receiving a message (i.e. REQUEST) from
the client, and the anchor is stored by that time. You should
specified where the anchor comes from in this scenario, and where
was it stored (given that the section specifies the binding entry
creattion on LQ Reply)
10. State Restoration
[eric] Requiring non-volatile memory sounds wrong. Other techniques
exists such as redundant boxes (switches) synchronizing states. I
don't recall that non-volatile memory was discussed at length in the
WG, especially given that it carries its own challenges: frequency
for saving states, load incurred, etc)
The one technique that was discussed in the WG was Binding Recovery
process. One solution should be enough.
Eric
On 06/03/12 16:01, The IESG wrote:
The IESG has received a request from the Source Address Validation
Improvements WG (savi) to consider the following document:
- 'SAVI Solution for DHCP'
<draft-ietf-savi-dhcp-12.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2012-03-20. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
This document specifies the procedure for creating bindings between a
DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and a
binding anchor [I-D.ietf-savi-framework] on SAVI (Source Address
Validation Improvements) device. The bindings can be used to filter
packets generated on the local link with forged source IP address.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-savi-dhcp/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-savi-dhcp/ballot/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
savi mailing list
savi(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/savi
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf