From nobody Thu Mar 6 08:36: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 947F21A00E8; Thu, 6 Mar 2014 08:36:05 -0800 (PST) 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 IniS-rBJWc2W; Thu, 6 Mar 2014 08:36:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFD01A00F4; Thu, 6 Mar 2014 08:36:02 -0800 (PST) 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.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140306163602.25489.97813.idtracker@ietfa.amsl.com> Date: Thu, 06 Mar 2014 08:36:02 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/savi/YnI8wZlmwbFAp-DXryPjbqCfess Cc: savi@ietf.org Subject: [savi] I-D Action: draft-ietf-savi-dhcp-19.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: Thu, 06 Mar 2014 16:36:05 -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-19.txt Pages : 44 Date : 2014-03-06 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 can be 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-19 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-savi-dhcp-19 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 Mar 11 04:56:44 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 A33971A066C; Tue, 11 Mar 2014 04:56:39 -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 FyDLfTRVfuQe; Tue, 11 Mar 2014 04:56:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4BF1A070D; Tue, 11 Mar 2014 04:56:37 -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.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140311115637.23954.57194.idtracker@ietfa.amsl.com> Date: Tue, 11 Mar 2014 04:56:37 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/savi/EkD8XIMky_MrFm44LRDTaGsENmk Cc: savi@ietf.org Subject: [savi] I-D Action: draft-ietf-savi-dhcp-20.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, 11 Mar 2014 11:56:40 -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-20.txt Pages : 43 Date : 2014-03-11 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 can be 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-20 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-savi-dhcp-20 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 Fri Mar 21 03:52:07 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 C01FD1A06B4 for ; Fri, 21 Mar 2014 03:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 95M1JcnZJnj1 for ; Fri, 21 Mar 2014 03:52:04 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id E77591A0717 for ; Fri, 21 Mar 2014 03:52:03 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C31F37FC399; Fri, 21 Mar 2014 03:51:53 -0700 (PDT) To: nordmark@acm.org, marcelo@it.uc3m.es, elevyabe@cisco.com, brian@innovationslab.net, ted.lemon@nominum.com, jeanmichel.combes@gmail.com From: RFC Errata System Message-Id: <20140321105153.C31F37FC399@rfc-editor.org> Date: Fri, 21 Mar 2014 03:51:53 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/savi/STZCKaWXoRsZVS5ooNE6tjqrvMQ Cc: leaf.yeh.sdo@gmail.com, savi@ietf.org, rfc-editor@rfc-editor.org Subject: [savi] [Editorial Errata Reported] RFC6620 (3926) 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: Fri, 21 Mar 2014 10:52:06 -0000 The following errata report has been submitted for RFC6620, "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6620&eid=3926 -------------------------------------- Type: Editorial Reported by: Leaf Yeh Section: 3.2.3 Original Text ------------- +---------+ VP_NS, VP_DATA/2xNS +-----------+ | |---------------------------------------->| | | NO_BIND | | TENTATIVE | | |<----------------------------------------| | +---------+ TP_NA, TP_NS/- +-----------+ ^ | | | TimeOut Timeout| | | v +---------+ VP_NA/- +-----------+ | |---------------------------------------->| | | TESTING | TP_NS/- | | | TP-LT |<----------------------------------------| VALID | | | TimeOut/2xNS | | | |<----------------------------------------| | +---------+ +-----------+ ^ | ^ | | | | | | +--------------------- ---------------------+ | | VP_NS/- | | NP_NA, TimeOut/- | | v | | | +-----------+ | | | | | +---------------------| TESTING |<----------------------+ VP_NS, VP_DATA/- | VP | VP_DATA, VP_NS, +-----------+ VP_NA/2xNS Figure 2: Simplified State Machine Corrected Text -------------- +---------+ VP_NS, VP_DATA/2xNS +-----------+ | |---------------------------------------->| | | NO_BIND | | TENTATIVE | | |<----------------------------------------| | +---------+ TP_NA, TP_NS/- +-----------+ ^ | | | TimeOut Timeout| | | v +---------+ VP_NA/- +-----------+ | |---------------------------------------->| | | TESTING | TP_NS/- | | | TP-LT |<----------------------------------------| VALID | | | TimeOut/2xNS | | | |<----------------------------------------| | +---------+ +-----------+ ^ | ^ | | | | | | +--------------------- ---------------------+ | | VP_NS/- | | VP_NA, TimeOut/- | | v | | | +-----------+ | | | | | +---------------------| TESTING |<----------------------+ TP_NS, TP_DATA/- | VP | VP_DATA, VP_NS, +-----------+ VP_NA/2xNS Figure 2: Simplified State Machine Notes ----- a. According to the description on the state machine at page 19, o If an NA message containing the IPAddr as the Target Address is received through the Validating Port P as a reply to the DAD_NS message, then the NA is forwarded as usual and the state is changed to VALID. The LIFETIME is set to DEFAULT_LT. the state change from TESTING_VP to VALID should be triggered by the VP_NA (NA message containing the IPAddr as the Target Address is received through the Validating Port). b. According to the description on the state machine at page 19, o If a data packet containing IPAddr as the source address is received through a Trusted Port (i.e., other than port P), the state is moved to TESTING_TP-LT, and the packet MAY be discarded. o If a DAD_NS is received through a Trusted Port, the packet is forwarded as usual, and the state is moved to TESTING_TP-LT. the state change from TESTING_VP to TESTING_TP-LT should be triggered by the TP_DATA (data packet containing IPAddr as the source address received through a Trusted Port), or by the TP_NS (DAD_NS is received through a Trusted Port). Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6620 (draft-ietf-savi-fcfs-14) -------------------------------------- Title : FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses Publication Date : May 2012 Author(s) : E. Nordmark, M. Bagnulo, E. Levy-Abegnoli Category : PROPOSED STANDARD Source : Source Address Validation Improvements Area : Internet Stream : IETF Verifying Party : IESG From nobody Fri Mar 21 04:10:46 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 2B0F01A0717 for ; Fri, 21 Mar 2014 04:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 0EvhwYaUJ733 for ; Fri, 21 Mar 2014 04:10:43 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id AA47E1A08A0 for ; Fri, 21 Mar 2014 04:10:40 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 750807FC387; Fri, 21 Mar 2014 04:10:31 -0700 (PDT) To: nordmark@acm.org, marcelo@it.uc3m.es, elevyabe@cisco.com, brian@innovationslab.net, ted.lemon@nominum.com, jeanmichel.combes@gmail.com From: RFC Errata System Message-Id: <20140321111031.750807FC387@rfc-editor.org> Date: Fri, 21 Mar 2014 04:10:31 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/savi/5gbS8e_rz50V3gQzSmJESMJVyVU Cc: leaf.yeh.sdo@gmail.com, savi@ietf.org, rfc-editor@rfc-editor.org Subject: [savi] [Editorial Errata Reported] RFC6620 (3927) 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: Fri, 21 Mar 2014 11:10:45 -0000 The following errata report has been submitted for RFC6620, "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6620&eid=3927 -------------------------------------- Type: Editorial Reported by: Leaf Yeh Section: 2.5 Original Text ------------- In order to provide proper source address validation, it is critical that the information distributed among the different FCFS SAVI devices be coherent. Corrected Text -------------- In order to provide proper source address validation, it is critical that the information distributed among the different FCFS SAVI devices be not coherent. Notes ----- The above revision then complies with the other statements in the same paragraph: In particular, it is important to avoid having the same source address bound to different binding anchors in different FCFS SAVI devices. Should that occur, then it would mean that two hosts are allowed to send packets with the same source address, which is what FCFS SAVI is trying to prevent. In order to preserve the coherency of the FCFS SAVI bindings distributed among the FCFS SAVI devices within a realm, the Neighbor Discovery (ND) protocol [RFC4861] is used, in particular the Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6620 (draft-ietf-savi-fcfs-14) -------------------------------------- Title : FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses Publication Date : May 2012 Author(s) : E. Nordmark, M. Bagnulo, E. Levy-Abegnoli Category : PROPOSED STANDARD Source : Source Address Validation Improvements Area : Internet Stream : IETF Verifying Party : IESG From nobody Fri Mar 21 05:37:31 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 338001A097F for ; Fri, 21 Mar 2014 05:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 h47FaSt41OH2 for ; Fri, 21 Mar 2014 05:37:22 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id BEA0C1A071B for ; Fri, 21 Mar 2014 05:37:22 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B06A91B87C0 for ; Fri, 21 Mar 2014 05:37:13 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 8F136190043; Fri, 21 Mar 2014 05:37:13 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Mar 2014 05:37:13 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <20140321105153.C31F37FC399@rfc-editor.org> Date: Fri, 21 Mar 2014 08:37:04 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <4191B0B1-BCEE-4F0B-BC06-A17F26A09533@nominum.com> References: <20140321105153.C31F37FC399@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/savi/2679WK7l-ZShdY-wj327WGjLS1w Cc: Brian Haberman , savi@ietf.org, leaf.yeh.sdo@gmail.com, jeanmichel.combes@gmail.com Subject: Re: [savi] [Editorial Errata Reported] RFC6620 (3926) 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: Fri, 21 Mar 2014 12:37:29 -0000 Leaf, I can't tell from this report what it is that you think is wrong, = nor why it is wrong. It looks like you made a change in the lower left = corner of the state diagram. Can you explain what the problem is? From nobody Fri Mar 21 05:39:24 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 AAF851A098A; Fri, 21 Mar 2014 05:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 uTGJmMfXReBn; Fri, 21 Mar 2014 05:39:21 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id CD6DC1A0983; Fri, 21 Mar 2014 05:39:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B945B7FC387; Fri, 21 Mar 2014 05:39:11 -0700 (PDT) To: leaf.yeh.sdo@gmail.com, nordmark@acm.org, marcelo@it.uc3m.es, elevyabe@cisco.com From: RFC Errata System Message-Id: <20140321123911.B945B7FC387@rfc-editor.org> Date: Fri, 21 Mar 2014 05:39:11 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/savi/XvUsGilp9ixTGFdfwOFo-QQS8oQ Cc: rfc-editor@rfc-editor.org, savi@ietf.org, ted.lemon@nominum.com, iesg@ietf.org Subject: [savi] [Errata Rejected] RFC6620 (3927) 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: Fri, 21 Mar 2014 12:39:23 -0000 The following errata report has been rejected for RFC6620, "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6620&eid=3927 -------------------------------------- Status: Rejected Type: Editorial Reported by: Leaf Yeh Date Reported: 2014-03-21 Rejected by: Ted Lemon (IESG) Section: 2.5 Original Text ------------- In order to provide proper source address validation, it is critical that the information distributed among the different FCFS SAVI devices be coherent. Corrected Text -------------- In order to provide proper source address validation, it is critical that the information distributed among the different FCFS SAVI devices be not coherent. Notes ----- The above revision then complies with the other statements in the same paragraph: In particular, it is important to avoid having the same source address bound to different binding anchors in different FCFS SAVI devices. Should that occur, then it would mean that two hosts are allowed to send packets with the same source address, which is what FCFS SAVI is trying to prevent. In order to preserve the coherency of the FCFS SAVI bindings distributed among the FCFS SAVI devices within a realm, the Neighbor Discovery (ND) protocol [RFC4861] is used, in particular the Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages. --VERIFIER NOTES-- The proposed change is incorrect. I think you have misunderstood what the word "coherent" means, and this led to confusion. -------------------------------------- RFC6620 (draft-ietf-savi-fcfs-14) -------------------------------------- Title : FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses Publication Date : May 2012 Author(s) : E. Nordmark, M. Bagnulo, E. Levy-Abegnoli Category : PROPOSED STANDARD Source : Source Address Validation Improvements Area : Internet Stream : IETF Verifying Party : IESG From nobody Sat Mar 22 04:42:36 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 370F61A076B for ; Sat, 22 Mar 2014 04:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 NxdGkdWhxzWx for ; Sat, 22 Mar 2014 04:42:32 -0700 (PDT) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id A2DDD1A06B4 for ; Sat, 22 Mar 2014 04:42:32 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id jt11so3515575pbb.28 for ; Sat, 22 Mar 2014 04:42:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=DEg+dykXx2LiqpegiRj8kKFA6wau35cfzK+zzo6sFME=; b=SOYBcAvWQo5TVr9WSecZYOzTBSofBsUAZCWEW7XkQgIg1LGAKYbHJ6b/Qg5a/HpzjN PRby3IoZi/LN9ZvU7GNstBdDHn6Sup6dRgUA/b4A9ZZPPDWi80AWFUpKsUu1yD87Jkkn Opqb0NG7UCcmmLTRX5ilyFy+pU7caeyu7seKZ5Qp1x4t4twPVzC65GQ4l2BJFLdTGNyu Ax/fkuun8PB31DXl4wmGnrC3Mt5wZ+TUOyma2wxSt5uwvNlhc9B02UFJK2vh9ZXWY7qU A7ZGv89U8ZUWB/w3CDcsHDm10V1o7YiS1XGAXUt/vomYsdKAD/lUefTvdALT3ZgN0eAv QD3w== X-Received: by 10.66.102.66 with SMTP id fm2mr60192524pab.51.1395488552705; Sat, 22 Mar 2014 04:42:32 -0700 (PDT) Received: from PC ([221.219.106.46]) by mx.google.com with ESMTPSA id pq3sm15211682pbb.57.2014.03.22.04.42.29 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 22 Mar 2014 04:42:32 -0700 (PDT) From: "Leaf Yeh" To: "'Ted Lemon'" , References: <20140321105153.C31F37FC399@rfc-editor.org> <4191B0B1-BCEE-4F0B-BC06-A17F26A09533@nominum.com> In-Reply-To: <4191B0B1-BCEE-4F0B-BC06-A17F26A09533@nominum.com> Date: Sat, 22 Mar 2014 19:42:32 +0800 Message-ID: <532d7728.4387440a.099e.4779@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9FAkskv0h/99D+S0SW8/RUbaAZNwAui4Qw Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/savi/AB3QlhEDMXUeqaYFsZ9qQReA4o4 Cc: 'Brian Haberman' , jeanmichel.combes@gmail.com Subject: Re: [savi] [Editorial Errata Reported] RFC6620 (3926) 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: Sat, 22 Mar 2014 11:42:34 -0000 Ted- Leaf, I can't tell from this report what it is that you think is wrong, nor why it is wrong. It looks like you made a change in the lower left corner of the state diagram. Can you explain what the problem is? Could we ask the input from the authors of RFC 6620 or the input from SAVI-WG on this reported Errata? It make 2 revisions on the Fig.2 per the description in Page 19 of RFC 6620. One is for 'NP_NA' message between the state of 'TESTING_VP' and 'Valid'. I suppose we can't find the definition of this message in the RFC. The other is for 'VP_NS, VP_DATA' messages between the state of 'TESTING_VP' and 'TESTING_TP-LT'. I believe they are 'TP_NS, TP_DATA '. Notes in the Errata show you the reasons I inputted. Best Regards, Leaf -----Original Message----- From: Ted Lemon [mailto:ted.lemon@nominum.com] Sent: Friday, March 21, 2014 8:37 PM To: RFC Errata System Cc: nordmark@acm.org; marcelo@it.uc3m.es; elevyabe@cisco.com; Brian Haberman; jeanmichel.combes@gmail.com; leaf.yeh.sdo@gmail.com; savi@ietf.org Subject: Re: [Editorial Errata Reported] RFC6620 (3926) Leaf, I can't tell from this report what it is that you think is wrong, nor why it is wrong. It looks like you made a change in the lower left corner of the state diagram. Can you explain what the problem is? From nobody Sat Mar 22 04:42:47 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 947481A076B; Sat, 22 Mar 2014 04:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 6jIkzCPwcf5L; Sat, 22 Mar 2014 04:42:35 -0700 (PDT) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id AD3FB1A06B4; Sat, 22 Mar 2014 04:42:35 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id md12so3481633pbc.7 for ; Sat, 22 Mar 2014 04:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=Cm5fccaBN0LBmtmpuiBY4BR4uSyOdu1a6OIoMLaBvbE=; b=bm5Hl6YxXe+Oke0K5E6DAAdix9UZZvSxda6C6wAPuv7piyzQcY2ZsVYJrVxwhn9FJa hcc7O6qFfbqBAFfNLlznsSJovE/LxZt1AmW9vPPbErsqDKU+wHRPryIwACFPYPzxziit 9xgMXpc0yLL6GMSHK7qV8clIpkgCBgTj3HuQ+OMxFs00Ah6ctkAU095pP2nqyeXV2w7j 6gaaYe6r/ou8uAX0w8fnCO8GMjnyAO6zsioA1kQuJjaWkOfK+0eKNDiR7I+1dvUDGGWB cAQscX3kwd2TKGe7vmcxZKgWHx/BCzEzULWZeAbfYG0+SjeaYppKQH0pqW9tV3QYYnCO 2W/w== X-Received: by 10.66.137.109 with SMTP id qh13mr36461939pab.39.1395488555690; Sat, 22 Mar 2014 04:42:35 -0700 (PDT) Received: from PC ([221.219.106.46]) by mx.google.com with ESMTPSA id pq3sm15211682pbb.57.2014.03.22.04.42.33 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 22 Mar 2014 04:42:35 -0700 (PDT) From: "Leaf Yeh" To: , , References: <20140321123911.B945B7FC387@rfc-editor.org> In-Reply-To: <20140321123911.B945B7FC387@rfc-editor.org> Date: Sat, 22 Mar 2014 19:42:32 +0800 Message-ID: <532d772b.4387440a.099e.477b@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9FAo+wiVHDIVyvRMahkYo4ndVrqQAvxVkw Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/savi/U9HGiW8HJ2AVLIiw04ke5DzrH2g Cc: savi@ietf.org, ted.lemon@nominum.com, iesg@ietf.org Subject: Re: [savi] [Errata Rejected] RFC6620 (3927) 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: Sat, 22 Mar 2014 11:42:37 -0000 Ted - The proposed change is incorrect. I think you have misunderstood what the word "coherent" means, and this led to confusion. Accepted. Might be my mistake. Best Regards, Leaf -----Original Message----- From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] Sent: Friday, March 21, 2014 8:39 PM To: leaf.yeh.sdo@gmail.com; nordmark@acm.org; marcelo@it.uc3m.es; elevyabe@cisco.com Cc: ted.lemon@nominum.com; iesg@ietf.org; savi@ietf.org; rfc-editor@rfc-editor.org Subject: [Errata Rejected] RFC6620 (3927) The following errata report has been rejected for RFC6620, "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6620&eid=3927 -------------------------------------- Status: Rejected Type: Editorial Reported by: Leaf Yeh Date Reported: 2014-03-21 Rejected by: Ted Lemon (IESG) Section: 2.5 Original Text ------------- In order to provide proper source address validation, it is critical that the information distributed among the different FCFS SAVI devices be coherent. Corrected Text -------------- In order to provide proper source address validation, it is critical that the information distributed among the different FCFS SAVI devices be not coherent. Notes ----- The above revision then complies with the other statements in the same paragraph: In particular, it is important to avoid having the same source address bound to different binding anchors in different FCFS SAVI devices. Should that occur, then it would mean that two hosts are allowed to send packets with the same source address, which is what FCFS SAVI is trying to prevent. In order to preserve the coherency of the FCFS SAVI bindings distributed among the FCFS SAVI devices within a realm, the Neighbor Discovery (ND) protocol [RFC4861] is used, in particular the Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages. --VERIFIER NOTES-- The proposed change is incorrect. I think you have misunderstood what the word "coherent" means, and this led to confusion. -------------------------------------- RFC6620 (draft-ietf-savi-fcfs-14) -------------------------------------- Title : FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses Publication Date : May 2012 Author(s) : E. Nordmark, M. Bagnulo, E. Levy-Abegnoli Category : PROPOSED STANDARD Source : Source Address Validation Improvements Area : Internet Stream : IETF Verifying Party : IESG From nobody Mon Mar 24 08:05:31 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 0A5D61A023C for ; Mon, 24 Mar 2014 08:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 Aww41yNyK91p for ; Mon, 24 Mar 2014 08:05:27 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id C29381A022D for ; Mon, 24 Mar 2014 08:05:27 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 5507D1B8049 for ; Mon, 24 Mar 2014 08:05:27 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 4D934190043; Mon, 24 Mar 2014 08:05:27 -0700 (PDT) Received: from [192.168.146.119] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 24 Mar 2014 08:05:27 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <532d7728.4387440a.099e.4779@mx.google.com> Date: Mon, 24 Mar 2014 10:05:23 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <4B7FAFCA-B811-472A-A812-C08E97FF713D@nominum.com> References: <20140321105153.C31F37FC399@rfc-editor.org> <4191B0B1-BCEE-4F0B-BC06-A17F26A09533@nominum.com> <532d7728.4387440a.099e.4779@mx.google.com> To: Leaf Yeh X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/savi/L_T4l8Uvg65oIDbd6YgKC9Vl6RY Cc: Brian Haberman , savi@ietf.org, jeanmichel.combes@gmail.com Subject: Re: [savi] [Editorial Errata Reported] RFC6620 (3926) 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: Mon, 24 Mar 2014 15:05:29 -0000 On Mar 22, 2014, at 6:42 AM, Leaf Yeh wrote: > Could we ask the input from the authors of RFC 6620 or the input from > SAVI-WG on this reported Errata? Could the authors please work with Leaf to figure out if this erratum is = correct? I do not have time to wade deeply enough into the document to = either accept or reject it on my own at the moment. Thanks! From nobody Thu Mar 27 10:05:00 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 7EE001A032C for ; Thu, 27 Mar 2014 10:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 R0QcOegze42w for ; Thu, 27 Mar 2014 10:04:43 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0034F1A016A for ; Thu, 27 Mar 2014 10:04:42 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id y10so3625080pdj.36 for ; Thu, 27 Mar 2014 10:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=0E+p3xTrqqEVwGSmkNnll1ocuG5riyEABxQJyDuOjto=; b=lPj9oZVCGih+ESl+9mGSGU5eo+DlmBoFtmyMETdLbrVnoCBgirIqt8TzrPnU8Li2Un O8vWGYyxZ+oClB1ustvP6roKs5tBMEXqBlulKVWcAHLNsOa1fI0RpNh/4tCwa2tjkHlR UxIOOT14Ud8hwl40lH19a5EmUtr55RhCU3aHVFLrNqpPfnanPzZjfZH/DDx68pLJ8xEg EYjavPyl8JvGejyGH8cupo0FsJFwsexcZYnFrqDmBc0gCCpNBd05wDsgnN0o1+1UfZl5 ZhsBqNOEKPaEGaEAanN7EVSv5xYyPA/UzfrKRJ61mIZgJiuBUxLv3AzJwAZClZASnbJ3 o+yQ== X-Received: by 10.68.136.2 with SMTP id pw2mr2915428pbb.167.1395939881033; Thu, 27 Mar 2014 10:04:41 -0700 (PDT) Received: from PC ([111.193.216.114]) by mx.google.com with ESMTPSA id dn1sm11322890pbb.54.2014.03.27.10.04.33 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 27 Mar 2014 10:04:40 -0700 (PDT) From: "Leaf Yeh" To: "'Jun Bi'" , "'Jun Bi'" , Date: Fri, 28 Mar 2014 01:04:32 +0800 Message-ID: <53345a28.e15f440a.76a1.430a@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9J16rOOdgzn4htS7aerOCadVF55Q== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/savi/eZ-XZ_AFx6HK7VXXBToomG9vlgo Cc: savi@ietf.org, 'Ted Lemon' Subject: [savi] Some findings in the darft-ietf-savi-dhcp-20 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: Thu, 27 Mar 2014 17:04:58 -0000 Dear Prof. Bi & authors, I=E2=80=99ve read the main part of the darft-ietf-savi-dhcp-20, and = probably got the following findings: 1. In the 1st paragraph of Page 11,=20 For example, in Figure 1, the attachment from the Non-SAVI Device 1 to = the SAVI Device B should be configured with no attribute. But in Fig.1, Non-SAVI Device 1 is not directly connected to SAVI Device = B. I suppose the draft really means =E2=80=98SAVI Device C=E2=80=99 = here. *** 2. In the last paragraph of page 11,=20 In Figure 1, the attachment from the DHCP Relay to the SAVI Device B, = and the attachment from the DHCP Server B to the SAVI Device B should be = configured with this attribute.=20 (for DHCP-Trust Attribute) But in Fig.1, DHCP Relay is not directly connected to SAVI Device B. I = suppose the draft really means =E2=80=98SAVI Device A=E2=80=99 here.=20 *** As to Fig.1, question for clarification : It sounds to set up a filter = (as the requirement of DHCP-Trust Attribute) inside the SAVI-perimeter. = I guess if the Relay or Server B is directly connected to SAVI Device = and outside the SAVI-perimeter, we still need to set up DHCP-Trust = Attribute for the port of SAVI Device A and B, right? If yes, does it = means the Fig.1 can let the Relay or Server B outside the = SAVI-perimeter?=20 3. Question of clarification on the text in the 3rd paragraph of section = 4.3.1,=20 In this case, SAVI device B doesn=E2=80=99t create a binding for client = A. SAVI device A doesn=E2=80=99t create a binding for client B. But the = SAVI device B is still protected from spoofing from client A and the = SAVI device A is still protected from spoofing from client B.=20 What does =E2=80=9CSAVI device B is still protected from spoofing from = client A=E2=80=9D exactly mean? How can SAVI device B protects from = spoofing from client A? It sounds a little confused. 4. Question of clarification on the text in section 4.3.2, (6) Optional: configure filters on the upstream links to filter out spoofing of local addresses from other networks. Per the definition of =E2=80=98Upstream link=E2=80=99 and = =E2=80=98Downstream link=E2=80=99 in section 3, upstream is for other = network (with gateway router), downstream is for local network. I guess = the text here might mean =E2=80=98filter out spoofing of source = addresses from other networks.=E2=80=99 5. Question of clarification on the text in the last paragraph of = section 4.3.2,=20 In this way, the points of attachments with Validating attribute (and generally together with attachments of upstream devices) on SAVI devices can form a perimeter separating DHCP clients and trusted devices. The above sentence sounds SAVI devices always form perimeter for = upstream devices. But in general thinking, we always trust devices in = the upstream network. In Fig.1, we should not configure = =E2=80=98DHCP-Trust attribute=E2=80=99 on the port of SAVI Device C for = the Server A through Non-SAVI Device 1, which might means the Client A = and Client B can=E2=80=99t get address assignment from Server A of the = upstream network. Does the above sounds a little confused? 6. Question of clarification on the text in the last paragraph of = section 4.3.2,=20 DHCP-Trust attribute is only configured on the inside links of the = perimeter.=20 The above sentence sounds, even in the SAVI-perimeter, we still need set = up filter for some devices, including relay and server. It sounds we = couldn=E2=80=99t trust the relay and server in the SAVI-perimeter; and = after we configure the DHCP-Trust attribute on the port of the = SAVI-device which connect the relay or server, we start to trust them. = But in general thinking, we always trust devices in the perimeter, and = we don=E2=80=99t need additional SAVI-device to connect some kind of = device in the perimeter. Does the above sounds a little confused? 7. Question of clarification on table 3 of BST in section 5: +---------+----------+----------+-----------+-------+ | Anchor | Address | State | Lifetime |TID | +---------+----------+----------+-----------+-------+ | A | IP_1 | BOUND | 65535 |TID_1 | +---------+----------+----------+-----------+-------+ | A | IP_2 | BOUND | 10000 |TID_2 | +---------+----------+----------+-----------+-------+ | B | IP_3 |INIT_BIND | 1 |TID_3 | +---------+----------+----------+-----------+-------+ for Binding State Table It is not quite sure about =E2=80=98A=E2=80=99 and =E2=80=98B=E2=80=99 = in the column of Anchor stands for. Does =E2=80=98A=E2=80=99 stands for = the Client A? It must not stand for SAVI-Device A. =E2=98=BA=20 Per the definition of =E2=80=98Binding anchor=E2=80=99 in section 3, the = anchor is the link-layer property of Clients. It sound usually be the = port of SAVI-device which connect Client A, right? On the other hand, I guess the =E2=80=98Creation Time=E2=80=99 of the = entry looks like a field in this table per the usage described in the = section 9. For the reason of consistency, we also have the field of = =E2=80=98Creation Time=E2=80=99 in the FCFS-SAVI DataBase (i.e. = SAVI-SLAAC DB, section 3.1 of RFC6620). 8. In section 6.3,=20 EVE_DHCP_OPTION_RC: A DHCPv6 Solicitation message with Rapid Commit option is received. I guess =E2=80=98EVE_DHCP_SOLICIT_RC=E2=80=99 looks better than = =E2=80=98EVE_DHCP_OPTION_RC, though I don=E2=80=99t really like the = prefix of =E2=80=98EVE_=E2=80=99 here. =E2=98=BA The prefix of = =E2=80=98EVE_=E2=80=99 must stand for Event here, supposed it really = means the additional valid check defined in section 6.3.2. 9. For Section 6.4.1, I think we could replace its title =E2=80=98From = NO_BIND to Other States=E2=80=99 to be =E2=80=98From NO_BIND to = INIT_BIND=E2=80=99. 10. In Section 6.4.3.2 If the message is DHCPv6 Reply, the SAVI device checks each IA Address option in each IA option. The related binding entry can be determined based on the address in the IAADDR option in the Leasequery-reply message. I personally like =E2=80=98IA Address option=E2=80=99 and = =E2=80=98IAADDR option=E2=80=99 could written in the same.=20 11. In Section 7.1, Data packets without matching binding entry may trigger this process to set up bindings. This process is not intended to set up a binding whenever a data packet without matched binding entry is received. Does the above 2 sentence sound a little conflict? 12. For Section 7.5.1, I think we could replace its title =E2=80=98From = NO_BIND to Other States=E2=80=99 to be =E2=80=98From NO_BIND to = DETECTION=E2=80=99. 13. In Section 7.5.3.2, about =E2=80=98IPv6 address=E2=80=99 on page 32, Send a Neighbor Solicitation message with the target address set to the IP address in the corresponding entry. The Neighbor Solicitation is only sent to the attachment which triggers the binding. If there is no response after DAD_TIMEOUT, send another Neighbor Solicitation. Could this additional DAD process be added in Fig.13? =E3=80=80=E3=80=80 14. In Section 7.5.3.2, about =E2=80=98IPv6 address=E2=80=99 in page 32, = If there is only one identical response, get the source hardware address from the response. Check if the =E2=80=99chaddr=E2=80=99 field (hardware address) = of the LEASEQUERY-REPLY message matches the source hardware address. If the two addresses do not match, the following actions will not be performed. If there is more than one response, if any of the source hardware addresses matches the =E2=80=99chaddr=E2=80=99 field (hardware address) of the LEASEQUERY-REPLY message, the following actions are to be performed. If the LEASEQUERY-REPLY message mentioned here is defined in RFC5007, I = supposed we can=E2=80=99t find the =E2=80=99chaddr=E2=80=99 field in = this message. *** 15. Section 7.6, just after Fig. 12 LQ_DELAY: MAX_LEASEQUERY_DELAY This =E2=80=98LQ_DELAY=E2=80=99 looks not a note for Fig. 12, but a note = for Fig. 13, right? If yes, should it be placed after Fig. 13? 16. Section 14.2, [savi-fcfs] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFSSAVI: First-Come First-Serve Source-Address Validation for Locally Assigned Addresses", RFC 6620, May 2012. I prefer to replace [savi-fcfs] to be [RFC 6620]. 17. Section 14.2, [savi-framework] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., "Source Address Validation Improvement Framework", draft-ietf-savi-framework-06 (work in progress), I prefer to replace [savi-framework] to be [RFC 7039]. It is not is in = the status of =E2=80=98work in progress=E2=80=99 any more. =E2=98=BA 18. I guess the darft-ietf-savi-dhcp-20 has not support DHCPv6-PD = (RFC3633) for SAVI on the delegated prefix by now, right? Anyway, I am not yet aware the discussion history in SAVI-WG before; the = above might be some additional comments, might be something discussed = before. Hope some of the above could be a help for the text in this = draft, and I am really looking forwarding to the advance of this = draft-ietf-savi-dhcp. Best Regards, Leaf From nobody Sun Mar 30 22:48:45 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 30C0A1A094C; Sun, 30 Mar 2014 22:48:42 -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 Zkzyz1gR6Z7e; Sun, 30 Mar 2014 22:48:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D55D1A0968; Sun, 30 Mar 2014 22:48:39 -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.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140331054839.12951.1562.idtracker@ietfa.amsl.com> Date: Sun, 30 Mar 2014 22:48:39 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/savi/QFHs06nRGy6I_vRQYTWyGoj5kUo Cc: savi@ietf.org Subject: [savi] I-D Action: draft-ietf-savi-dhcp-21.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: Mon, 31 Mar 2014 05:48:42 -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-21.txt Pages : 43 Date : 2014-03-30 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 can be 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-21 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-savi-dhcp-21 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 Mon Mar 31 08:07:25 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 AF92D1A0901 for ; Mon, 31 Mar 2014 02:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.39 X-Spam-Level: * X-Spam-Status: No, score=1.39 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_15=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 OW27qu4FLRV4 for ; Mon, 31 Mar 2014 02:33:17 -0700 (PDT) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id DBBFA1A07A1 for ; Mon, 31 Mar 2014 02:33:16 -0700 (PDT) Received: from AndrewYaoPC (unknown [166.111.132.217]) by centos (Coremail) with SMTP id AQAAf3BbWQJQNjlTarUbAA--.800S2; Mon, 31 Mar 2014 17:33:04 +0800 (CST) From: "Guang Yao" To: "'Leaf Yeh'" , "'Jun Bi'" , "'Jun Bi'" References: <53345a28.e15f440a.76a1.430a@mx.google.com> In-Reply-To: <53345a28.e15f440a.76a1.430a@mx.google.com> Date: Mon, 31 Mar 2014 17:33:05 +0800 Message-ID: <000c01cf4cc4$382c92e0$a885b8a0$@cernet.edu.cn> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000D_01CF4D07.46513270" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHXgVSJEKldWHfW8Xp2lGM95er5l5rqg3LA Content-Language: zh-cn X-CM-TRANSID: AQAAf3BbWQJQNjlTarUbAA--.800S2 X-Coremail-Antispam: 1UD129KBjvAXoWfWr43uFyUKry3AFW8GFWDXFb_yoW8uF4fJo Z3uw4rA3Z7tr47GFZ5KFykGayDGFW09F17Jr1UGr15Gas2qayaqw4UGanrWF98JrW5Krsr X34fXas8Kr1qvF95n29KB7ZKAUJUUUU8529EdanIXcx71UUUUU7v73VFW2AGmfu7bjvjm3 AaLaJ3UjIYCTnIWjp_UUUY77AC8VAFwI0_Jr0_Gr1l1xkIjI8I6I8E6xAIw20EY4v20xva j40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM28EF7xvwVC0I7IYx2IY67 AKxVWUCVW8JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIE 14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26F4UJVW0owAa7VASzI0EjI02j7 AqF2xKxVCjxxvEa2IrM2AIxVAIcxkEcVAq07x20xvEncxIr21le4C267I2x7xF54xIwI1l 5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7 v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lF7xvr2IYc2Ij64vIr40E4x8a64kEw24lF7I21c0E jII2zVCS5cI20VAGYxC7MxkIecxEwVAFwVW8uwCF04k20xvY0x0EwIxGrwC20s026c02F4 0E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1l IxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxV AFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v2 6r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7VU8 nL05UUUUU== X-CM-SenderInfo: 51drw3xdqjquphuqv3oohg3hdfq/ Archived-At: http://mailarchive.ietf.org/arch/msg/savi/-QsasmveL2m9FeaCaXuA7nNprjo X-Mailman-Approved-At: Mon, 31 Mar 2014 08:07:21 -0700 Cc: savi@ietf.org, 'Ted Lemon' Subject: Re: [savi] Some findings in the darft-ietf-savi-dhcp-20 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: Mon, 31 Mar 2014 09:33:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000D_01CF4D07.46513270 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Dear Leaf, Thank you very much for your comments! Your comments are very important and valuable. We have revised the doc = accordingly and submitted a new version. The responses are both at the = behind of this mail and in the attachment. If you have any more comments, please let us know. Best regards, Guang 1. In the 1st paragraph of Page 11, For example, in Figure 1, the attachment from the Non-SAVI Device 1 to = the SAVI Device B should be configured with no attribute. But in Fig.1, Non-SAVI Device 1 is not directly connected to SAVI Device = B. I suppose the draft really means =E2=80=98SAVI Device C=E2=80=99 = here. *** R1: Thank you very much! We have made some modifications to the scenario diagram. It seems a part = of the text is not updated accordingly. We have modified such sentences, = including the following one. 2. In the last paragraph of page 11, In Figure 1, the attachment from the DHCP Relay to the SAVI Device B, = and the attachment from the DHCP Server B to the SAVI Device B should be = configured with this attribute. (for DHCP-Trust Attribute) But in Fig.1, DHCP Relay is not directly connected to SAVI Device B. I = suppose the draft really means =E2=80=98SAVI Device A=E2=80=99 here. *** R2.1: Thanks. We have revised the sentence. As to Fig.1, question for clarification : It sounds to set up a filter = (as the requirement of DHCP-Trust Attribute) inside the SAVI-perimeter. = I guess if the Relay or Server B is directly connected to SAVI Device = and outside the SAVI-perimeter, we still need to set up DHCP-Trust = Attribute for the port of SAVI Device A and B, right? If yes, does it = means the Fig.1 can let the Relay or Server B outside the = SAVI-perimeter? R2.2: Thank you for this comment. Indeed, there is no problem if letting the Relay or Server B outside the = perimeter. In fact, in the ealier versions, they are outside the = perimeter. However, in recent versions, we decide to include them into the = perimeter. On one hand, it is used to distinguish the DHCP server = A(which is outside the perimeter) and the DHCP server B/Relay. On the = other hand, we think the perimeter should be used to separating the = trusted area and the untrusted area. The Relay and Server B should be = trusted, and they are actually the sources of trust. Besides, to confirm with other solutions, perimeter is the place to = perform data packet filtering. Thus, only the attach points with = validating attribute are on the perimeter. 3. Question of clarification on the text in the 3rd paragraph of section = 4.3.1, In this case, SAVI device B doesn=E2=80=99t create a binding for client = A. SAVI device A doesn=E2=80=99t create a binding for client B. But the = SAVI device B is still protected from spoofing from client A and the = SAVI device A is still protected from spoofing from client B. What does =E2=80=9CSAVI device B is still protected from spoofing from = client A=E2=80=9D exactly mean? How can SAVI device B protects from = spoofing from client A? It sounds a little confused. R3: Thank you for this comment. It means, "SAVI device B can avoid receiving spoofing traffic from = client A.". 4. Question of clarification on the text in section 4.3.2, (6) Optional: configure filters on the upstream links to filter out spoofing of local addresses from other networks. Per the definition of =E2=80=98Upstream link=E2=80=99 and = =E2=80=98Downstream link=E2=80=99 in section 3, upstream is for other = network (with gateway router), downstream is for local network. I guess = the text here might mean =E2=80=98filter out spoofing of source = addresses from other networks.=E2=80=99 R4: Thank you for this comment. We cannot prevent other networks from spoofing each other. Thus, we can = just requre local addresses (addresses assigned to local network) will = not be spoofed by the other networks. 5. Question of clarification on the text in the last paragraph of = section 4.3.2, In this way, the points of attachments with Validating attribute (and generally together with attachments of upstream devices) on SAVI devices can form a perimeter separating DHCP clients and trusted devices. The above sentence sounds SAVI devices always form perimeter for = upstream devices. But in general thinking, we always trust devices in = the upstream network. In Fig.1, we should not configure = =E2=80=98DHCP-Trust attribute=E2=80=99 on the port of SAVI Device C for = the Server A through Non-SAVI Device 1, which might means the Client A = and Client B can=E2=80=99t get address assignment from Server A of the = upstream network. Does the above sounds a little confused? R5: Thank you for this comment. This problem is discussed in section4.3.3 P3. We should not trust devices in the upstream network by default unless = some other securty mechanisms are enforced. Client A and Client B can = get address assignment from Server A indirectly from the Relay. 6. Question of clarification on the text in the last paragraph of = section 4.3.2, DHCP-Trust attribute is only configured on the inside links of the = perimeter. The above sentence sounds, even in the SAVI-perimeter, we still need set = up filter for some devices, including relay and server. It sounds we = couldn=E2=80=99t trust the relay and server in the SAVI-perimeter; and = after we configure the DHCP-Trust attribute on the port of the = SAVI-device which connect the relay or server, we start to trust them. = But in general thinking, we always trust devices in the perimeter, and = we don=E2=80=99t need additional SAVI-device to connect some kind of = device in the perimeter. Does the above sounds a little confused? R6:=20 Thank you for this comment. Maybe this comment has been responed by R2.2? 7. Question of clarification on table 3 of BST in section 5: +---------+----------+----------+-----------+-------+ | Anchor | Address | State | Lifetime |TID | +---------+----------+----------+-----------+-------+ | A | IP_1 | BOUND | 65535 |TID_1 | +---------+----------+----------+-----------+-------+ | A | IP_2 | BOUND | 10000 |TID_2 | +---------+----------+----------+-----------+-------+ | B | IP_3 |INIT_BIND | 1 |TID_3 | +---------+----------+----------+-----------+-------+ for Binding State Table It is not quite sure about =E2=80=98A=E2=80=99 and =E2=80=98B=E2=80=99 = in the column of Anchor stands for. Does =E2=80=98A=E2=80=99 stands for = the Client A? It must not stand for SAVI-Device A. =E2=98=BA Per the definition of =E2=80=98Binding anchor=E2=80=99 in section 3, the = anchor is the link-layer property of Clients. It sound usually be the = port of SAVI-device which connect Client A, right? R7.1: Thank you for this comment. 'A' and 'B' do not stand for any element in the diagram. They just = denote some anchor of the clients. On the other hand, I guess the =E2=80=98Creation Time=E2=80=99 of the = entry looks like a field in this table per the usage described in the = section 9. For the reason of consistency, we also have the field of = =E2=80=98Creation Time=E2=80=99 in the FCFS-SAVI DataBase (i.e. = SAVI-SLAAC DB, section 3.1 of RFC6620). R7.2: Thank you for this comment. It is a good suggestion. But I think "Creation Time" is not requried in = binding set up and traffic filtering. For the usage in section 9, the = system time of the store operation is enough. There is no need to = recording the "Creation Time" in binding set up. Besides, adding a new = field in the table will introduce too many modifications... 8. In section 6.3, EVE_DHCP_OPTION_RC: A DHCPv6 Solicitation message with Rapid Commit option is received. I guess looks better than =E2=80=98EVE_DHCP_OPTION_RC, though I = don=E2=80=99t really like the prefix of =E2=80=98EVE_=E2=80=99 here. = =E2=98=BA The prefix of =E2=80=98EVE_=E2=80=99 must stand for Event = here, supposed it really means the additional valid check defined in = section 6.3.2. R8: Thank you for this comment. We have changed =E2=80=98EVE_DHCP_SOLICIT_RC=E2=80=99 to = =E2=80=98EVE_DHCP_OPTION_RC'. Yes, =E2=80=98EVE_=E2=80=99 stands for = Event. We need some terms to denote events to be handled. 9. For Section 6.4.1, I think we could replace its title =E2=80=98From = NO_BIND to Other States=E2=80=99 to be =E2=80=98From NO_BIND to = INIT_BIND=E2=80=99. R9: Thank you for this comment. Well, we find it is alright to make this modification. 10. In Section 6.4.3.2 If the message is DHCPv6 Reply, the SAVI device checks each IA Address option in each IA option. The related binding entry can be determined based on the address in the IAADDR option in the Leasequery-reply message. I personally like =E2=80=98IA Address option=E2=80=99 and = =E2=80=98IAADDR option=E2=80=99 could written in the same. R10: Thank you for this comment. We have changed them to 'IA Address option'. 11. In Section 7.1, Data packets without matching binding entry may trigger this process to set up bindings. This process is not intended to set up a binding whenever a data packet without matched binding entry is received. Does the above 2 sentence sound a little conflict? R10: Thank you for this comment. "Data packets without matching binding entry _may_ trigger this process to set up bindings." We use a "may" to mean this is probable. 12. For Section 7.5.1, I think we could replace its title =E2=80=98From = NO_BIND to Other States=E2=80=99 to be =E2=80=98From NO_BIND to = DETECTION=E2=80=99. R12: Thank you for this comment. Well, we find it is alright to make this modification, too.:) 13. In Section 7.5.3.2, about =E2=80=98IPv6 address=E2=80=99 on page 32, Send a Neighbor Solicitation message with the target address set to the IP address in the corresponding entry. The Neighbor Solicitation is only sent to the attachment which triggers the binding. If there is no response after DAD_TIMEOUT, send another Neighbor Solicitation. Could this additional DAD process be added in Fig.13? R12: Thank you for this comment. But it is there: +-------------+ | | /---------| NO_BIND |<--------\ | ------>| | | TIMEOUT | | +-------------+ |(2nd LQ_DELAY) EVE_DATA_UNMATCH | | | | | | | | | ***1st DAD_TIMEOUT | | | 1st LQ_DELAY /------\ | | | /---------\ | | | | EVE_DATA_CONFLICT | | | | v v | | v | | +-------------+ TIMEOUT +------------+ | | | | ***(2nd DAD_TIMEOUT) | | | \----| DETECTION ------------------------>| RECOVERY ----/ | | | | +-------------+ +------------+ EVE_DATA_LEASEQUERY| /----------\ | EVE_DHCP_RENEW| | | EVE_DHCP_REBIND| +-----v-------+ | | | | | \----| BOUND |<----------/ | | +-------------+ 14. In Section 7.5.3.2, about =E2=80=98IPv6 address=E2=80=99 in page 32, If there is only one identical response, get the source hardware address from the response. Check if the =E2=80=99chaddr=E2=80=99 field (hardware address) = of the LEASEQUERY-REPLY message matches the source hardware address. If the two addresses do not match, the following actions will not be performed. If there is more than one response, if any of the source hardware addresses matches the =E2=80=99chaddr=E2=80=99 field (hardware address) of the LEASEQUERY-REPLY message, the following actions are to be performed. If the LEASEQUERY-REPLY message mentioned here is defined in RFC5007, I = supposed we can=E2=80=99t find the =E2=80=99chaddr=E2=80=99 field in = this message. *** R14: We are sorry this is a careless copy from IPv4 para. LEASEQUERY-REPLY = provides no additional information about the link-layer address or = physical address of the client. Thus we remove this para. 15. Section 7.6, just after Fig. 12 LQ_DELAY: MAX_LEASEQUERY_DELAY This =E2=80=98LQ_DELAY=E2=80=99 looks not a note for Fig. 12, but a note = for Fig. 13, right? If yes, should it be placed after Fig. 13? R15: Thank you for this comment. It has been done. 16. Section 14.2, [savi-fcfs] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFSSAVI: First-Come First-Serve Source-Address Validation for Locally Assigned Addresses", RFC 6620, May 2012. I prefer to replace [savi-fcfs] to be [RFC 6620]. R16: Thank you for this comment. It has been done. 17. Section 14.2, [savi-framework] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., "Source Address Validation Improvement Framework", draft-ietf-savi-framework-06 (work in progress), I prefer to replace [savi-framework] to be [RFC 7039]. It is not is in = the status of =E2=80=98work in progress=E2=80=99 any more. =E2=98=BA R17: Thank you for this comment. It is great! 18. I guess the darft-ietf-savi-dhcp-20 has not support DHCPv6-PD = (RFC3633) for SAVI on the delegated prefix by now, right? R18: Thank you for this comment. Actually, DHCPv6-PD is covered in the very early version of this draft. = But it is moved to the section 7 of SAVI-Framework. -----Original Message----- From: Leaf Yeh [mailto:leaf.yeh.sdo@gmail.com]=20 Sent: Friday, March 28, 2014 1:05 AM To: 'Jun Bi'; 'Jun Bi'; yaoguang@cernet.edu.cn Cc: 'Ted Lemon'; savi@ietf.org Subject: Some findings in the darft-ietf-savi-dhcp-20 Dear Prof. Bi & authors, I=E2=80=99ve read the main part of the darft-ietf-savi-dhcp-20, and = probably got the following findings: 1. In the 1st paragraph of Page 11, For example, in Figure 1, the attachment from the Non-SAVI Device 1 to = the SAVI Device B should be configured with no attribute. But in Fig.1, Non-SAVI Device 1 is not directly connected to SAVI Device = B. I suppose the draft really means =E2=80=98SAVI Device C=E2=80=99 = here. *** 2. In the last paragraph of page 11, In Figure 1, the attachment from the DHCP Relay to the SAVI Device B, = and the attachment from the DHCP Server B to the SAVI Device B should be = configured with this attribute.=20 (for DHCP-Trust Attribute) But in Fig.1, DHCP Relay is not directly connected to SAVI Device B. I = suppose the draft really means =E2=80=98SAVI Device A=E2=80=99 here.=20 *** As to Fig.1, question for clarification : It sounds to set up a filter = (as the requirement of DHCP-Trust Attribute) inside the SAVI-perimeter. = I guess if the Relay or Server B is directly connected to SAVI Device = and outside the SAVI-perimeter, we still need to set up DHCP-Trust = Attribute for the port of SAVI Device A and B, right? If yes, does it = means the Fig.1 can let the Relay or Server B outside the = SAVI-perimeter?=20 3. Question of clarification on the text in the 3rd paragraph of section = 4.3.1, In this case, SAVI device B doesn=E2=80=99t create a = binding for client A. SAVI device A doesn=E2=80=99t create a binding for = client B. But the SAVI device B is still protected from spoofing from = client A and the SAVI device A is still protected from spoofing from = client B.=20 What does =E2=80=9CSAVI device B is still protected from spoofing from = client A=E2=80=9D exactly mean? How can SAVI device B protects from = spoofing from client A? It sounds a little confused. 4. Question of clarification on the text in section 4.3.2, (6) Optional: configure filters on the upstream links to filter out = spoofing of local addresses from other networks. Per the definition of =E2=80=98Upstream link=E2=80=99 and = =E2=80=98Downstream link=E2=80=99 in section 3, upstream is for other = network (with gateway router), downstream is for local network. I guess = the text here might mean =E2=80=98filter out spoofing of source = addresses from other networks.=E2=80=99 5. Question of clarification on the text in the last paragraph of = section 4.3.2, In this way, the points of attachments with = Validating attribute (and generally together with attachments of = upstream devices) on SAVI devices can form a perimeter separating DHCP = clients and trusted devices. The above sentence sounds SAVI devices always form perimeter for = upstream devices. But in general thinking, we always trust devices in = the upstream network. In Fig.1, we should not configure = =E2=80=98DHCP-Trust attribute=E2=80=99 on the port of SAVI Device C for = the Server A through Non-SAVI Device 1, which might means the Client A = and Client B can=E2=80=99t get address assignment from Server A of the = upstream network. Does the above sounds a little confused? 6. Question of clarification on the text in the last paragraph of = section 4.3.2, DHCP-Trust attribute is only configured on the = inside links of the perimeter.=20 The above sentence sounds, even in the SAVI-perimeter, we still need set = up filter for some devices, including relay and server. It sounds we = couldn=E2=80=99t trust the relay and server in the SAVI-perimeter; and = after we configure the DHCP-Trust attribute on the port of the = SAVI-device which connect the relay or server, we start to trust them. = But in general thinking, we always trust devices in the perimeter, and = we don=E2=80=99t need additional SAVI-device to connect some kind of = device in the perimeter. Does the above sounds a little confused? 7. Question of clarification on table 3 of BST in section 5: +---------+----------+----------+-----------+-------+ | Anchor | Address | State | Lifetime |TID | +---------+----------+----------+-----------+-------+ | A | IP_1 | BOUND | 65535 |TID_1 | +---------+----------+----------+-----------+-------+ | A | IP_2 | BOUND | 10000 |TID_2 | +---------+----------+----------+-----------+-------+ | B | IP_3 |INIT_BIND | 1 |TID_3 | +---------+----------+----------+-----------+-------+ for Binding State Table It is not quite sure about =E2=80=98A=E2=80=99 and =E2=80=98B=E2=80=99 = in the column of Anchor stands for. Does =E2=80=98A=E2=80=99 stands for = the Client A? It must not stand for SAVI-Device A. =E2=98=BA Per the = definition of =E2=80=98Binding anchor=E2=80=99 in section 3, the anchor = is the link-layer property of Clients. It sound usually be the port of = SAVI-device which connect Client A, right? On the other hand, I guess the =E2=80=98Creation Time=E2=80=99 of the = entry looks like a field in this table per the usage described in the = section 9. For the reason of consistency, we also have the field of = =E2=80=98Creation Time=E2=80=99 in the FCFS-SAVI DataBase (i.e. = SAVI-SLAAC DB, section 3.1 of RFC6620). 8. In section 6.3, EVE_DHCP_OPTION_RC: A DHCPv6 Solicitation message with Rapid Commit = option is received. I guess =E2=80=98EVE_DHCP_SOLICIT_RC=E2=80=99 looks better than = =E2=80=98EVE_DHCP_OPTION_RC, though I don=E2=80=99t really like the = prefix of =E2=80=98EVE_=E2=80=99 here. =E2=98=BA The prefix of = =E2=80=98EVE_=E2=80=99 must stand for Event here, supposed it really = means the additional valid check defined in section 6.3.2. 9. For Section 6.4.1, I think we could replace its title =E2=80=98From = NO_BIND to Other States=E2=80=99 to be =E2=80=98From NO_BIND to = INIT_BIND=E2=80=99. 10. In Section 6.4.3.2 If the message is DHCPv6 Reply, the SAVI device checks each IA Address = option in each IA option. The related binding entry can be determined based on the address in the = IAADDR option in the Leasequery-reply message. I personally like =E2=80=98IA Address option=E2=80=99 and = =E2=80=98IAADDR option=E2=80=99 could written in the same.=20 11. In Section 7.1, Data packets without matching binding entry may trigger this process to set up = bindings. This process is not intended to set up a binding whenever a data packet = without matched binding entry is received. Does the above 2 sentence sound a little conflict? 12. For Section 7.5.1, I think we could replace its title =E2=80=98From = NO_BIND to Other States=E2=80=99 to be =E2=80=98From NO_BIND to = DETECTION=E2=80=99. 13. In Section 7.5.3.2, about =E2=80=98IPv6 address=E2=80=99 on page 32, = Send a Neighbor Solicitation message with the target address set = to the IP address in the corresponding entry. The Neighbor Solicitation = is only sent to the attachment which triggers the binding. If there is = no response after DAD_TIMEOUT, send another Neighbor Solicitation. Could this additional DAD process be added in Fig.13? =E3=80=80=E3=80=80 14. In Section 7.5.3.2, about =E2=80=98IPv6 address=E2=80=99 in page 32, = If there is only one identical response, get the source hardware = address from the response. Check if the =E2=80=99chaddr=E2=80=99 field = (hardware address) of the LEASEQUERY-REPLY message matches the source = hardware address. If the two addresses do not match, the following actions will not be = performed. If there is more than one response, if any of the source = hardware addresses matches the =E2=80=99chaddr=E2=80=99 field (hardware = address) of the LEASEQUERY-REPLY message, the following actions are to = be performed. If the LEASEQUERY-REPLY message mentioned here is defined in RFC5007, I = supposed we can=E2=80=99t find the =E2=80=99chaddr=E2=80=99 field in = this message. *** 15. Section 7.6, just after Fig. 12 LQ_DELAY: MAX_LEASEQUERY_DELAY This =E2=80=98LQ_DELAY=E2=80=99 looks not a note for Fig. 12, but a note = for Fig. 13, right? If yes, should it be placed after Fig. 13? 16. Section 14.2, [savi-fcfs] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFSSAVI: First-Come First-Serve Source-Address Validation for Locally Assigned = Addresses", RFC 6620, May 2012. I prefer to replace [savi-fcfs] to be [RFC 6620]. 17. Section 14.2, [savi-framework] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., "Source = Address Validation Improvement Framework", draft-ietf-savi-framework-06 (work in progress), I prefer to replace [savi-framework] to be [RFC 7039]. It is not is in = the status of =E2=80=98work in progress=E2=80=99 any more. =E2=98=BA 18. I guess the darft-ietf-savi-dhcp-20 has not support DHCPv6-PD = (RFC3633) for SAVI on the delegated prefix by now, right? Anyway, I am not yet aware the discussion history in SAVI-WG before; the = above might be some additional comments, might be something discussed = before. Hope some of the above could be a help for the text in this = draft, and I am really looking forwarding to the advance of this = draft-ietf-savi-dhcp. Best Regards, Leaf ------=_NextPart_000_000D_01CF4D07.46513270 Content-Type: text/plain; name="review.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="review.txt" Dear Prof. Bi & authors, I=E2=80=99ve read the main part of the darft-ietf-savi-dhcp-20, and = probably got the following findings: 1. In the 1st paragraph of Page 11, For example, in Figure 1, the attachment from the Non-SAVI Device 1 to = the SAVI Device B should be configured with no attribute. But in Fig.1, Non-SAVI Device 1 is not directly connected to SAVI Device = B. I suppose the draft really means =E2=80=98SAVI Device C=E2=80=99 = here. *** R1: Thank you very much! We have made some modifications to the scenario diagram. It seems a part = of the text is not updated accordingly. We have modified such sentences, = including the following one. 2. In the last paragraph of page 11, In Figure 1, the attachment from the DHCP Relay to the SAVI Device B, = and the attachment from the DHCP Server B to the SAVI Device B should be = configured with this attribute. (for DHCP-Trust Attribute) But in Fig.1, DHCP Relay is not directly connected to SAVI Device B. I = suppose the draft really means =E2=80=98SAVI Device A=E2=80=99 here. *** R2.1: Thanks. We have revised the sentence. As to Fig.1, question for clarification : It sounds to set up a filter = (as the requirement of DHCP-Trust Attribute) inside the SAVI-perimeter. = I guess if the Relay or Server B is directly connected to SAVI Device = and outside the SAVI-perimeter, we still need to set up DHCP-Trust = Attribute for the port of SAVI Device A and B, right? If yes, does it = means the Fig.1 can let the Relay or Server B outside the = SAVI-perimeter? R2.2: Thank you for this comment. Indeed, there is no problem if letting the Relay or Server B outside the = perimeter. In fact, in the ealier versions, they are outside the = perimeter. However, in recent versions, we decide to include them into the = perimeter. On one hand, it is used to distinguish the DHCP server = A(which is outside the perimeter) and the DHCP server B/Relay. On the = other hand, we think the perimeter should be used to separating the = trusted area and the untrusted area. The Relay and Server B should be = trusted, and they are actually the sources of trust. Besides, to confirm with other solutions, perimeter is the place to = perform data packet filtering. Thus, only the attach points with = validating attribute are on the perimeter. 3. Question of clarification on the text in the 3rd paragraph of section = 4.3.1, In this case, SAVI device B doesn=E2=80=99t create a binding for client = A. SAVI device A doesn=E2=80=99t create a binding for client B. But the = SAVI device B is still protected from spoofing from client A and the = SAVI device A is still protected from spoofing from client B. What does =E2=80=9CSAVI device B is still protected from spoofing from = client A=E2=80=9D exactly mean? How can SAVI device B protects from = spoofing from client A? It sounds a little confused. R3: Thank you for this comment. It means, "SAVI device B can avoid receiving spoofing traffic from = client A.". 4. Question of clarification on the text in section 4.3.2, (6) Optional: configure filters on the upstream links to filter out spoofing of local addresses from other networks. Per the definition of =E2=80=98Upstream link=E2=80=99 and = =E2=80=98Downstream link=E2=80=99 in section 3, upstream is for other = network (with gateway router), downstream is for local network. I guess = the text here might mean =E2=80=98filter out spoofing of source = addresses from other networks.=E2=80=99 R4: Thank you for this comment. We cannot prevent other networks from spoofing each other. Thus, we can = just requre local addresses (addresses assigned to local network) will = not be spoofed by the other networks. 5. Question of clarification on the text in the last paragraph of = section 4.3.2, In this way, the points of attachments with Validating attribute (and generally together with attachments of upstream devices) on SAVI devices can form a perimeter separating DHCP clients and trusted devices. The above sentence sounds SAVI devices always form perimeter for = upstream devices. But in general thinking, we always trust devices in = the upstream network. In Fig.1, we should not configure = =E2=80=98DHCP-Trust attribute=E2=80=99 on the port of SAVI Device C for = the Server A through Non-SAVI Device 1, which might means the Client A = and Client B can=E2=80=99t get address assignment from Server A of the = upstream network. Does the above sounds a little confused? R5: Thank you for this comment. This problem is discussed in section4.3.3 P3. We should not trust devices in the upstream network by default unless = some other securty mechanisms are enforced. Client A and Client B can = get address assignment from Server A indirectly from the Relay. 6. Question of clarification on the text in the last paragraph of = section 4.3.2, DHCP-Trust attribute is only configured on the inside links of the = perimeter. The above sentence sounds, even in the SAVI-perimeter, we still need set = up filter for some devices, including relay and server. It sounds we = couldn=E2=80=99t trust the relay and server in the SAVI-perimeter; and = after we configure the DHCP-Trust attribute on the port of the = SAVI-device which connect the relay or server, we start to trust them. = But in general thinking, we always trust devices in the perimeter, and = we don=E2=80=99t need additional SAVI-device to connect some kind of = device in the perimeter. Does the above sounds a little confused? R6:=20 Thank you for this comment. Maybe this comment has been responed by R2.2? 7. Question of clarification on table 3 of BST in section 5: +---------+----------+----------+-----------+-------+ | Anchor | Address | State | Lifetime |TID | +---------+----------+----------+-----------+-------+ | A | IP_1 | BOUND | 65535 |TID_1 | +---------+----------+----------+-----------+-------+ | A | IP_2 | BOUND | 10000 |TID_2 | +---------+----------+----------+-----------+-------+ | B | IP_3 |INIT_BIND | 1 |TID_3 | +---------+----------+----------+-----------+-------+ for Binding State Table It is not quite sure about =E2=80=98A=E2=80=99 and =E2=80=98B=E2=80=99 = in the column of Anchor stands for. Does =E2=80=98A=E2=80=99 stands for = the Client A? It must not stand for SAVI-Device A. =E2=98=BA Per the definition of =E2=80=98Binding anchor=E2=80=99 in section 3, the = anchor is the link-layer property of Clients. It sound usually be the = port of SAVI-device which connect Client A, right? R7.1: Thank you for this comment. 'A' and 'B' do not stand for any element in the diagram. They just = denote some anchor of the clients. On the other hand, I guess the =E2=80=98Creation Time=E2=80=99 of the = entry looks like a field in this table per the usage described in the = section 9. For the reason of consistency, we also have the field of = =E2=80=98Creation Time=E2=80=99 in the FCFS-SAVI DataBase (i.e. = SAVI-SLAAC DB, section 3.1 of RFC6620). R7.2: Thank you for this comment. It is a good suggestion. But I think "Creation Time" is not requried in = binding set up and traffic filtering. For the usage in section 9, the = system time of the store operation is enough. There is no need to = recording the "Creation Time" in binding set up. Besides, adding a new = field in the table will introduce too many modifications... 8. In section 6.3, EVE_DHCP_OPTION_RC: A DHCPv6 Solicitation message with Rapid Commit option is received. I guess looks better than =E2=80=98EVE_DHCP_OPTION_RC, though I = don=E2=80=99t really like the prefix of =E2=80=98EVE_=E2=80=99 here. = =E2=98=BA The prefix of =E2=80=98EVE_=E2=80=99 must stand for Event = here, supposed it really means the additional valid check defined in = section 6.3.2. R8: Thank you for this comment. We have changed =E2=80=98EVE_DHCP_SOLICIT_RC=E2=80=99 to = =E2=80=98EVE_DHCP_OPTION_RC'. Yes, =E2=80=98EVE_=E2=80=99 stands for = Event. We need some terms to denote events to be handled. 9. For Section 6.4.1, I think we could replace its title =E2=80=98From = NO_BIND to Other States=E2=80=99 to be =E2=80=98From NO_BIND to = INIT_BIND=E2=80=99. R9: Thank you for this comment. Well, we find it is alright to make this modification. 10. In Section 6.4.3.2 If the message is DHCPv6 Reply, the SAVI device checks each IA Address option in each IA option. The related binding entry can be determined based on the address in the IAADDR option in the Leasequery-reply message. I personally like =E2=80=98IA Address option=E2=80=99 and = =E2=80=98IAADDR option=E2=80=99 could written in the same. R10: Thank you for this comment. We have changed them to 'IA Address option'. 11. In Section 7.1, Data packets without matching binding entry may trigger this process to set up bindings. This process is not intended to set up a binding whenever a data packet without matched binding entry is received. Does the above 2 sentence sound a little conflict? R10: Thank you for this comment. "Data packets without matching binding entry _may_ trigger this process to set up bindings." We use a "may" to mean this is probable. 12. For Section 7.5.1, I think we could replace its title =E2=80=98From = NO_BIND to Other States=E2=80=99 to be =E2=80=98From NO_BIND to = DETECTION=E2=80=99. R12: Thank you for this comment. Well, we find it is alright to make this modification, too.:) 13. In Section 7.5.3.2, about =E2=80=98IPv6 address=E2=80=99 on page 32, Send a Neighbor Solicitation message with the target address set to the IP address in the corresponding entry. The Neighbor Solicitation is only sent to the attachment which triggers the binding. If there is no response after DAD_TIMEOUT, send another Neighbor Solicitation. Could this additional DAD process be added in Fig.13? R12: Thank you for this comment. But it is there: +-------------+ | | /---------| NO_BIND |<--------\ | ------>| | | TIMEOUT | | +-------------+ |(2nd LQ_DELAY) EVE_DATA_UNMATCH | | | | | | | | | ***1st DAD_TIMEOUT | | | 1st LQ_DELAY /------\ | | | /---------\ | | | | EVE_DATA_CONFLICT | | | | v v | | v | | +-------------+ TIMEOUT +------------+ | | | | ***(2nd DAD_TIMEOUT) | | | \----| DETECTION ------------------------>| RECOVERY ----/ | | | | +-------------+ +------------+ EVE_DATA_LEASEQUERY| /----------\ | EVE_DHCP_RENEW| | | EVE_DHCP_REBIND| +-----v-------+ | | | | | \----| BOUND |<----------/ | | +-------------+ 14. In Section 7.5.3.2, about =E2=80=98IPv6 address=E2=80=99 in page 32, If there is only one identical response, get the source hardware address from the response. Check if the =E2=80=99chaddr=E2=80=99 field (hardware address) = of the LEASEQUERY-REPLY message matches the source hardware address. If the two addresses do not match, the following actions will not be performed. If there is more than one response, if any of the source hardware addresses matches the =E2=80=99chaddr=E2=80=99 field (hardware address) of the LEASEQUERY-REPLY message, the following actions are to be performed. If the LEASEQUERY-REPLY message mentioned here is defined in RFC5007, I = supposed we can=E2=80=99t find the =E2=80=99chaddr=E2=80=99 field in = this message. *** R14: We are sorry this is a careless copy from IPv4 para. LEASEQUERY-REPLY = provides no additional information about the link-layer address or = physical address of the client. Thus we remove this para. 15. Section 7.6, just after Fig. 12 LQ_DELAY: MAX_LEASEQUERY_DELAY This =E2=80=98LQ_DELAY=E2=80=99 looks not a note for Fig. 12, but a note = for Fig. 13, right? If yes, should it be placed after Fig. 13? R15: Thank you for this comment. It has been done. 16. Section 14.2, [savi-fcfs] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFSSAVI: First-Come First-Serve Source-Address Validation for Locally Assigned Addresses", RFC 6620, May 2012. I prefer to replace [savi-fcfs] to be [RFC 6620]. R16: Thank you for this comment. It has been done. 17. Section 14.2, [savi-framework] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., "Source Address Validation Improvement Framework", draft-ietf-savi-framework-06 (work in progress), I prefer to replace [savi-framework] to be [RFC 7039]. It is not is in = the status of =E2=80=98work in progress=E2=80=99 any more. =E2=98=BA R17: Thank you for this comment. It is great! 18. I guess the darft-ietf-savi-dhcp-20 has not support DHCPv6-PD = (RFC3633) for SAVI on the delegated prefix by now, right? R18: Thank you for this comment. Actually, DHCPv6-PD is covered in the very early version of this draft. = But it is moved to the section 7 of SAVI-Framework. Anyway, I am not yet aware the discussion history in SAVI-WG before; the = above might be some additional comments, might be something discussed = before. Hope some of the above could be a help for the text in this = draft, and I am really looking forwarding to the advance of this = draft-ietf-savi-dhcp. Best Regards, Leaf ------=_NextPart_000_000D_01CF4D07.46513270-- From nobody Mon Mar 31 11:03:35 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 5416A1A6F36 for ; Mon, 31 Mar 2014 11:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.3 X-Spam-Level: * X-Spam-Status: No, score=1.3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no 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 cqPboVeITUv9 for ; Mon, 31 Mar 2014 11:03:31 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5001A089A for ; Mon, 31 Mar 2014 11:03:31 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id v10so8355236pde.11 for ; Mon, 31 Mar 2014 11:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=XT+ZBUjL3V+76/VjdgPKc0+aaCok6i2fvKHwucJfqBU=; b=qI9nWfLc1MNr0Q0LVnkp/qX0VHzjT8k6rMG5dinQ64KPKRf0CwcAhVVLa9RT8voNrZ 28/yS3WbnVc/OBvg61elOuNn94sRebjpV6vbcPftdBmx1Fz78Vu8DkQp8BUoaqrxmFIM ZbmOvjzqsrq6kX1wVXFywNE3+bshzfP2XvHCKXUCq8xFl2wR5paChjhYISfSDxTjPTpM pN8uA4vQiAwPNT8x5STQ1dT9tJWqlKdU5SDZWpt3ZZJ4MPYnaYFUS9Iqz4BPvTLtUJJW S66T7CEy2fPFf106tX3Ok/gt9HVp9TBuUFimqHxsnmdJhXwQh09dtjv9hVF0CJrseTeM uCYg== X-Received: by 10.67.23.135 with SMTP id ia7mr26568460pad.5.1396289007883; Mon, 31 Mar 2014 11:03:27 -0700 (PDT) Received: from PC ([111.199.88.46]) by mx.google.com with ESMTPSA id te2sm43734049pac.25.2014.03.31.11.03.18 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 31 Mar 2014 11:03:27 -0700 (PDT) From: "Leaf Yeh" To: "'Guang Yao'" , "'Jun Bi'" , "'Jun Bi'" References: <53345a28.e15f440a.76a1.430a@mx.google.com> <000c01cf4cc4$382c92e0$a885b8a0$@cernet.edu.cn> In-Reply-To: <000c01cf4cc4$382c92e0$a885b8a0$@cernet.edu.cn> Date: Tue, 1 Apr 2014 02:01:46 +0800 Message-ID: <5339adef.42e7420a.490c.ffff8eac@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHXgVSJEKldWHfW8Xp2lGM95er5l5rqg3LAgAAvUeA= Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/savi/TAlfmgagm0iUeFO5rq-qiGi-XIc Cc: savi@ietf.org, 'Ted Lemon' Subject: Re: [savi] Some findings in the darft-ietf-savi-dhcp-20 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: Mon, 31 Mar 2014 18:03:34 -0000 Leaf - As to Fig.1, question for clarification : It sounds to set up a = filter (as the requirement of DHCP-Trust Attribute) inside the = SAVI-perimeter. I guess if the Relay or Server B is directly connected = to SAVI Device and outside the SAVI-perimeter, we still need to set up = DHCP-Trust Attribute for the port of SAVI Device A and B, right? If yes, = does it means the Fig.1 can let the Relay or Server B outside the = SAVI-perimeter? Guang - R2.2: ...Indeed, there is no problem if letting the Relay or = Server B outside the perimeter. In fact, in the ealier versions, they = are outside the perimeter. However, in recent versions, we decide to = include them into the perimeter.=20 The above decision sounds you make that Relay is the for the connection = with the upstream network. Guang - On one hand, it is used to distinguish the DHCP server A(which = is outside the perimeter) and the DHCP server B/Relay. On the other = hand, we think the perimeter should be used to separating the trusted = area and the untrusted area. The Relay and Server B should be trusted, = and they are actually the sources of trust.=20 But you still need DHCP-Trust Attribute for them. It seem DHCP-Trust = Attribute make them to be trust. How about if we just trust the Relay = and Server B in the SAVI-perimeter without the additional permission, = because they are connected to the Trust Port, (which was introduced by = RFC662.) Guang - Besides, to confirm with other solutions, perimeter is the place = to perform data packet filtering. Thus, only the attach points with = validating attribute are on the perimeter. It make me not quite sure you want to configure Validating attribute for = the upstream network, which looks outside of the SAVI-perimeter in = Fig.1.=20 Per the description in section 4 of RFC7039, The IP source = addresses in packets passing the protection perimeter are validated by = the ingress SAVI instance, but no further validation takes place as long = as the packets remain within or leave the protection perimeter., = I suppose it is not necessary to let upstream network outside the = SAVI-perimeter. Leaf - What does =E2=80=9CSAVI device B is still protected from spoofing = from client A=E2=80=9D exactly mean? How can SAVI device B protects from = spoofing from client A? It sounds a little confused. Guang - R3:...It means, "SAVI device B can avoid receiving spoofing = traffic from client A.". The above statement sounds SAVI device A can avoid receiving spoofing = traffic from client A, then 'SAVI device B can avoid receiving spoofing = traffic from client A' because of the SAVI perimeter. I doubt the = necessary text of 'SAVI device B is still protected from spoofing from = client A' here. Leaf -4. Question of clarification on the text in section 4.3.2, = (6) Optional: configure filters on the upstream links to filter = out spoofing of local addresses from other networks.... Guang - R4:...We cannot prevent other networks from spoofing each other. = Thus, we can just requre local addresses (addresses assigned to local = network) will not be spoofed by the other networks. Thanks for your explanation here, but that method sounds ingress = filtering (or uRPF) to me. Meanwhile, the 'other network' in the = definition of 'Upstream link' seems a little vague for me. I guess it is = usually we don=E2=80=99t use SAVI-switch to connect to the upstream = network, we use a gateway or router. So the (6) of SAVI-DHCP Perimeter = Configuration Guideline seems unnecessary. I mean we don't usually use = SAVI-switch to form the SAVI-perimeter against the upstream link or = network. Leaf - 5. Question of clarification on the text in the last paragraph of = section 4.3.2, In this way, the points of attachments with = Validating attribute (and generally together with attachments of = upstream devices) on SAVI devices can form a perimeter separating DHCP = clients and trusted devices. The above sentence sounds SAVI devices always form perimeter for = upstream devices. But in general thinking, we always trust devices in = the upstream network... Guang - R5:...We should not trust devices in the upstream network by = default unless some other securty mechanisms are enforced. =20 Why not if the upstream network is in the SAVI-perimeter? Guang - R7.1: ...'A' and 'B' do not stand for any element in the = diagram. They just denote some anchor of the clients. How about replace A to be 'Port_1' in the instance of Fig.3? Leaf - On the other hand, I guess the =E2=80=98Creation Time=E2=80=99 of = the entry looks like a field in this table per the usage described in = the section 9. For the reason of consistency, we also have the field of = =E2=80=98Creation Time=E2=80=99 in the FCFS-SAVI DataBase (i.e. = SAVI-SLAAC DB, section 3.1 of RFC6620). Guang - R7.2:...It is a good suggestion. ... For the usage in section 9, = the system time of the store operation is enough. There is no need to = recording the "Creation Time" in binding set up. Besides, adding a new = field in the table will introduce too many modifications... Per the description in section 9, Binding entries MAY be saved = into non-volatile storage whenever a new binding entry changes to BOUND = state. ... The time when each binding entry is established is also = saved., I suppose 'Creation Time' could support this action. Leaf...though I don=E2=80=99t really like the prefix of = =E2=80=98EVE_=E2=80=99 here. =E2=98=BA The prefix of = =E2=80=98EVE_=E2=80=99 must stand for Event here, supposed it really = means the additional valid check defined in section 6.3.2. Guang - R8: ...We have changed =E2=80=98EVE_DHCP_SOLICIT_RC=E2=80=99 to = =E2=80=98EVE_DHCP_OPTION_RC'. Yes, =E2=80=98EVE_=E2=80=99 stands for = Event. We need some terms to denote events to be handled. I guess the text in the draft will not cause any misunderstanding if you = delete the prefix of 'EVE_'. Right? Leaf - In Section 7.1, Data packets without matching binding = entry may trigger this process to set up bindings. This process is not intended to set up a binding whenever a data = packet without matched binding entry is received. Does the above 2 sentence sound a little conflict? Guang - R10: ... "Data packets without matching binding entry _may_ = trigger this process to set up bindings." We use a "may" to mean this is = probable. Can I say ' This process is intended to set up a binding whenever a data = packet without matched binding entry is received.' ? Leaf -13. In Section 7.5.3.2, about =E2=80=98IPv6 address=E2=80=99 on = page 32, Send a Neighbor Solicitation message with the target = address set to the IP address in the corresponding entry. The Neighbor = Solicitation is only sent to the attachment which triggers the binding. = If there is no response after DAD_TIMEOUT, send another Neighbor = Solicitation. Could this additional DAD process be added in Fig.13? Guang - R12: ... But it is there:... I am not quite sure it is a good decision to delete this DAD process = after EVE_DATA_LEASEQUERY (in the state of RECOVERY). It looks not the = same as that DAD after EVE_DATA_UNMATCH (in the state of DETECTION), if = you keep the text in section 7.5.2, The messages MUST NOT be sent = to the attachment from which the triggering packet is received.. = The DAD process after EVE_DATA_LEASEQUERY looks that 'The Neighbor = Solicitation is only sent to the attachment which triggers the binding.' = I personally prefer to combine these 2 DAD process, which means to sent = DAD_NS to all the ports of SAVI-switch. Best Regards, Leaf -----Original Message----- From: Guang Yao [mailto:yaoguang@cernet.edu.cn]=20 Sent: Monday, March 31, 2014 5:33 PM To: 'Leaf Yeh'; 'Jun Bi'; 'Jun Bi' Cc: 'Ted Lemon'; savi@ietf.org Subject: RE: Some findings in the darft-ietf-savi-dhcp-20 Dear Leaf, Thank you very much for your comments! Your comments are very important and valuable. We have revised the doc = accordingly and submitted a new version. The responses are both at the = behind of this mail and in the attachment. If you have any more comments, please let us know. Best regards, Guang 1. In the 1st paragraph of Page 11, For example, in Figure 1, the attachment from the Non-SAVI Device 1 to = the SAVI Device B should be configured with no attribute. But in Fig.1, Non-SAVI Device 1 is not directly connected to SAVI Device = B. I suppose the draft really means =E2=80=98SAVI Device C=E2=80=99 = here. *** R1: Thank you very much! We have made some modifications to the scenario diagram. It seems a part = of the text is not updated accordingly. We have modified such sentences, = including the following one. 2. In the last paragraph of page 11, In Figure 1, the attachment from the DHCP Relay to the SAVI Device B, = and the attachment from the DHCP Server B to the SAVI Device B should be = configured with this attribute. (for DHCP-Trust Attribute) But in Fig.1, DHCP Relay is not directly connected to SAVI Device B. I = suppose the draft really means =E2=80=98SAVI Device A=E2=80=99 here. *** R2.1: Thanks. We have revised the sentence. As to Fig.1, question for clarification : It sounds to set up a filter = (as the requirement of DHCP-Trust Attribute) inside the SAVI-perimeter. = I guess if the Relay or Server B is directly connected to SAVI Device = and outside the SAVI-perimeter, we still need to set up DHCP-Trust = Attribute for the port of SAVI Device A and B, right? If yes, does it = means the Fig.1 can let the Relay or Server B outside the = SAVI-perimeter? R2.2: Thank you for this comment. Indeed, there is no problem if letting the Relay or Server B outside the = perimeter. In fact, in the ealier versions, they are outside the = perimeter. However, in recent versions, we decide to include them into the = perimeter. On one hand, it is used to distinguish the DHCP server = A(which is outside the perimeter) and the DHCP server B/Relay. On the = other hand, we think the perimeter should be used to separating the = trusted area and the untrusted area. The Relay and Server B should be = trusted, and they are actually the sources of trust. Besides, to confirm with other solutions, perimeter is the place to = perform data packet filtering. Thus, only the attach points with = validating attribute are on the perimeter. 3. Question of clarification on the text in the 3rd paragraph of section = 4.3.1, In this case, SAVI device B doesn=E2=80=99t create a = binding for client A. SAVI device A doesn=E2=80=99t create a binding for = client B. But the SAVI device B is still protected from spoofing from = client A and the SAVI device A is still protected from spoofing from = client B. What does =E2=80=9CSAVI device B is still protected from spoofing from = client A=E2=80=9D exactly mean? How can SAVI device B protects from = spoofing from client A? It sounds a little confused. R3: Thank you for this comment. It means, "SAVI device B can avoid receiving spoofing traffic from = client A.". 4. Question of clarification on the text in section 4.3.2, (6) Optional: configure filters on the upstream links to filter out = spoofing of local addresses from other networks. Per the definition of =E2=80=98Upstream link=E2=80=99 and = =E2=80=98Downstream link=E2=80=99 in section 3, upstream is for other = network (with gateway router), downstream is for local network. I guess = the text here might mean =E2=80=98filter out spoofing of source = addresses from other networks.=E2=80=99 R4: Thank you for this comment. We cannot prevent other networks from spoofing each other. Thus, we can = just requre local addresses (addresses assigned to local network) will = not be spoofed by the other networks. 5. Question of clarification on the text in the last paragraph of = section 4.3.2, In this way, the points of attachments with = Validating attribute (and generally together with attachments of = upstream devices) on SAVI devices can form a perimeter separating DHCP = clients and trusted devices. The above sentence sounds SAVI devices always form perimeter for = upstream devices. But in general thinking, we always trust devices in = the upstream network. In Fig.1, we should not configure = =E2=80=98DHCP-Trust attribute=E2=80=99 on the port of SAVI Device C for = the Server A through Non-SAVI Device 1, which might means the Client A = and Client B can=E2=80=99t get address assignment from Server A of the = upstream network. Does the above sounds a little confused? R5: Thank you for this comment. This problem is discussed in section4.3.3 P3. We should not trust devices in the upstream network by default unless = some other securty mechanisms are enforced. Client A and Client B can = get address assignment from Server A indirectly from the Relay. 6. Question of clarification on the text in the last paragraph of = section 4.3.2, DHCP-Trust attribute is only configured on the = inside links of the perimeter. The above sentence sounds, even in the SAVI-perimeter, we still need set = up filter for some devices, including relay and server. It sounds we = couldn=E2=80=99t trust the relay and server in the SAVI-perimeter; and = after we configure the DHCP-Trust attribute on the port of the = SAVI-device which connect the relay or server, we start to trust them. = But in general thinking, we always trust devices in the perimeter, and = we don=E2=80=99t need additional SAVI-device to connect some kind of = device in the perimeter. Does the above sounds a little confused? R6:=20 Thank you for this comment. Maybe this comment has been responed by R2.2? 7. Question of clarification on table 3 of BST in section 5: +---------+----------+----------+-----------+-------+ | Anchor | Address | State | Lifetime |TID | +---------+----------+----------+-----------+-------+ | A | IP_1 | BOUND | 65535 |TID_1 | +---------+----------+----------+-----------+-------+ | A | IP_2 | BOUND | 10000 |TID_2 | +---------+----------+----------+-----------+-------+ | B | IP_3 |INIT_BIND | 1 |TID_3 | +---------+----------+----------+-----------+-------+ for Binding State Table It is not quite sure about =E2=80=98A=E2=80=99 and =E2=80=98B=E2=80=99 = in the column of Anchor stands for. Does =E2=80=98A=E2=80=99 stands for = the Client A? It must not stand for SAVI-Device A. =E2=98=BA Per the = definition of =E2=80=98Binding anchor=E2=80=99 in section 3, the anchor = is the link-layer property of Clients. It sound usually be the port of = SAVI-device which connect Client A, right? R7.1: Thank you for this comment. 'A' and 'B' do not stand for any element in the diagram. They just = denote some anchor of the clients. On the other hand, I guess the =E2=80=98Creation Time=E2=80=99 of the = entry looks like a field in this table per the usage described in the = section 9. For the reason of consistency, we also have the field of = =E2=80=98Creation Time=E2=80=99 in the FCFS-SAVI DataBase (i.e. = SAVI-SLAAC DB, section 3.1 of RFC6620). R7.2: Thank you for this comment. It is a good suggestion. But I think "Creation Time" is not requried in = binding set up and traffic filtering. For the usage in section 9, the = system time of the store operation is enough. There is no need to = recording the "Creation Time" in binding set up. Besides, adding a new = field in the table will introduce too many modifications... 8. In section 6.3, EVE_DHCP_OPTION_RC: A DHCPv6 Solicitation message with Rapid Commit = option is received. I guess looks better than =E2=80=98EVE_DHCP_OPTION_RC, though I = don=E2=80=99t really like the prefix of =E2=80=98EVE_=E2=80=99 here. = =E2=98=BA The prefix of =E2=80=98EVE_=E2=80=99 must stand for Event = here, supposed it really means the additional valid check defined in = section 6.3.2. R8: Thank you for this comment. We have changed =E2=80=98EVE_DHCP_SOLICIT_RC=E2=80=99 to = =E2=80=98EVE_DHCP_OPTION_RC'. Yes, =E2=80=98EVE_=E2=80=99 stands for = Event. We need some terms to denote events to be handled. 9. For Section 6.4.1, I think we could replace its title =E2=80=98From = NO_BIND to Other States=E2=80=99 to be =E2=80=98From NO_BIND to = INIT_BIND=E2=80=99. R9: Thank you for this comment. Well, we find it is alright to make this modification. 10. In Section 6.4.3.2 If the message is DHCPv6 Reply, the SAVI device checks each IA Address = option in each IA option. The related binding entry can be determined based on the address in the = IAADDR option in the Leasequery-reply message. I personally like =E2=80=98IA Address option=E2=80=99 and = =E2=80=98IAADDR option=E2=80=99 could written in the same. R10: Thank you for this comment. We have changed them to 'IA Address option'. 11. In Section 7.1, Data packets without matching binding entry may trigger this process to set up = bindings. This process is not intended to set up a binding whenever a data packet = without matched binding entry is received. Does the above 2 sentence sound a little conflict? R10: Thank you for this comment. "Data packets without matching binding entry _may_ trigger this process to set up = bindings." We use a "may" to mean this is probable. 12. For Section 7.5.1, I think we could replace its title =E2=80=98From = NO_BIND to Other States=E2=80=99 to be =E2=80=98From NO_BIND to = DETECTION=E2=80=99. R12: Thank you for this comment. Well, we find it is alright to make this modification, too.:) 13. In Section 7.5.3.2, about =E2=80=98IPv6 address=E2=80=99 on page 32, = Send a Neighbor Solicitation message with the target address set = to the IP address in the corresponding entry. The Neighbor Solicitation = is only sent to the attachment which triggers the binding. If there is = no response after DAD_TIMEOUT, send another Neighbor Solicitation. Could this additional DAD process be added in Fig.13? R12: Thank you for this comment. But it is there: +-------------+ | | /---------| NO_BIND |<--------\ | ------>| | | TIMEOUT | | +-------------+ |(2nd LQ_DELAY) EVE_DATA_UNMATCH | | | | | | | | | ***1st DAD_TIMEOUT | | | 1st LQ_DELAY /------\ | | | /---------\ | | | | EVE_DATA_CONFLICT | | | | v v | | v | | +-------------+ TIMEOUT +------------+ | | | | ***(2nd DAD_TIMEOUT) | | | \----| DETECTION ------------------------>| RECOVERY ----/ | | | | +-------------+ +------------+ EVE_DATA_LEASEQUERY| /----------\ | EVE_DHCP_RENEW| | | EVE_DHCP_REBIND| +-----v-------+ | | | | | \----| BOUND |<----------/ | | +-------------+ 14. In Section 7.5.3.2, about =E2=80=98IPv6 address=E2=80=99 in page 32, = If there is only one identical response, get the source hardware = address from the response. Check if the =E2=80=99chaddr=E2=80=99 field = (hardware address) of the LEASEQUERY-REPLY message matches the source = hardware address. If the two addresses do not match, the following actions will not be = performed. If there is more than one response, if any of the source = hardware addresses matches the =E2=80=99chaddr=E2=80=99 field (hardware = address) of the LEASEQUERY-REPLY message, the following actions are to = be performed. If the LEASEQUERY-REPLY message mentioned here is defined in RFC5007, I = supposed we can=E2=80=99t find the =E2=80=99chaddr=E2=80=99 field in = this message. *** R14: We are sorry this is a careless copy from IPv4 para. LEASEQUERY-REPLY = provides no additional information about the link-layer address or = physical address of the client. Thus we remove this para. 15. Section 7.6, just after Fig. 12 LQ_DELAY: MAX_LEASEQUERY_DELAY This =E2=80=98LQ_DELAY=E2=80=99 looks not a note for Fig. 12, but a note = for Fig. 13, right? If yes, should it be placed after Fig. 13? R15: Thank you for this comment. It has been done. 16. Section 14.2, [savi-fcfs] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFSSAVI: First-Come First-Serve Source-Address Validation for Locally Assigned = Addresses", RFC 6620, May 2012. I prefer to replace [savi-fcfs] to be [RFC 6620]. R16: Thank you for this comment. It has been done. 17. Section 14.2, [savi-framework] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., "Source = Address Validation Improvement Framework", draft-ietf-savi-framework-06 (work in progress), I prefer to replace [savi-framework] to be [RFC 7039]. It is not is in = the status of =E2=80=98work in progress=E2=80=99 any more. =E2=98=BA R17: Thank you for this comment. It is great! 18. I guess the darft-ietf-savi-dhcp-20 has not support DHCPv6-PD = (RFC3633) for SAVI on the delegated prefix by now, right? R18: Thank you for this comment. Actually, DHCPv6-PD is covered in the very early version of this draft. = But it is moved to the section 7 of SAVI-Framework. From nobody Mon Mar 31 18:50:50 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 B4F141A6F2C for ; Mon, 31 Mar 2014 18:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 7Hwg8K756vM2 for ; Mon, 31 Mar 2014 18:50:47 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id E6DC71A6F20 for ; Mon, 31 Mar 2014 18:50:46 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id md12so9074992pbc.37 for ; Mon, 31 Mar 2014 18:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=8ZqZi5QLccxe8fWV/+3pwiXZprwFDo8nB923uHlmRe8=; b=C7fw84K67UC4eOJqtDgaiMa2lRy+Z53TO5lAEEz2ur8BlNG4R4WTa6bXgWwO20VbV5 ybGP+V3uZxd2d9ZrBSXyuwJCKSBJFsZllFq9gUqmnz455kgrCl4wi/gHL5TusvWxfM94 2g9AB26INw0skIpuMHEEASlKzjI59T1g4EEF1em3Plf7SC4jMOzLunECc8RJ6V+Jblny uYXJROq1TknngpQRP2hzft2adgaHWgFQaotfGna3AXUrpOVqL4be8uFsU0NKzZeM2NYu vMfRUgty9MB5mJdKe62g7BcIsHU824nxUuNlUMH3NqZI1BHkJg9tPyx+3EHzTrO/ApSg EvmQ== X-Received: by 10.68.143.34 with SMTP id sb2mr7074324pbb.135.1396317043681; Mon, 31 Mar 2014 18:50:43 -0700 (PDT) Received: from PC ([218.241.103.53]) by mx.google.com with ESMTPSA id oa3sm46246492pbb.15.2014.03.31.18.50.41 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 31 Mar 2014 18:50:43 -0700 (PDT) From: "Leaf Yeh" To: "'Guang Yao'" References: <20140331054839.12951.1562.idtracker@ietfa.amsl.com> In-Reply-To: <20140331054839.12951.1562.idtracker@ietfa.amsl.com> Date: Tue, 1 Apr 2014 09:50:39 +0800 Message-ID: <533a1b73.0382440a.6009.ffffb32a@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9MpOXA8r4Oc09YSdSq7Z0MD6ou+QAZn8hg Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/savi/BjWGNthzd-Rq7etmZ3j9f-kYt5k Cc: savi@ietf.org, 'Ted Lemon' Subject: Re: [savi] I-D Action: draft-ietf-savi-dhcp-21.txt 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, 01 Apr 2014 01:50:49 -0000 Hi Guang, Q19. I am not sure the reason why there is a new link between SAVI Device C to SAVI Device B in Fig.1. The relation between the SAVI Device A and the SAVI Device B looks more like the case described in the Fig.1 of SAVI arch. (RFC7039). Q20. As to DHCP-Trust Attribute, in section 4.2.2, The "DHCP-Trust Attribute" indicates the DHCP Server-Client messages from the corresponding attachment is trustable. ... , in section 4.3.2 (5) Configure DHCP-Trust attribute on the direct attachments of trusted DHCP relays/servers. ... DHCP-Trust attribute is only configured on the inside links of the perimeter. Only DHCP server-client messages originated in the perimeter is trusted. When the port of SAVI-switch connected to the trusted DHCP relays/servers (in the SAVI-perimeter) is configured DHCP-Trust attribute, how about the data packet forwarding when it is received on this port? I guess the switch will forward the packet as the normal without checking, right? May you need a statement on this case in section 8.1? Best Regards, Leaf -----Original Message----- From: savi [mailto:savi-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Monday, March 31, 2014 1:49 PM To: i-d-announce@ietf.org Cc: savi@ietf.org Subject: [savi] I-D Action: draft-ietf-savi-dhcp-21.txt 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-21.txt Pages : 43 Date : 2014-03-30 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 can be 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-21 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-savi-dhcp-21 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/ _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi