From nobody Fri Jul 4 12:46:09 2014 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FCB1B2F17; Fri, 4 Jul 2014 12:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtVuNpW_RfrU; Fri, 4 Jul 2014 12:46:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 183B01B2F3D; Fri, 4 Jul 2014 12:45:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704194556.32082.33994.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 12:45:56 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/savi/7Dd5y3apAISM8pv7lQ6kqGwfjrE Cc: savi@ietf.org Subject: [savi] I-D Action: draft-ietf-savi-dhcp-28.txt X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 04 Jul 2014 19:46:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Address Validation Improvements Working Group of the IETF. Title : SAVI Solution for DHCP Authors : Jun Bi Jianping Wu Guang Yao Fred Baker Filename : draft-ietf-savi-dhcp-28.txt Pages : 44 Date : 2014-07-04 Abstract: This document specifies the procedure for creating a binding between a DHCPv4/DHCPv6 assigned IP address and a binding anchor on a SAVI (Source Address Validation Improvements) device. The bindings set up by this procedure is used to filter out packets with forged source IP address in DHCP scenario. This mechanism is proposed as a complement to ingress filtering to provide finer-grained source IP address validation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-savi-dhcp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-savi-dhcp-28 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-savi-dhcp-28 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 17 08:43:15 2014 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BED91A077E for ; Wed, 7 May 2014 07:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhI1NskiiGzD for ; Wed, 7 May 2014 07:30:53 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id DF6C11A0779 for ; Wed, 7 May 2014 07:30:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 0E2A72199C; Wed, 7 May 2014 07:30:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [190.112.55.105]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 2EE6721998; Wed, 7 May 2014 07:30:49 -0700 (PDT) Message-ID: <536A4398.6070102@joelhalpern.com> From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Leaf Yeh , "'Joel M. Halpern'" , 'SAVI Mailing List' , 'marcelo bagnulo braun' , "'Eric Levy- Abegnoli (elevyabe)'" References: <536846e7.637a420a.27dc.02df@mx.google.com> <5368508C.9060205@joelhalpern.com> <53685d07.8564420a.3494.3c0a@mx.google.com> <5368EB4D.7000704@joelhalpern.com> <5369a6d9.838f440a.7e55.1450@mx.google.com> In-Reply-To: <5369a6d9.838f440a.7e55.1450@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/savi/jHNg_BhtM4Mybw8en6VX1ioaj6k X-Mailman-Approved-At: Thu, 17 Jul 2014 08:43:14 -0700 Subject: Re: [savi] RFC6620 Page 15 - Data Trigger X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 07 May 2014 14:30:55 -0000 X-Original-Date: Wed, 07 May 2014 10:30:48 -0400 X-List-Received-Date: Wed, 07 May 2014 14:30:55 -0000 With regard to protecting hosts from "on-link" attackers, there are two different cases. If the SAVI function is on the device with a dedicated port to the end device (or an authenticated port) then there is no value in sending the NS back to the entity which sent it. (Some of this is conceptually buried in the definition of binding scopes in SAVI, and can be hard to realize.) In the case where the SAVI function is upstream of the usage port (for example, it is on the router port, with bridges / switches between the prot and the users) there are many weaknesses in SAVI efficacy. That is clearly stated in the documents. Sending the NS back on that port will not as far as I can tell help resolve much, if any, of those weaknesses. We did discuss this extensively in the working group. Yours, Joel On 5/6/14, 11:21 PM, Leaf Yeh wrote: > Joel - The goal of SAVI is very specific. it is to prevent one node from > claiming an address that is belongs to (by assignment or proper > claiming) another node. Can you please restate your concern with the data > trigger in terms of how it fails to meet that goal?.... > Sending solicitations back onto that LAN (which seems to be what you are > asking for) does not actually help with that problem. > > I guess your logic sounds right. DAD_NS should sent through the TP, which > may connect to other SAVI device (and more hosts) within the same scope, > i.e. the same link, or the same broadcast domain. But the above logic sounds > not cover my concern on the host to abuse the source address within the > on-link prefix. > > Sending DAD_NS back to the VP receiving the data trigger, sounds useful for > a check. Wrong or harmful? > > > Best Regards, > Leaf > > From nobody Mon Jul 21 20:57:04 2014 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B9D1A03AD; Mon, 21 Jul 2014 20:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jl8fH8gu3bmr; Mon, 21 Jul 2014 20:56:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 727F81A03C7; Mon, 21 Jul 2014 20:56:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140722035658.10316.4542.idtracker@ietfa.amsl.com> Date: Mon, 21 Jul 2014 20:56:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/savi/4klhC3CBzAh-3JfpCTJrkEdcY6A Cc: savi@ietf.org Subject: [savi] I-D Action: draft-ietf-savi-dhcp-29.txt X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2014 03:57:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Address Validation Improvements Working Group of the IETF. Title : SAVI Solution for DHCP Authors : Jun Bi Jianping Wu Guang Yao Fred Baker Filename : draft-ietf-savi-dhcp-29.txt Pages : 44 Date : 2014-07-21 Abstract: This document specifies the procedure for creating a binding between a DHCPv4/DHCPv6 assigned IP address and a binding anchor on a SAVI (Source Address Validation Improvements) device. The bindings set up by this procedure is used to filter out packets with forged source IP address in DHCP scenario. This mechanism is proposed as a complement to ingress filtering to provide finer-grained source IP address validation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-savi-dhcp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-savi-dhcp-29 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-savi-dhcp-29 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 22 15:05:38 2014 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552FF1A049F; Tue, 22 Jul 2014 15:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgpC-pvMA-ZS; Tue, 22 Jul 2014 15:05:30 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DD2C1A03EA; Tue, 22 Jul 2014 15:05:30 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t60so290655wes.20 for ; Tue, 22 Jul 2014 15:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=HRMnct5vy0AawHpLhSCEPyJnbrhtWmBmj1MfYfOgS3g=; b=EWAlLa9qu8Y7DEfPnYkCiZz20pVMk4DJi7fLImYOY2M2v8C2OdETYnoG5HrFjg40fS azZylzgpspJAXeCXJfXZ1mxQ1/YFotMI37JmmLxV6Jo//Zrn/58xH4LBgBfcRQY8rUx4 7gcSrLKQGzS3O/4UmmhKflFch5Qs3fl663Yy07BWaqHG9TrZBmn7oNFFS9SNidnSSHZS +hqXKD5CefNRVk6xSeOuENgbCK8LQUJ3OUMlSB7zGVsHjzUA2FVUJOLqs69CemxPAVpq 1yv4ib0fzLzSRFxmXgqs/QrsVKqB/4KRoYLV1U/IqrSfgPeSczK12D3KwpIb4lX+IYkF sWZg== MIME-Version: 1.0 X-Received: by 10.180.95.166 with SMTP id dl6mr19046249wib.15.1406066728759; Tue, 22 Jul 2014 15:05:28 -0700 (PDT) Received: by 10.217.122.78 with HTTP; Tue, 22 Jul 2014 15:05:28 -0700 (PDT) Date: Wed, 23 Jul 2014 00:05:28 +0200 Message-ID: From: Jean-Michel Combes To: iesg-secretary@ietf.org Content-Type: multipart/alternative; boundary=f46d04428998e5fbbd04fecf6b1d Archived-At: http://mailarchive.ietf.org/arch/msg/savi/Qh6gibjoS8rnj5tAPuTUpPvXGBg Cc: "int-ads@tools.ietf.org" , "" , SAVI Mailing List , "savi-chairs@tools.ietf.org" Subject: [savi] Publication request for "SAVI Solution for DHCP" (draft-ietf-savi-dhcp-29) X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2014 22:05:37 -0000 --f46d04428998e5fbbd04fecf6b1d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Secretary, This is a request to publish draft-ietf-savi-dhcp-29 as Standard track RFC. Please find below the Shepherd Document write-up. Thanks in advance. Best regards, JMC. (1) The type of RFC requested is Proposed Standard. This is the proper type because this document describes specifications for a mechanism being implemented and deployed. The type of RFC is indicated in the title page header. (2) Here is the Document Announcement Write-Up, Technical Summary: This document specifies the procedure for creating a binding between a DHCPv4/DHCPv6 assigned IP address and a binding anchor on a SAVI (Source Address Validation Improvements) device. The bindings set up by this procedure is used to filter out packets with forged source IP address in DHCP scenario. This mechanism is proposed as a complement to ingress filtering to provide finer-grained source IP address validation. Working Group Summary: Even if IPR have been disclosed, there is no concern from the WG to move forward this document as Proposed Standard. Document Quality: This document has been thorough reviewed. Personnel: The document shepherd is Jean-Michel Combes (jeanmichel.combes@gmail.com). = The Responsible Area Director is Ted Lemon (ted.lemon@nominum.com) (3) The review of this document performed by the Document Shepherd includes: - Comments from IESG regarding the other SAVI documents (i.e., FCFS SAVI, SEND SAVI) are taken into account inside this document - Specifications described inside this document are following, when possible, the same framework as the other SAVI documents (i.e., FCFS SAVI, SEND SAVI) to ease the implementation of many SAVI mechanism inside a same SAVI device. - A check of the English level (even if English is not the mother tongue of the Document Shepherd). (4) The Document Shepherd has no concern about the deph or breadth of the reviews that have been performed. (5) As the mechanism specified in this document is strongly based on DHCPv4/DHCPv6, the dhc WG has been associated to the WGLC. (6) The Document Shepherd has no specific concerns or issue with this document. (7) Each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have been filed. (8) An IPR disclosure has been filed that references this document. After the disclosure, a new WGLC has been launched to know if any member of the WG would have concerns to move forward the document: there was no concern. (9) The WG consensus behind this document is mainly based of the agreement of a small group with others being silent. (10) Nobody threatened an appeal or otherwise indicated extreme discontent= . (11) The check done with ID Nits tool is not successful: there is one error. (12) The document doesn=E2=80=99t need to meet any required format review = criteria (13) All references within this document have been identified as either normative or informative but, as noted by the ID Nits check (cf. above), a normative reference is in fact an Informational RFC. (14) There are 2 normative references (i.e., ietf-opsec-dhcpv6-shield, ietf-dhc-dhcpv4-over-dhcpv6) that are not ready for advancement. Finally, the Document Shepherd believes these references should become informative references as they don=E2=80=99t impact critically the mechanism specified = in this document. (15) There is one downward normative reference (cf. ID Nits check). This normative reference should become informative reference. (16) The publication of this document will not change the status of any existing RFC. (17) There is no request for an action from the IANA. (18) There is no request for an action from the IANA. (19) There is no formal language inside this document expecting a specific review from the Document Shepherd. --f46d04428998e5fbbd04fecf6b1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Secretary,

This is a= request to publish draft-ietf-sav= i-dhcp-29 as Standard track RFC. Please find= below the Shepherd Document write-up.

Thanks in advance.

Best regards,

JMC.

(1)=C2=A0=C2=A0 The type of RFC requested is Proposed Standard. This is the proper type because this document describes specifications for a mechanism being implemented and deployed. The type of = RFC is indicated in the title page header.

(2)=C2=A0=C2=A0 Here is the Document Announcement Write-Up,

Technical Summary:

This document specifies the procedure for creating a binding between a DHCPv4/DH= CPv6 assigned IP address and a binding anchor on a SAVI (Source Address Validati= on Improvements) device. The bindings set up by this procedure is used to filt= er out packets with forged source IP address in DHCP scenario. This mechanism = is proposed as a complement to ingress filtering to provide finer-grained sour= ce IP address validation.

Working Group Summary:

Even if IPR have been disclosed, there is no concern from the WG to move forward this document as Proposed Standard.

Document Quality:

This document has been thorough reviewed.

Personnel:

The document shepherd is Jean-Michel Combes (jeanmichel.combes@gmail.com= ). The Responsible Area Director is Ted Lemon (ted.lemon@nominum.com)

(3)=C2=A0=C2=A0 The review of this document performed by the Document Shepherd includes:

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Comments from IESG regarding the other SAVI documents (i.e., FCFS SAVI, SEND SAVI) a= re taken into account inside this document

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Specifications described inside this document are following, when possible, the same frame= work as the other SAVI documents (i.e., FCFS SAVI, SEND SAVI) to ease the implementation of many SAVI mechanism inside a same SAVI device.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 A check of the English level (even if English is not the mother tongue of the= Document Shepherd).

(4)=C2=A0=C2=A0 The Document Shepherd has no concern about the deph or breadth of the reviews that have been performed.

(5)=C2=A0=C2=A0 As the mechanism specified in this document is strongly based on DHCPv4/DHCPv6, the dhc WG has been associated= to the WGLC.

(6)=C2=A0=C2=A0 The Document Shepherd has no specific concerns or issue with this document.

(7)=C2=A0=C2=A0 Each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have been filed.

(8)=C2=A0=C2=A0 An IPR disclosure has been filed that references this document. After the disclosure, a new WGLC has been la= unched to know if any member of the WG would have concerns to move forward the document: there was no concern. =C2=A0

(9)=C2=A0=C2=A0 The WG consensus behind this document is mainly based of the agreement of a small group with others bein= g silent.

(10)=C2=A0 Nobody threatened an appeal or otherwise indicated extreme discontent.

(11)=C2=A0 The check done with ID Nits tool is not successful: there is one error. =

(12)=C2=A0 The document doesn=E2=80=99t need to meet any required format review criteria

(13)=C2=A0 All references within this document have been identified as either normative or informative but, as noted by the ID Nits check (cf. above), a normative reference is in fact an Informational RFC.

(14)=C2=A0 There are 2 normative references (i.e., ietf-opsec-dhcpv6-shield, ietf-dhc-dhcpv4= -over-dhcpv6) that are not ready for advancement. Finally, the Document Shepherd believes these references should become informative references as they don=E2=80=99t= impact critically the mechanism specified in this document.

(15) <= /span>There is one downward normative reference (cf. ID Nits check). This normative reference should become informative reference.

(16) The publication of this document will not change the status of any existing RFC= .

(17) There is no request for an action from the IANA.

(18) There is no request for an action from the IANA.

(19) There is no formal language inside this document expecting a specific review from= the Document Shepherd.

=C2=A0


--f46d04428998e5fbbd04fecf6b1d-- From nobody Thu Jul 24 06:49:38 2014 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3AB1A0327; Thu, 24 Jul 2014 06:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUNuvhcDA64S; Thu, 24 Jul 2014 06:49:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C81DD1A032E; Thu, 24 Jul 2014 06:49:08 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140724134908.20985.70713.idtracker@ietfa.amsl.com> Date: Thu, 24 Jul 2014 06:49:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/savi/fdiMh3HpYz9Ac1e-cFGdpx7lRoY Cc: savi@ietf.org Subject: [savi] Last Call: (SAVI Solution for DHCP) to Proposed Standard X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org 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, 24 Jul 2014 13:49:24 -0000 The IESG has received a request from the Source Address Validation Improvements WG (savi) to consider the following document: - 'SAVI Solution for DHCP' as 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 2014-08-07. 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 a binding between a DHCPv4/DHCPv6 assigned IP address and a binding anchor on a SAVI (Source Address Validation Improvements) device. The bindings set up by this procedure is used to filter out packets with forged source IP address in DHCP scenario. This mechanism is proposed as a complement to ingress filtering to provide finer-grained source IP address validation. 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/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2373/