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@xxxxxxxxhttps://www.ietf.org/mailman/listinfo/savi