2012/3/13 eric levy-abegnoli
<elevyabe@xxxxxxxxx>
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?
[guang]
In RFC3315, it reads:
"RT for the first
message transmission is based on IRT:
RT = IRT + RAND*IRT
RT for each subsequent message transmission is based on the previous
value of RT:
RT = 2*RTprev + RAND*RTprev
MRT specifies an upper bound on the value of RT (disregarding the
randomization added by the use of RAND). If MRT has a value of 0,
there is no upper limit on the value of RT. Otherwise:
if (RT > MRT)
RT = MRT +
RAND*MRT"
Here MRT is 120s. Based on this value, the maximum
retransmission time is in range of 120s(+-)12s. Thus, we
think 120s is a favorable value to remove an entry.
The DoS in this window is a problem, but we think the
binding number limitation on each binding anchor can
mitigate the damage.
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.
[guang]
We have removed the condition on "vendor ability" .
Link flap is handled through keeping bindings for a period
after binding anchor off-link. We have changed the text to
make it clear.
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)
[guang]
We have changed the text, and specified each step. Tell
me if it is still unclear.
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.
[guang]
There can be a large number of bindings on the savi
device. If only relying on the binding recovery process,
there can be a large latency. Especially, the recovery in
this mechanism requires querying the DHCP server.
Moreover, the storing in non-volatile memory is just
recommended but not mandatory. Using redundant box can
be another suggestion. We have change the MUST to MAY in
text.
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@xxxxxxxx
mailing lists by 2012-03-20. Exceptionally, comments
may be
sent to iesg@xxxxxxxx
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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/savi
_______________________________________________
savi mailing list
savi@xxxxxxxx
https://www.ietf.org/mailman/listinfo/savi