Re: [savi] Last Call: <draft-ietf-savi-dhcp-12.txt> (SAVI Solution for DHCP) to Proposed Standard

Hi Guang,
I realized I never acknowledged your responses. Sorry for the delay.
  It does clear my concerns.
Thank you!
Eric
On 16/03/12 07:42, Guang Yao wrote:
> Hi, Eric
>
> Thank you for the comments. My replies are in the line. We have 
> updated the text as the attachment. Sorry for it cannot be submitted 
> because the submit window is closed.
>
> Best regards,
> Guang
>
> 2012/3/13 eric levy-abegnoli <elevyabe@cisco.com 
> <mailto:elevyabe@cisco.com>>
>
>     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@ietf.org <mailto:ietf@ietf.org> mailing lists by
>         2012-03-20. Exceptionally, comments may be
>         sent to iesg@ietf.org <mailto:iesg@ietf.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@ietf.org <mailto:savi@ietf.org>
>         https://www.ietf.org/mailman/listinfo/savi
>
>
>     _______________________________________________
>     savi mailing list
>     savi@ietf.org <mailto:savi@ietf.org>
>     https://www.ietf.org/mailman/listinfo/savi
>
>