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

From: eric levy-abegnoli <[email-masked]>
Date: Thu, 12 Apr 2012 09:47:05 +0200

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 <[email-masked] 
> <mailto:[email-masked]>>
>
>     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
>         [email-masked] <mailto:[email-masked]> mailing lists by
>         2012-03-20. Exceptionally, comments may be
>         sent to [email-masked] <mailto:[email-masked]> 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
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/listinfo/savi
>
>
>     _______________________________________________
>     savi mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/savi
>
>

---

From: "Jun Bi" <[email-masked]>
Date: Thu, 12 Apr 2012 16:05:08 +0800

thanks!
Jun Bi

From: eric levy-abegnoli 
Sent: Thursday, April 12, 2012 3:47 PM
To: Guang Yao 
Cc: [email-masked] ; [email-masked] 
Subject: Re: [savi] Last Call: <draft-ietf-savi-dhcp-12.txt> (SAVI Solution for DHCP) to Proposed Standard

Hi Guang,

  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 <[email-masked]>

    Hi,

    [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:

      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.

      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.

        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 

      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
      [email-masked] mailing lists by 2012-03-20. Exceptionally, comments may be
      sent to [email-masked] 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.

      [email-masked]

    [email-masked]

--------------------------------------------------------------------------------
_______________________________________________
savi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/savi