From elevyabe@cisco.com Thu Apr 12 00:47:10 2012 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B95D21F853A; Thu, 12 Apr 2012 00:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.398 X-Spam-Level: X-Spam-Status: No, score=-9.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVAHPg2datgj; Thu, 12 Apr 2012 00:47:09 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4816821F84D5; Thu, 12 Apr 2012 00:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=elevyabe@cisco.com; l=17844; q=dns/txt; s=iport; t=1334216828; x=1335426428; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Zn2cbUHiTNq5msTM/T54jozgbQo3mK5AfWFLWjLf2cQ=; b=FjgT0jHHfiUCgZyxG1wfHg/AGBgigadNQX+KXTO7ST7tyyey2oJpFVUp hwsdvgmt8xkbodZOuuYcdFQvFsHoEFFyWVPNudenc4YmV1AmWETsWVnbL 4+zpU4+B9rJuMXYNfNoNbx1W+ypu4mEGpCnD4O3wgkebRwAntiskTrAIF g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAN2Hhk+Q/khL/2dsb2JhbABEuWSBB4IJAQEBBAEBAQ8BVAcKARALGAkWCAcJAwIBAgEVHxEGDQEFAgEBFweHbAuaRqAHiyqGTwSVbIERhGGIW4FpgmmBUwEX X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208,217";a="70643565" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 12 Apr 2012 07:47:07 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3C7l70D015230; Thu, 12 Apr 2012 07:47:07 GMT Received: from xmb-ams-105.cisco.com ([144.254.74.80]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Apr 2012 09:47:06 +0200 Received: from [144.254.53.96] ([144.254.53.96]) by xmb-ams-105.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Apr 2012 09:47:06 +0200 Message-ID: <4F868879.4050102@cisco.com> Date: Thu, 12 Apr 2012 09:47:05 +0200 From: eric levy-abegnoli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Guang Yao References: <20120306150141.8315.38572.idtracker@ietfa.amsl.com> <4F5F623F.3030907@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020307020802090406030307" X-OriginalArrivalTime: 12 Apr 2012 07:47:06.0348 (UTC) FILETIME=[751F52C0:01CD1880] Cc: savi@ietf.org, ietf@ietf.org Subject: Re: [savi] Last Call: (SAVI Solution for DHCP) to Proposed Standard X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 07:47:10 -0000 This is a multi-part message in MIME format. --------------020307020802090406030307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 > > > 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' > 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 mailing lists by > 2012-03-20. Exceptionally, comments may be > sent to 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 > https://www.ietf.org/mailman/listinfo/savi > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > > --------------020307020802090406030307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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>
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 mailing lists by 2012-03-20. Exceptionally, comments may be
sent to 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
https://www.ietf.org/mailman/listinfo/savi


_______________________________________________
savi mailing list
savi@ietf.org
https://www.ietf.org/mailman/listinfo/savi


--------------020307020802090406030307-- From junbi@cernet.edu.cn Thu Apr 12 01:05:30 2012 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3929321F8601; Thu, 12 Apr 2012 01:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.698 X-Spam-Level: X-Spam-Status: No, score=-100.698 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_46=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYU6ZtAe99FR; Thu, 12 Apr 2012 01:05:29 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 258AC21F8604; Thu, 12 Apr 2012 01:05:27 -0700 (PDT) Received: from junbiVAIOz138 (unknown [59.66.24.181]) by centos (Coremail) with SMTP id AQAAf3CrwQboi4ZPG04AAA--.1593S2; Thu, 12 Apr 2012 16:01:50 +0800 (CST) Message-ID: <729F1297F58840BFAD975C8480C18873@junbiVAIOz138> From: "Jun Bi" To: "eric levy-abegnoli" , "Guang Yao" References: <20120306150141.8315.38572.idtracker@ietfa.amsl.com> <4F5F623F.3030907@cisco.com> <4F868879.4050102@cisco.com> In-Reply-To: <4F868879.4050102@cisco.com> Date: Thu, 12 Apr 2012 16:05:08 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_053C_01CD18C6.08439350" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 X-CM-TRANSID: AQAAf3CrwQboi4ZPG04AAA--.1593S2 X-Coremail-Antispam: 1UD129KBjvJXoW3JFy3XFWUZFykWF17Cr4fGrg_yoW7Ww1UpF W3Kr45Gr4kX3WxAwn7Xw40qry0v3s5JFW7AF15Jw1DAa98G3W8tr1Skw4Yv34UJr1fJw4Y qF429r98Jwn3ZFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUgYb7Iv0xC_KF4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr0_ Cr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AKxVWxJr 0_GcWle2I262IYc4CY6c8Ij28IcVAaY2xG8wAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2 z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4x0Y4 8IcxkI7VAKI48G6xCjnVAKz4kxMxkIecxEwVAFwVW8ZwCF04k20xvY0x0EwIxGrwC20s02 6c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF 0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvE c7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2js IE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZF pf9x07jF6wZUUUUU= X-CM-SenderInfo: xmxquxg6fh20lhwovvfxof0/ Cc: savi@ietf.org, ietf@ietf.org Subject: Re: [savi] Last Call: (SAVI Solution for DHCP) to Proposed Standard X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 08:05:30 -0000 这是一封 MIME 格式的多方邮件。 ------=_NextPart_000_053C_01CD18C6.08439350 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable thanks! Jun Bi From: eric levy-abegnoli=20 Sent: Thursday, April 12, 2012 3:47 PM To: Guang Yao=20 Cc: savi@ietf.org ; ietf@ietf.org=20 Subject: Re: [savi] Last Call: (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:=20 Hi, Eric=20 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 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 =3D IRT + RAND*IRT RT for each subsequent message transmission is based on the previous value of RT: RT =3D 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 =3D 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.=20 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.=20 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=20 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' 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 mailing lists by 2012-03-20. Exceptionally, comments = may be sent to 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 https://www.ietf.org/mailman/listinfo/savi _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi -------------------------------------------------------------------------= ------- _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi ------=_NextPart_000_053C_01CD18C6.08439350 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
thanks!
Jun Bi
 
Sent: Thursday, April 12, 2012 3:47 PM
Subject: Re: [savi] Last Call: = <draft-ietf-savi-dhcp-12.txt>=20 (SAVI Solution for DHCP) to Proposed Standard
 
Hi=20 Guang,
I realized I never acknowledged your responses. Sorry for the=20 delay.
It does clear my concerns.
Thank you!
Eric
On = 16/03/12 07:42,=20 Guang Yao wrote:=20 Hi, Eric=20
 
Thank you for the comments. My replies are in the line. We have = updated=20 the text as the attachment. Sorry for it cannot be submitted because = the=20 submit window is closed.
 
Best regards,
Guang
 
2012/3/13 eric levy-abegnoli <elevyabe@cisco.com>
Hi,
here are my substantive comments
Look = for =20 [eric].
Eric

7.3.1. Timer Expiration Event

 =20 EVE_ENTRY_EXPIRE: The lifetime of an entry expires

[eric] 2 = minutes=20 sounds very long. DHCP client timeout is 1 sec for the = first
message.=20 Then multiplied by 2, etc. What is the rational behind this value, = which=20 increase the window for DoS attacks?
[guang]
In RFC3315, it reads:
"RT for the first message=20 transmission is based on IRT:
      RT =3D IRT + RAND*IRT

   RT for each subsequent message transmission is based on the previous
   value of RT:

      RT =3D 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 =3D MRT + = RAND*MRT"
 
Here MRT is 120s. Based on this value, the maximum  = retransmission=20 time is in range of 120s(+-)12s. Thus, we think 120s is a favorable = value to=20 remove an entry.
The DoS in this window is a problem, but we think the binding = number=20 limitation on each binding anchor can mitigate the damage.

8. Supplemental Binding Process
[eric] This = section=20 is very unclear. The conditional SHOULD
  based on  = "vendor=20 ability" sounds like a "MAY" to me, which is not
  what I = remember=20 of the WG consensus. In addition, hosts are not
  required = to (DHCP)=20 re-configure upon link flapping, even when they
  are = directly=20 attached.  The text seems to indicate otherwise.
  In = practice,=20 in the absence of such mechanism, traffic will be=20 blocked.

[guang]
We have removed the condition on "vendor ability" . Link flap is = handled=20 through keeping bindings for a period after binding anchor off-link. = We have=20 changed the text to make it clear.
 
8.1. Binding Recovery Process
[eric] It is = unclear what=20 the address is bound to. In the normal case,
    = the entry=20 is created upon receiving a message (i.e. REQUEST)=20 from
    the client, and the anchor is stored by = that=20 time. You should
    specified where the anchor = comes from=20 in this scenario, and where
    was it stored = (given that=20 the section specifies the binding entry creattion on LQ=20 Reply)
[guang]
We have changed the text, and specified each step. Tell me if it = is still=20 unclear.

10. State Restoration
[eric] Requiring = non-volatile=20 memory sounds wrong. Other techniques
exists such as redundant = boxes=20 (switches) synchronizing states. I
don't recall that non-volatile = memory=20 was discussed at length in the
WG, especially given that it = carries its=20 own challenges: frequency
for saving states, load incurred, = etc)
The=20 one technique that was discussed in the WG was Binding=20 Recovery
process.  One solution should be = enough.
[guang]
There can be a large number of bindings on the savi device. If = only=20 relying on the binding recovery process, there can be a large latency. = Especially, the recovery in this mechanism requires querying the DHCP = server.=20
Moreover, the storing in non-volatile memory is just recommended = but not=20 mandatory. Using redundant box can be  another suggestion. We = have change=20 the MUST to MAY in text.


Eric=20


On 06/03/12 16:01, The IESG wrote:
The IESG has received a request from the Source = Address=20 Validation
Improvements WG (savi) to consider the following=20 document:
- 'SAVI Solution for DHCP'
 =20 <draft-ietf-savi-dhcp-12.txt>  as a Proposed=20 Standard

The IESG plans to make a decision in the next few = weeks,=20 and solicits
final comments on this action. Please send = substantive=20 comments to the
ietf@ietf.org mailing lists by = 2012-03-20.=20 Exceptionally, comments may be
sent to iesg@ietf.org = instead. In either=20 case, please retain the
beginning of the Subject line to allow=20 automated sorting.

Abstract


   This = document=20 specifies the procedure for creating bindings between = a
  =20 DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and=20 a
   binding anchor [I-D.ietf-savi-framework] on SAVI = (Source=20 Address
   Validation Improvements) device. The = bindings can=20 be used to filter
   packets generated on the local = link with=20 forged source IP address.




The file can be = obtained=20 via
http://datatracker.ietf.org/doc/draft-ietf-savi-= dhcp/

IESG=20 discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-savi-= dhcp/ballot/


No=20 IPR declarations have been submitted directly on this=20 = I-D.


_______________________________________________
savi=20 mailing list
savi@ietf.org
https://www.ietf.org/mailman/listinfo/savi

_______________________________________________savi=20 mailing list
savi@ietf.org
https://www.ietf.org/mailman/listinfo/savi
 

_______________________________________________
savi mailing=20 list
savi@ietf.org
https://www.ietf.org/mailman/listinfo/savi
------=_NextPart_000_053C_01CD18C6.08439350-- From internet-drafts@ietf.org Sat Apr 28 04:57:00 2012 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7030221F8684; Sat, 28 Apr 2012 04:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUg0zIMoypug; Sat, 28 Apr 2012 04:57:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06CA621F8669; Sat, 28 Apr 2012 04:57:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120428115700.20905.45943.idtracker@ietfa.amsl.com> Date: Sat, 28 Apr 2012 04:57:00 -0700 Cc: savi@ietf.org Subject: [savi] I-D Action: draft-ietf-savi-mix-02.txt X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 11:57:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Source Address Validation Improvement= s Working Group of the IETF. Title : SAVI for Mixed Address Assignment Methods Scenario Author(s) : Jun Bi Guang Yao Joel M. Halpern Eric Levy-Abegnoli Filename : draft-ietf-savi-mix-02.txt Pages : 9 Date : 2012-04-28 This document reviews how multiple address discovery methods can coexist in a single SAVI device and collisions are resolved when the same binding entry is discovered by two or more methods. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-savi-mix-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-savi-mix-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-savi-mix/