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

eric levy-abegnoli <> Tue, 13 March 2012 15:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3BC2C21F886B; Tue, 13 Mar 2012 08:05:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y8bSj9-M2hvt; Tue, 13 Mar 2012 08:05:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2C25721F886A; Tue, 13 Mar 2012 08:05:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3122; q=dns/txt; s=iport; t=1331651139; x=1332860739; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=CCYv3DmWqCOKt0gkbeSOHJxx0KnWVx9DX9xUA7cyqnc=; b=hQDTDA1W3wG5io2bA6t7+pYZ2EyJfS7t3QQssgTvLX/VJ2vZVJmmGuSM riznQW4aIjDAVk8SWtRLfpeAwwlJzzszw351hjYZZQx5exG1soEc48c7C ZAzWe+IsO0DFOgcVQ6IiQrrZ5EwFT0K17+W+iSufDAn8aCoTk4PdzgN+n 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.73,577,1325462400"; d="scan'208";a="132187796"
Received: from ([]) by with ESMTP; 13 Mar 2012 15:05:37 +0000
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id q2DF5bY4024863; Tue, 13 Mar 2012 15:05:37 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Mar 2012 16:05:37 +0100
Received: from [] ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Mar 2012 16:05:37 +0100
Message-ID: <>
Date: Tue, 13 Mar 2012 16:05:35 +0100
From: eric levy-abegnoli <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20120216 Thunderbird/3.1.19
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 Mar 2012 15:05:37.0071 (UTC) FILETIME=[BF248BF0:01CD012A]
Subject: Re: [savi] Last Call: <draft-ietf-savi-dhcp-12.txt> (SAVI Solution for DHCP) to Proposed Standard
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: Tue, 13 Mar 2012 15:05:40 -0000

here are my substantive comments
Look for  [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 
message. Then multiplied by 2, etc. What is the rational behind this 
value, which increase the window for DoS attacks?

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.

   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)

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.


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
> mailing lists by 2012-03-20. Exceptionally, comments may be
> sent to 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
> IESG discussion can be tracked via
> No IPR declarations have been submitted directly on this I-D.
> _______________________________________________
> savi mailing list