Re: [savi] Last Call: <draft-ietf-savi-dhcp-12.txt> (SAVI Solution for DHCP) to Proposed Standard
eric levy-abegnoli <elevyabe@cisco.com> Thu, 12 April 2012 07:47 UTC
Return-Path: <elevyabe@cisco.com>
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 <elevyabe@cisco.com>
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 <yaoguang.china@gmail.com>
References: <20120306150141.8315.38572.idtracker@ietfa.amsl.com> <4F5F623F.3030907@cisco.com> <CA+=FF_6wzcSHuKG9mYTZgajb5uKC5G0ikXp2e4F3BPPd3U8+Cg@mail.gmail.com>
In-Reply-To: <CA+=FF_6wzcSHuKG9mYTZgajb5uKC5G0ikXp2e4F3BPPd3U8+Cg@mail.gmail.com>
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: <draft-ietf-savi-dhcp-12.txt> (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 <savi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/savi>, <mailto:savi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/savi>
List-Post: <mailto:savi@ietf.org>
List-Help: <mailto:savi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/savi>, <mailto:savi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2012 07:47:10 -0000
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 > >
- [savi] Last Call: <draft-ietf-savi-dhcp-12.txt> (… The IESG
- Re: [savi] Last Call: <draft-ietf-savi-dhcp-12.tx… eric levy-abegnoli
- Re: [savi] Last Call: <draft-ietf-savi-dhcp-12.tx… Guang Yao
- Re: [savi] Last Call: <draft-ietf-savi-dhcp-12.tx… eric levy-abegnoli
- Re: [savi] Last Call: <draft-ietf-savi-dhcp-12.tx… Jun Bi