From nobody Sun May 4 02:08:53 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 2991C1A00EF for ; Sun, 4 May 2014 02:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.651] 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 Q0zXloLNeQU9 for ; Sun, 4 May 2014 02:08:49 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0ED1A004A for ; Sun, 4 May 2014 02:08:48 -0700 (PDT) Received: from AndrewYaoPC (unknown [166.111.132.217]) by centos (Coremail) with SMTP id AQAAf3C7FgOLA2ZTqwMHAA--.246S2; Sun, 04 May 2014 17:08:27 +0800 (CST) From: "Guang Yao" To: "'Jun Bi'" , "'Ted Lemon'" , "'Pascal Thubert \(pthubert\)'" References: <52D2BDC7-9E55-43BC-8248-23C43DCDEF96@fugue.com> <000c01cf62d1$21c68920$65539b60$@cernet.edu.cn> <003f01cf62ec$d1ac07f0$750417d0$@cernet.edu.cn> In-Reply-To: <003f01cf62ec$d1ac07f0$750417d0$@cernet.edu.cn> Date: Sun, 4 May 2014 17:08:27 +0800 Message-ID: <000c01cf6778$6972a050$3c57e0f0$@cernet.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHz29Xah5gSK3gNlrPJIuMg2SittAGPDjalAZVDszYCKNAaUQK+oXfeAgodrhCalomHsA== Content-Language: zh-cn X-CM-TRANSID: AQAAf3C7FgOLA2ZTqwMHAA--.246S2 X-Coremail-Antispam: 1UD129KBjvJXoW3Wr1xWFWDXFWfAF4UWFyDJrb_yoWfZF4Dpa yDKa15Gw1DJw18Xwn7Zw1xZryrurWkCay3GFn8GrWjv3s8uryftryI93y5XFyxCrn3Ca1Y vF4q9ryDAas8ZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUg214x267AKxVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84ACjcxK6xIIjxv20xvE14 v26r1j6r1xM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r1j6r4UM28EF7xvwVC2z280aVAF wI0_Gr0_Cr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4j6r4UJwAS0I0E0xvYzxvE52x082 IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S 6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4x0Y48IcxkI7VAKI48G6xCjnVAKz4 kxM4x0x7Aq67IIx4CEVc8vx2IErcIFxwCY02Avz4vE14v_GFWl42xK82IYc2Ij64vIr41l x2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14 v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IY x2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4 A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI 43ZEXa7VUj4CJPUUUUU== X-CM-SenderInfo: 51drw3xdqjquphuqv3oohg3hdfq/ Archived-At: http://mailarchive.ietf.org/arch/msg/savi/bpcOgGqBjcVBN73Ju76wCOlvPr8 Cc: draft-ietf-savi-dhcp@tools.ietf.org, 'SAVI Mailing List' , 'Jean-Michel Combes' Subject: Re: [savi] WGLC: draft-ietf-savi-dhcp-22 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: Sun, 04 May 2014 09:08:52 -0000 Hi folks, Since there are no discussions for one week, maybe it is time to = conclude this WGLC? If yes, we will submit a new version according to = the decisions.=20 Thank you very much! Best regards, Guang -----Original Message----- From: Jun Bi [mailto:junbi@cernet.edu.cn]=20 Sent: Monday, April 28, 2014 10:19 PM To: 'Guang Yao'; 'Ted Lemon'; 'Pascal Thubert (pthubert)' Cc: draft-ietf-savi-dhcp@tools.ietf.org; 'SAVI Mailing List'; = 'Jean-Michel Combes' Subject: RE: [savi] WGLC: draft-ietf-savi-dhcp-22 Dear folks, Many thanks for your valuable review comments. We plan to submit a new version ASAP. Best Regards, Jun Bi -----Original Message----- From: savi [mailto:savi-bounces@ietf.org] On Behalf Of Guang Yao Sent: Monday, April 28, 2014 7:01 AM To: 'Ted Lemon'; 'Pascal Thubert (pthubert)' Cc: draft-ietf-savi-dhcp@tools.ietf.org; 'SAVI Mailing List'; = 'Jean-Michel Combes' Subject: Re: [savi] WGLC: draft-ietf-savi-dhcp-22 Dear folks, Thank you very much for all the comments. Because the topic forks into = multiple threads, I made a summary for the discussions, including our = revision decisions.=20 We are grateful to any advanced comments. Thank you again. Best regards, Guang Yao 1. LQ problem The original post from Eric: "1) There seem to be a requirement in several places of the document = (see below) to send LEASEQUERY to the DHCP server. That is certainly = useful to do so, but switches are sometimes pure layer-2 switches, and = don't implement a DHCP stack not they have a layer-3 address to source = traffic from. Even when the switches have a layer-3 leg, setting then to reach out = the DHCP server is not a trivial operation, and not one which is = typically done on layer-2 access switches. Whenever the LEASEQUERY is mandated, I'd rather have it as a SHOULD, = with some alternate behavior (delete the entry for instance). " The discussions: Pascal: least there should be enough options to implement some user = policies. maybe we should be documenting the value / risk involved in = using LQ or not? Eric: I am not sure how to read this ("MUST" followed but "if it = can't"). Isn't it contradictory? I thought "SHOULD" was exactly the way = to say that.=20 Eric: In the data snooping process...If no conflict was detected, it = does the LQ I'll tend to argue that if LQ is required, the DETECTION = state is not necessary and should be removed. If LQ is optional, and = DETECTION failed to detect a conflict, then the entry should not move = back right away to NO_BIND? Ted: BTW, I agree with Eric that the MUST there should be a SHOULD... Pascal: I'm not sure that this particular FSM is the only way to = implement the function and get all the necessary interoperation. Ted: I think the added flexibility you are talking about might in theory = be a good thing, but might in practice actually be a bad outcome. In = any case, it's certainly true that implementors can do this differently = if they like, as long as their implementation behaves in a way that = interoperate with implementations that follow the documented FSM. =20 [final decision] (a) for the data snooping process, LQ is necessary, or else there is no = need to perform the data snooping process (there is no other way to sync = state with the DHCP server). Considering the whole data snooping process = is a conditional MUST, the LQ is actually a conditional MUST. For the detection problem from Eric, the conflict detection is used to = reduce times of LQ under attacks against local addresses. "If LQ is = optional, and DETECTION failed to detect a conflict, then the entry = should not move back right away to NO_BIND." Then if LQ is not = implemented, the entry will always move back to NO_BIND. There is no = need to perform data snooping process at last... (b) for the DHCP snooping process, LQ is used to get the lease = when the binding is triggered by CONFIRM. We propose: "the SAVI device SHOULD send a LEASEQUERY. In case the SAVI = device is not capable of performing the DHCP leasequery process, the = entry should be set a lifetime of DHCP_DEFAULT_LEASE." Add a term (but not a constant) "DHCP_DEFAULT_LEASE: default lifetime for DHCPv6 address when = the binding the triggered by CONFIRM but LQ cannot be performed by the = SAVI device to fetch the lease." 2. MLD problem The original post from Eric: "I don't think a layer-2 switch can and need to join the Solicited Node = Multicast group of the source address. It does not have a layer-3 stack = on top of every link it is bridging/switching. It has to snoop ND = traffic, like it snoops DHCP traffic. " The discussions: Guang: the similar text is found in RFC6620. " The FCFS SAVI device MUST join the solicited node multicast group = for all the addresses with a state other than NO_BIND. This is needed = to make sure that the FCFS SAVI device will receive the DAD_NS for = those addresses. =20 " Ted: Do we really think there are modern layer 2 devices that will = implement SAVI-DHCP that will not have IPv6 addresses? ... I think this = is a non-problem. Eric: An access switch can deal with hundreds, sometimes thousands of = links (vlans) and while it will always have a layer-3 uplink for = management purpose, mandating one layer-3 downlink per vlan is often not = operationally acceptable. Ted: IOW the switch can't have a link-local address per subnet? Again, = if it's a managed switch, it doesn't make sense that you wouldn't want = it to have a routable L3 address. =20 Eric: I find the below section very confusing. SAVI devices are = switches, hence they have other means to punt any traffic they want to = inspect to cpu level. They would not "join multicast groups". A wild = guess on the intention is to get around the case where some MLD snooping = device is at stake in the network. Works for addresses that you know but = can't possibly work for addresses that you don't know yet and that are = being DAD'ed. MLD snooping is just incompatible with SAVI, and if we = accept that fact, joining MLD solicited group is not needed.=20 And it has the same issue I raised: access switches cannot reasonably = have a layer-3 interface on every subnet (link/vlan) they operate on, = which could be thousands. Pascal: Anyway; whether they are private or not, there can be a great = many vlans and it can become a real hassle to configure one SVI per = vlan.=20 Ted: Thanks for the detailed explanations=E2=80=94it's very helpful, = since I'm a bit out of my depth when it comes to big switches. Leaf: I also wonder a further explanation on the following statement.=20 [final decision] We found the problems for SAVI-DHCP and SAVI-FCFS are different. = SAVI-DHCP does not expect a DAD NS in any state. The NA will always be = received by the SAVI device. Thus it is proper to not join the MLD = group. We will remove the corresponding sentence.=20 3. DAD detection problem=20 The original post from Eric: "I wonder what would be the end-result if the switch send a DAD or and = ARP and the legitimate owner interpret it as "someone already has the = address" (always possible depending on its current state). That would = seriously break DAD or ACD (rfc5227). I think we need a way to = distinguish between the packets issued by the switch and normal DAD or = ACD packets. (some field in the header? But that would be a protocol = change=E2=80=A6)." The discussions: Guang: the similar text is found in RFC6620. "Upon the reception through a Validating Port (VP) of a DATA packet containing IPAddr as the source address, the SAVI device SHOULD execute the process of sending Neighbor Solicitation messages of the Duplicate Address Detection process as described in Section 5.4.2 of [RFC4862] " Leaf: If you could agreed on the above in RFC6620, I guess you would = have no doubt here for the IPv6 address.=20 Eric: DETECTION in general is problematic. The state in the SAVI device and = on the end-node which has the conflicting address are independent. When = he SAVI switch sends a DAD, while the end-node is right in TENTATIVE = (bad luck), this DAD would shutdown the end-node interface. Maybe that = is a problem we have to deal with, but these probe packets are causing = exactly this type of issues, seen in real life. I thought I should = mention it. In your response, you said it could also send a regular NS, which I = assume is an NS lookup. I could not find a reference in the text about = sending NS lookup instead of DAD. This is certainly a good practice (we = have implemented it that way) provided that you have an address to = source it from. However (my usual objection) the access switches often = don't have a l3 address per link/vlan, not even a link-local address. So NS-lookup = should be an option. Which leaves only DAD or LQ. Leaf: This sounds also the same argue to the FSM (including the states = of 'No Bind') described in Fig.2 of RFC6620, which needs the SAVI device (or switch) to send out DAD_NS. If we believe it sounds a wrong message, = would you like submit a Errata for it? =EF=81=8A [final decision]: (a) we will use a non-DAD NS with specified source (sorry for we do not = find the definition for NS lookup). (b) Considering the l3 address problem, I propose use a "SHOULD" on the = NS detection.=20 As I mention above, DAD is not an alternative of LQ. It is used to = reduce the times of LQ under attacks against local addresses. _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi From nobody Mon May 5 02:18:53 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 991381A0298; Mon, 5 May 2014 02:18:50 -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 HIYG6gAQwITM; Mon, 5 May 2014 02:18:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC721A029E; Mon, 5 May 2014 02:18:48 -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.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140505091848.12496.42827.idtracker@ietfa.amsl.com> Date: Mon, 05 May 2014 02:18:48 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/savi/KzWy8agZpOvbI2_OAJAoMKPXor8 Cc: savi@ietf.org Subject: [savi] I-D Action: draft-ietf-savi-dhcp-24.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, 05 May 2014 09:18:50 -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-24.txt Pages : 43 Date : 2014-05-05 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-24 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-savi-dhcp-24 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 May 5 19:20: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 A71131A049A for ; Mon, 5 May 2014 19:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0KisNwAmNgS for ; Mon, 5 May 2014 19:20:27 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4C11A0201 for ; Mon, 5 May 2014 19:20:27 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id ey11so5247199pad.18 for ; Mon, 05 May 2014 19:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=dn59f2HLsAYhivr4YtURu5wxbwppGCDHQOf9RL3dNeg=; b=B0e3GheEmz/yCt2jFBtZDaACOFetO0FJR/WAFPTF0EGieuYvzjjwDxAQLbH2LN1AVR w0KNi6oJ2WHElIzGuEClCXpyzKbSgDjVjYJDcSuHdmowpSFvCGv+CsGHSQ9aUlTubyYc 8qv1KYxQpmRa1xKLHiCOzTljg4u4K7vay9v8eT6h367hB7Kq5VpsV3yLYfbneKK1KXD2 VL8iGCpABuEikppUa+VxN4fifFnbizMsHjn7IALNny+hHL3w/y8qAgt0WUeSW1DKPCg2 RR2kTSJzRCsvRXo73TeyjxMKofSHjkLyKwcqtJCPJyGB8ndjezLwbgMtxASWnUhGXdye MLqA== X-Received: by 10.66.250.161 with SMTP id zd1mr1006181pac.136.1399342823936; Mon, 05 May 2014 19:20:23 -0700 (PDT) Received: from PC ([218.241.103.43]) by mx.google.com with ESMTPSA id lr3sm84786581pab.4.2014.05.05.19.20.21 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 05 May 2014 19:20:23 -0700 (PDT) X-Google-Original-Message-ID: <009b01cf68d1$bad04a60$3070df20$@yeh.sdo@gmail.com> From: "Leaf Yeh" To: "'SAVI Mailing List'" , "'marcelo bagnulo braun'" , "'Eric Levy- Abegnoli \(elevyabe\)'" Date: Tue, 6 May 2014 10:20:17 +0800 Message-ID: <536846e7.637a420a.27dc.02df@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009C_01CF6914.C8F38A60" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9o0V57R5JaXpKkQKaDPzQwUOXmTw== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/savi/0Uz5CVPysXYxmE2FdOgaCpyClIE Subject: [savi] RFC6620 Page 15 - Data Trigger X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 02:20:29 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_009C_01CF6914.C8F38A60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I read RFC6620 again, still have some questions on it. Section 3.2.3 Page 15 @ the state of NO_BIND Upon the reception through a Validating Port (VP) of a DATA packet containing IPAddr as the source address, the SAVI device SHOULD execute the process of sending Neighbor Solicitation messages of the Duplicate Address Detection process ... The DAD_NS messages are not sent through any of the ports configured as Validating Ports. The DAD_NSOL messages are sent through Trusted Ports (but, of course, subject to usual switch behavior and possible MLD snooping optimizations)... The state is moved to TENTATIVE. The LIFETIME is set to TENT_LT (i.e., LT: =TENT_LT), the BINDING ANCHOR is set to VP (i.e., P:=VP), and the Creation time is set to the current value of the local clock. It seems the DAD_NS are not sent to 'any of VP', but sent to TP, after the VP received a data packet, whose source address are not in binding table of the SAVI device. If this data packet use the prefix assigned on this link, we don't expect the DAD_NA from the TP. If the data packet use any IID-interface ID, i.e. the 64 bits of the source address, the SAVI switch will set up a binding entry for each source address. Then I guess we lost the finer-grained SAV here, and only can rely on the SAVI (on-link) prefix list to filtering the 'transit traffic'. Right? I mean the malicious host can create a huge number of *valid* source address within the on-link prefix. What was the design philosophy here? How about send DAD_NS to the VP received data packet for the double-check in the above process? Best Regards, Leaf ------=_NextPart_000_009C_01CF6914.C8F38A60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I read = RFC6620 again, still have some questions on it.

 

Section 3.2.3 Page 15 @ the state = of NO_BIND

<quote>

Upon the reception through a Validating Port (VP) of a = DATA packet

      containing IPAddr as = the source address, the SAVI device SHOULD

      execute the process of = sending Neighbor Solicitation messages of

      the Duplicate Address = Detection process ... The DAD_NS messages are = not

      sent through any of the = ports configured as Validating Ports.  The

      DAD_NSOL messages are = sent through Trusted Ports (but, of course,

      subject to usual switch = behavior and possible MLD snooping

      optimizations)... The = state

      is moved to = TENTATIVE.  The LIFETIME is set to TENT_LT (i.e., = LT:

      =3DTENT_LT), the = BINDING ANCHOR is set to VP (i.e., P:=3DVP), and = the

      Creation time is set to = the current value of the local clock.

</quote>

 

It seems the DAD_NS are not sent to = ‘any of VP’, but sent to TP, after the VP received a data = packet, whose source address are not in binding table of the SAVI = device.

 

If this data packet use the prefix assigned on this link, = we don’t expect the DAD_NA from the TP.

If the data packet use any = IID-interface ID, i.e. the 64 bits of the source address, the SAVI = switch will set up a binding entry for each source = address.

 

Then I guess we lost the finer-grained SAV here, and only = can rely on the SAVI (on-link) prefix list to filtering the = ‘transit traffic’. Right?

 

I mean the malicious host can = create a huge number of *valid* source address within the on-link = prefix. What was the design philosophy here?

 

How about send DAD_NS to the VP = received data packet for the double-check in the above = process?

 

 

Best Regards,

Leaf

 

------=_NextPart_000_009C_01CF6914.C8F38A60-- From nobody Mon May 5 20:02:12 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 87B3F1A0204 for ; Mon, 5 May 2014 20:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBTjUyOwn_NH for ; Mon, 5 May 2014 20:02:06 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 86D801A0114 for ; Mon, 5 May 2014 20:02:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id F29DD2404D2; Mon, 5 May 2014 20:02:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-103.clppva.east.verizon.net [70.106.134.103]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 15F782402C6; Mon, 5 May 2014 20:02:01 -0700 (PDT) Message-ID: <5368508C.9060205@joelhalpern.com> Date: Mon, 05 May 2014 23:01:32 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Leaf Yeh , 'SAVI Mailing List' , 'marcelo bagnulo braun' , "'Eric Levy- Abegnoli (elevyabe)'" References: <536846e7.637a420a.27dc.02df@mx.google.com> In-Reply-To: <536846e7.637a420a.27dc.02df@mx.google.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/savi/e2Xv8PkbJmTeANbX_OIaHAnKBk4 Subject: Re: [savi] RFC6620 Page 15 - Data Trigger X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 03:02:08 -0000 I am not sure what threat you are trying to prevent in your description. The goal of the SAVI work was to prevent one host from claiming the address another host is using. The limits on the number of addresses a host can claim are related to keeping the bookkeeping state bounded. If a hsot causes his own claims to be lost, that is his problem, not SAVI's. Yours, Joel On 5/5/14, 10:20 PM, Leaf Yeh wrote: > I read RFC6620 again, still have some questions on it. > > Section 3.2.3 Page 15 @ the state of NO_BIND > > > > Upon the reception through a Validating Port (VP) of a DATA packet > > containing IPAddr as the source address, the SAVI device SHOULD > > execute the process of sending Neighbor Solicitation messages of > > the Duplicate Address Detection process ... The DAD_NS messages > are not > > sent through any of the ports configured as Validating Ports. The > > DAD_NSOL messages are sent through Trusted Ports (but, of course, > > subject to usual switch behavior and possible MLD snooping > > optimizations)... The state > > is moved to TENTATIVE. The LIFETIME is set to TENT_LT (i.e., LT: > > =TENT_LT), the BINDING ANCHOR is set to VP (i.e., P:=VP), and the > > Creation time is set to the current value of the local clock. > > > > It seems the DAD_NS are not sent to ‘any of VP’, but sent to TP, after > the VP received a data packet, whose source address are not in binding > table of the SAVI device. > > If this data packet use the prefix assigned on this link, we don’t > expect the DAD_NA from the TP. > > If the data packet use any IID-interface ID, i.e. the 64 bits of the > source address, the SAVI switch will set up a binding entry for each > source address. > > Then I guess we lost the finer-grained SAV here, and only can rely on > the SAVI (on-link) prefix list to filtering the ‘transit traffic’. Right? > > I mean the malicious host can create a huge number of **valid** source > address within the on-link prefix. What was the design philosophy here? > > How about send DAD_NS to the VP received data packet for the > double-check in the above process? > > Best Regards, > > Leaf > > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From nobody Mon May 5 20:54:57 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 59E0E1A06E5 for ; Mon, 5 May 2014 20:54:55 -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 QK67xYySBeIe for ; Mon, 5 May 2014 20:54:53 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id CCD261A06E8 for ; Mon, 5 May 2014 20:54:51 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id ld10so5396672pab.17 for ; Mon, 05 May 2014 20:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=8bg9FQKvVdQj1Xi3ODwDtaY+WTKjYeXGlKd6lGKDI5w=; b=YrlWzKJzc1Tg0MwGe+4+UPj8e35D0iNcHpqTrAJMBsm837lNY/ckNCszZLg7fEwL86 33M23mIzdCN3PqpCWJqBg9zl3n2B5SOCtLFDOwbNe36YAxPMnuhSmjElwDCt5COjhXFC 4V6SRis+XJqFb0kY6QPWZJ1BNCty2PHvu02xn+ToCmnzu/Ycx3ZKHD9u/5d+ULuFuyzS dzsdHAMUiNN9c1mnOGsZPxOjFBm1Kmyg3PwgbngBeU5OQ7tunVpmsxQcP8DKmwqcmNFE Tns0VMFKt7sE2zlMhxWtVtU3zQQKpZ8XkQbAZ08p0L7hFV9DMs0KM/J7QRrfrkIT73O5 nzDg== X-Received: by 10.66.254.166 with SMTP id aj6mr1701744pad.11.1399348488147; Mon, 05 May 2014 20:54:48 -0700 (PDT) Received: from PC ([218.241.103.43]) by mx.google.com with ESMTPSA id ey5sm87218179pab.22.2014.05.05.20.54.45 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 05 May 2014 20:54:47 -0700 (PDT) X-Google-Original-Message-ID: <00ab01cf68de$eb075b30$c1161190$@yeh.sdo@gmail.com> From: "Leaf Yeh" To: "'Joel M. Halpern'" , "'SAVI Mailing List'" , "'marcelo bagnulo braun'" , "'Eric Levy- Abegnoli \(elevyabe\)'" References: <536846e7.637a420a.27dc.02df@mx.google.com> <5368508C.9060205@joelhalpern.com> In-Reply-To: <5368508C.9060205@joelhalpern.com> Date: Tue, 6 May 2014 11:54:41 +0800 Message-ID: <53685d07.8564420a.3494.3c0a@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: Ac9o147LhnvhC7RFQ96Xoqx9uKXDEAABQYSA Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/savi/dWHOy2FITSllpF7aGxzHjKBjEdE Subject: Re: [savi] RFC6620 Page 15 - Data Trigger X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 03:54:55 -0000 Joel - The limits on the number of addresses a host can claim are related to keeping the bookkeeping state bounded. If a hsot causes his own claims to be lost, that is his problem, not SAVI's. I guess you mean the host can claim any number of addresses if SAVI device's memory permits. Joel - I am not sure what threat you are trying to prevent in your description. Leaf - > How about send DAD_NS to the VP received data packet for the > double-check in the above process? I intend to prevent the host abuse the source address within the on-link prefix. If SAVI device sent the DAD_NS directly back to the VP received the data, it expected the host do have initiated that source address under test as the target address, and response the DAD_NA. Best Regards, Leaf -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Tuesday, May 06, 2014 11:02 AM To: Leaf Yeh; 'SAVI Mailing List'; 'marcelo bagnulo braun'; 'Eric Levy- Abegnoli (elevyabe)' Subject: Re: [savi] RFC6620 Page 15 - Data Trigger I am not sure what threat you are trying to prevent in your description. The goal of the SAVI work was to prevent one host from claiming the address another host is using. The limits on the number of addresses a host can claim are related to keeping the bookkeeping state bounded. If a hsot causes his own claims to be lost, that is his problem, not SAVI's. Yours, Joel On 5/5/14, 10:20 PM, Leaf Yeh wrote: > I read RFC6620 again, still have some questions on it. > > Section 3.2.3 Page 15 @ the state of NO_BIND > > > > Upon the reception through a Validating Port (VP) of a DATA packet > > containing IPAddr as the source address, the SAVI device SHOULD > > execute the process of sending Neighbor Solicitation messages > of > > the Duplicate Address Detection process ... The DAD_NS messages > are not > > sent through any of the ports configured as Validating Ports. > The > > DAD_NSOL messages are sent through Trusted Ports (but, of > course, > > subject to usual switch behavior and possible MLD snooping > > optimizations)... The state > > is moved to TENTATIVE. The LIFETIME is set to TENT_LT (i.e., LT: > > =TENT_LT), the BINDING ANCHOR is set to VP (i.e., P:=VP), and > the > > Creation time is set to the current value of the local clock. > > > > It seems the DAD_NS are not sent to 'any of VP', but sent to TP, after > the VP received a data packet, whose source address are not in binding > table of the SAVI device. > > If this data packet use the prefix assigned on this link, we don't > expect the DAD_NA from the TP. > > If the data packet use any IID-interface ID, i.e. the 64 bits of the > source address, the SAVI switch will set up a binding entry for each > source address. > > Then I guess we lost the finer-grained SAV here, and only can rely on > the SAVI (on-link) prefix list to filtering the 'transit traffic'. Right? > > I mean the malicious host can create a huge number of **valid** source > address within the on-link prefix. What was the design philosophy here? > > How about send DAD_NS to the VP received data packet for the > double-check in the above process? > > Best Regards, > > Leaf > > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From nobody Tue May 6 07:02:32 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 A61AF1A01BC for ; Tue, 6 May 2014 07:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xNabvCFvTmf for ; Tue, 6 May 2014 07:02:28 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 062551A00DF for ; Tue, 6 May 2014 07:02:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 844361C0E0D; Tue, 6 May 2014 07:02:23 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-103.clppva.east.verizon.net [70.106.134.103]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 875101C0E0B; Tue, 6 May 2014 07:02:21 -0700 (PDT) Message-ID: <5368EB4D.7000704@joelhalpern.com> Date: Tue, 06 May 2014 10:01:49 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Leaf Yeh , 'SAVI Mailing List' , 'marcelo bagnulo braun' , "'Eric Levy- Abegnoli (elevyabe)'" References: <536846e7.637a420a.27dc.02df@mx.google.com> <5368508C.9060205@joelhalpern.com> <53685d07.8564420a.3494.3c0a@mx.google.com> In-Reply-To: <53685d07.8564420a.3494.3c0a@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/savi/x_61VIS3vnc873D3z-UIbuGpEDc Subject: Re: [savi] RFC6620 Page 15 - Data Trigger X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 14:02:29 -0000 I suspect I am misunderstanding you. The goal of SAVI is very specific. it is to prevent one node from claiming an address that is belongs to (by assignment or proper claiming) another node. Can you please restate your concern with the data trigger in terms of how it fails to meet that goal? You should also note that in the case of a multi-access LAN where SAVI is not being run on the individual ports which point to individual machines, and where there is not authentication, then there are significant limitations on the ability of SAVI to protect one claimant from another within that scope. This is spelled out in the SAVI documents. Sending solicitations back onto that LAN (which seems to be what you are asking for) does not actually help with that problem. Yours, Joel On 5/5/14, 11:54 PM, Leaf Yeh wrote: > Joel - The limits on the number of addresses a host can claim are related to > keeping the bookkeeping state bounded. If a hsot causes his own claims to > be lost, that is his problem, not SAVI's. > > I guess you mean the host can claim any number of addresses if SAVI device's > memory permits. > > > Joel - I am not sure what threat you are trying to prevent in your > description. > Leaf - > How about send DAD_NS to the VP received data packet for the >> double-check in the above process? > > I intend to prevent the host abuse the source address within the on-link > prefix. If SAVI device sent the DAD_NS directly back to the VP received the > data, it expected the host do have initiated that source address under test > as the target address, and response the DAD_NA. > > > Best Regards, > Leaf > > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Tuesday, May 06, 2014 11:02 AM > To: Leaf Yeh; 'SAVI Mailing List'; 'marcelo bagnulo braun'; 'Eric Levy- > Abegnoli (elevyabe)' > Subject: Re: [savi] RFC6620 Page 15 - Data Trigger > > I am not sure what threat you are trying to prevent in your description. > The goal of the SAVI work was to prevent one host from claiming the address > another host is using. The limits on the number of addresses a host can > claim are related to keeping the bookkeeping state bounded. If a hsot > causes his own claims to be lost, that is his problem, not SAVI's. > > Yours, > Joel > > On 5/5/14, 10:20 PM, Leaf Yeh wrote: >> I read RFC6620 again, still have some questions on it. >> >> Section 3.2.3 Page 15 @ the state of NO_BIND >> >> >> >> Upon the reception through a Validating Port (VP) of a DATA packet >> >> containing IPAddr as the source address, the SAVI device SHOULD >> >> execute the process of sending Neighbor Solicitation messages >> of >> >> the Duplicate Address Detection process ... The DAD_NS messages >> are not >> >> sent through any of the ports configured as Validating Ports. >> The >> >> DAD_NSOL messages are sent through Trusted Ports (but, of >> course, >> >> subject to usual switch behavior and possible MLD snooping >> >> optimizations)... The state >> >> is moved to TENTATIVE. The LIFETIME is set to TENT_LT (i.e., LT: >> >> =TENT_LT), the BINDING ANCHOR is set to VP (i.e., P:=VP), and >> the >> >> Creation time is set to the current value of the local clock. >> >> >> >> It seems the DAD_NS are not sent to 'any of VP', but sent to TP, after >> the VP received a data packet, whose source address are not in binding >> table of the SAVI device. >> >> If this data packet use the prefix assigned on this link, we don't >> expect the DAD_NA from the TP. >> >> If the data packet use any IID-interface ID, i.e. the 64 bits of the >> source address, the SAVI switch will set up a binding entry for each >> source address. >> >> Then I guess we lost the finer-grained SAV here, and only can rely on >> the SAVI (on-link) prefix list to filtering the 'transit traffic'. Right? >> >> I mean the malicious host can create a huge number of **valid** source >> address within the on-link prefix. What was the design philosophy here? >> >> How about send DAD_NS to the VP received data packet for the >> double-check in the above process? >> >> Best Regards, >> >> Leaf >> >> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > > From nobody Tue May 6 20:22:10 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 AA9211A03DA for ; Tue, 6 May 2014 20:22:08 -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 sQ98et6qZlP0 for ; Tue, 6 May 2014 20:22:06 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id C87E01A0215 for ; Tue, 6 May 2014 20:22:06 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id kq14so460485pab.38 for ; Tue, 06 May 2014 20:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=RI8pIK+nuHzMncTNfMAnaJLbBBzpUerrIWLl0QGdgoI=; b=MLxbARitKv6V4SBhjJkpKUDIBEipKnRsfIesll9grESMGSKQvPsTQGYNvb282zS+Ek B2rXSVSSK9Bukk+S8qfyktxvs5rTwaOaC2bqkKbDoE2ORuC2DCHiWYAXofyXnreFp0Bx K2krhzGY0JKpHjWJBbJlrNrTVrdyLlL6AE9TROHfPhILvZBjEwLJiTV0qgxJ84a3onQq VbJMp7AcW6MwUH3nJrYQPwYRMq+xWMVFFT4G+k/jtlGwggehnDxeZsgqdS8ddCJhHiRQ l6Qn/Ty7cIH0Tr9kbu8HlUpOVk0yLxWNMTV9DjEqPdlsLMJ00s327bLHPWcLvHJkFpJi JBRA== X-Received: by 10.66.171.76 with SMTP id as12mr13645446pac.52.1399432922757; Tue, 06 May 2014 20:22:02 -0700 (PDT) Received: from PC ([218.241.103.232]) by mx.google.com with ESMTPSA id se3sm364090pbb.80.2014.05.06.20.22.00 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 06 May 2014 20:22:01 -0700 (PDT) X-Google-Original-Message-ID: <006701cf69a3$81f05230$85d0f690$@yeh.sdo@gmail.com> From: "Leaf Yeh" To: "'Joel M. Halpern'" , "'SAVI Mailing List'" , "'marcelo bagnulo braun'" , "'Eric Levy- Abegnoli \(elevyabe\)'" References: <536846e7.637a420a.27dc.02df@mx.google.com> <5368508C.9060205@joelhalpern.com> <53685d07.8564420a.3494.3c0a@mx.google.com> <5368EB4D.7000704@joelhalpern.com> In-Reply-To: <5368EB4D.7000704@joelhalpern.com> Date: Wed, 7 May 2014 11:21:55 +0800 Message-ID: <5369a6d9.838f440a.7e55.1450@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: Ac9pM89ZEQeKOBz9QH+C3vt5kYWv3wAX7v/g Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/savi/8Vq050Jwgu1ftq48eBJWpXjQcZA Subject: Re: [savi] RFC6620 Page 15 - Data Trigger X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 03:22:08 -0000 Joel - The goal of SAVI is very specific. it is to prevent one node from claiming an address that is belongs to (by assignment or proper claiming) another node. Can you please restate your concern with the data trigger in terms of how it fails to meet that goal?.... Sending solicitations back onto that LAN (which seems to be what you are asking for) does not actually help with that problem. I guess your logic sounds right. DAD_NS should sent through the TP, which may connect to other SAVI device (and more hosts) within the same scope, i.e. the same link, or the same broadcast domain. But the above logic sounds not cover my concern on the host to abuse the source address within the on-link prefix. Sending DAD_NS back to the VP receiving the data trigger, sounds useful for a check. Wrong or harmful? Best Regards, Leaf -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Tuesday, May 06, 2014 10:02 PM To: Leaf Yeh; 'SAVI Mailing List'; 'marcelo bagnulo braun'; 'Eric Levy- Abegnoli (elevyabe)' Subject: Re: [savi] RFC6620 Page 15 - Data Trigger I suspect I am misunderstanding you. The goal of SAVI is very specific. it is to prevent one node from claiming an address that is belongs to (by assignment or proper claiming) another node. Can you please restate your concern with the data trigger in terms of how it fails to meet that goal? You should also note that in the case of a multi-access LAN where SAVI is not being run on the individual ports which point to individual machines, and where there is not authentication, then there are significant limitations on the ability of SAVI to protect one claimant from another within that scope. This is spelled out in the SAVI documents. Sending solicitations back onto that LAN (which seems to be what you are asking for) does not actually help with that problem. Yours, Joel On 5/5/14, 11:54 PM, Leaf Yeh wrote: > Joel - The limits on the number of addresses a host can claim are > related to keeping the bookkeeping state bounded. If a hsot causes > his own claims to be lost, that is his problem, not SAVI's. > > I guess you mean the host can claim any number of addresses if SAVI > device's memory permits. > > > Joel - I am not sure what threat you are trying to prevent in your > description. > Leaf - > How about send DAD_NS to the VP received data packet for the >> double-check in the above process? > > I intend to prevent the host abuse the source address within the > on-link prefix. If SAVI device sent the DAD_NS directly back to the VP > received the data, it expected the host do have initiated that source > address under test as the target address, and response the DAD_NA. > > > Best Regards, > Leaf > > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Tuesday, May 06, 2014 11:02 AM > To: Leaf Yeh; 'SAVI Mailing List'; 'marcelo bagnulo braun'; 'Eric > Levy- Abegnoli (elevyabe)' > Subject: Re: [savi] RFC6620 Page 15 - Data Trigger > > I am not sure what threat you are trying to prevent in your description. > The goal of the SAVI work was to prevent one host from claiming the > address another host is using. The limits on the number of addresses > a host can claim are related to keeping the bookkeeping state bounded. > If a hsot causes his own claims to be lost, that is his problem, not SAVI's. > > Yours, > Joel > > On 5/5/14, 10:20 PM, Leaf Yeh wrote: >> I read RFC6620 again, still have some questions on it. >> >> Section 3.2.3 Page 15 @ the state of NO_BIND >> >> >> >> Upon the reception through a Validating Port (VP) of a DATA packet >> >> containing IPAddr as the source address, the SAVI device >> SHOULD >> >> execute the process of sending Neighbor Solicitation messages >> of >> >> the Duplicate Address Detection process ... The DAD_NS >> messages are not >> >> sent through any of the ports configured as Validating Ports. >> The >> >> DAD_NSOL messages are sent through Trusted Ports (but, of >> course, >> >> subject to usual switch behavior and possible MLD snooping >> >> optimizations)... The state >> >> is moved to TENTATIVE. The LIFETIME is set to TENT_LT (i.e., LT: >> >> =TENT_LT), the BINDING ANCHOR is set to VP (i.e., P:=VP), and >> the >> >> Creation time is set to the current value of the local clock. >> >> >> >> It seems the DAD_NS are not sent to 'any of VP', but sent to TP, >> after the VP received a data packet, whose source address are not in >> binding table of the SAVI device. >> >> If this data packet use the prefix assigned on this link, we don't >> expect the DAD_NA from the TP. >> >> If the data packet use any IID-interface ID, i.e. the 64 bits of the >> source address, the SAVI switch will set up a binding entry for each >> source address. >> >> Then I guess we lost the finer-grained SAV here, and only can rely on >> the SAVI (on-link) prefix list to filtering the 'transit traffic'. Right? >> >> I mean the malicious host can create a huge number of **valid** >> source address within the on-link prefix. What was the design philosophy here? >> >> How about send DAD_NS to the VP received data packet for the >> double-check in the above process? >> >> Best Regards, >> >> Leaf >> >> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > > From nobody Tue May 6 23:46:33 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 951B41A03B3 for ; Tue, 6 May 2014 23:46:31 -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 F-DHn3iV7Tpq for ; Tue, 6 May 2014 23:46:30 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3181A024E for ; Tue, 6 May 2014 23:46:30 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id w10so643698pde.26 for ; Tue, 06 May 2014 23:46:26 -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=vFQpNRH6E5GluvHmK2HIQrkGisCw8HKj+LzfouuG6FA=; b=NdsHsxJ9CnFC/30iS+mX8aWK1tP5phVV8VSiJXcyoG6Appstxxr1hI0ytwCXx9rUyQ s0zrxe09Bf07ZDzOp/YCVCDXYVPgQUAq3bcmHbeXJcc/FUPEaheQLI0BSGJfKCW5gsig mHFIOm097g38xX5phq5VEIcVCekGKrfGRoZ8FEEOiBLW30zCzegeWNPKFUriQzz5FEAO sii1IwF6hjrTgF4EKnDzpFitrTD5GNktESgEpCyUxOmftv7nwmjY4+AvPkDga/y6GEZ0 E7Oe/YYRHRmq+9EXe7+UyYp3IsqTuUSU1L1Ndv+DldC7KOdm+VbeRlR+ZkNGYxYZjkys Bzsw== X-Received: by 10.66.141.197 with SMTP id rq5mr15502650pab.64.1399445186469; Tue, 06 May 2014 23:46:26 -0700 (PDT) Received: from PC ([218.241.103.232]) by mx.google.com with ESMTPSA id qv3sm1294184pbb.87.2014.05.06.23.46.24 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 06 May 2014 23:46:25 -0700 (PDT) X-Google-Original-Message-ID: <006b01cf69c0$0f769260$2e63b720$@yeh.sdo@gmail.com> From: "Leaf Yeh" To: "'SAVI Mailing List'" , "'marcelo bagnulo braun'" , "'Eric Levy- Abegnoli \(elevyabe\)'" Date: Wed, 7 May 2014 14:46:20 +0800 Message-ID: <5369d6c1.238b440a.702c.3ae4@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: Ac9pwAuOurvC4VDpRCeYZdh2JeuHWg== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/savi/zrfD1NqNPBAhDyGJiHdvc3YdulY Subject: [savi] RFC6620 Page 17 - Control Trigger X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 06:46:31 -0000 More finding in RFC6620, section 3.2.3, page 17 @ VALID o If ... a DAD_NA packet with the Target Address set to IPAddr is received through a Validating Port P' other than P, then the SAVI device will execute the process of sending DAD_NS messages... two NS messages for that address will be sent by the SAVI device... The DAD_NS message will be forwarded to the port P. The state is moved to TESTING_VP...In any case, it MUST NOT forward the data packets until the binding has been verified. I am trying to think about when the VP' could received DAD_NA with the target address as IPAddr. It sounds the IPAddr is a valid address of the host, which connects under the VP'. The only possible case is when the host with IPAddr moves from VP to VP' during the lifetime of VALID. But even in this case, when the SAVI device receive a DAD_NS from TP or VP'', per the following statements in section 3.2.3, page 17 of RFC6620, o If a DAD_NS is received from a Trusted Port, then the DAD_NS message is forwarded to port P and is also forwarded to the Trusted Ports.... o If a DAD_NS packet with the Target Address set to IPAddr is received through a Validating Port P' other than P, ....The DAD_NS messages will be forwarded to the port P. the DAD_NS will not forward to the VP' mention above. Right? So I guess DAD_NA will not happen to receive from the VP'. Best Regards, Leaf From nobody Wed May 7 19:09:01 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 10C951A01EE for ; Wed, 7 May 2014 19:08:47 -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 tuXxuUCdVTic for ; Wed, 7 May 2014 19:08:45 -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 4E2811A01EC for ; Wed, 7 May 2014 19:08:45 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id y10so1797131pdj.39 for ; Wed, 07 May 2014 19:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=rb6yvCy+/asiibmN9wFYUAl37UhE16O0uZx2CqCQbfE=; b=uzi860yQe+njVqRNT8ELQDN4buU3KaXqVa0vvU/j8gp1RAJaLmDaFKJaOWHi57bl7z zP/ZLFqauWbsdtpaSRC9a3YfU+WOKMVBgaTEp0DE++mDUnHi/h3TiMYBJ9owx9cQTmcX 7eI+fyAE/KrFRfY6cnz1tqIIfdDHh2zRufUazlr6/g6ofOghUUJtx2R/kfES37sJakrP q8LCPjf76T3hkhE2hSML3ElQAFS+JjAh5B8gCIC2BEQTENM8EzCIyEik2p4LB72VRG1q dvWM/K05T2184t8eKD56XTyBDkBmKYUmle1r9TDo6a1W2PKPk41LubcyJ7ymfgZgK8GQ Wsag== X-Received: by 10.66.249.233 with SMTP id yx9mr1552254pac.3.1399514921033; Wed, 07 May 2014 19:08:41 -0700 (PDT) Received: from PC ([218.241.103.130]) by mx.google.com with ESMTPSA id ak1sm5582082pbc.58.2014.05.07.19.08.37 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 07 May 2014 19:08:39 -0700 (PDT) X-Google-Original-Message-ID: <001b01cf6a62$6cfa3570$46eea050$@yeh.sdo@gmail.com> From: "Leaf Yeh" To: "'Joel Halpern Direct'" , "'Joel M. Halpern'" , "'SAVI Mailing List'" , "'marcelo bagnulo braun'" , "'Eric Levy- Abegnoli \(elevyabe\)'" References: <536846e7.637a420a.27dc.02df@mx.google.com> <5368508C.9060205@joelhalpern.com> <53685d07.8564420a.3494.3c0a@mx.google.com> <5368EB4D.7000704@joelhalpern.com> <5369a6d9.838f440a.7e55.1450@mx.google.com> <536A4398.6070102@joelhalpern.com> In-Reply-To: <536A4398.6070102@joelhalpern.com> Date: Thu, 8 May 2014 10:08:34 +0800 Message-ID: <536ae727.41aa440a.69b1.fffff040@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: Ac9qAPIFVJwRNcA+TfeaqRYD2lAW1wAX2Xrg Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/savi/77qY2We51s_uGZJAUrqkWHtPO0k Subject: Re: [savi] RFC6620 Page 15 - Data Trigger X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 02:08:47 -0000 Joel - If the SAVI function is on the device with a dedicated port to the end device (or an authenticated port) then there is no value in sending the NS back to the entity which sent it. (Some of this is conceptually buried in the definition of binding scopes in SAVI, and can be hard to realize.) Sending the DAD_NS intends to make sure the end device has initiated a interface with the source address in the data packet sent out. Otherwise, the end device could spoof a lot of source address at no cost within the same on-link prefix. The address space here is at least /64. Best Regards, Leaf -----Original Message----- From: Joel Halpern Direct [mailto:jmh.direct@joelhalpern.com] Sent: Wednesday, May 07, 2014 10:31 PM To: Leaf Yeh; 'Joel M. Halpern'; 'SAVI Mailing List'; 'marcelo bagnulo braun'; 'Eric Levy- Abegnoli (elevyabe)' Subject: Re: [savi] RFC6620 Page 15 - Data Trigger With regard to protecting hosts from "on-link" attackers, there are two different cases. If the SAVI function is on the device with a dedicated port to the end device (or an authenticated port) then there is no value in sending the NS back to the entity which sent it. (Some of this is conceptually buried in the definition of binding scopes in SAVI, and can be hard to realize.) In the case where the SAVI function is upstream of the usage port (for example, it is on the router port, with bridges / switches between the prot and the users) there are many weaknesses in SAVI efficacy. That is clearly stated in the documents. Sending the NS back on that port will not as far as I can tell help resolve much, if any, of those weaknesses. We did discuss this extensively in the working group. Yours, Joel On 5/6/14, 11:21 PM, Leaf Yeh wrote: > Joel - The goal of SAVI is very specific. it is to prevent one node > from claiming an address that is belongs to (by assignment or proper > claiming) another node. Can you please restate your concern with the > data trigger in terms of how it fails to meet that goal?.... > Sending solicitations back onto that LAN (which seems to be what you > are asking for) does not actually help with that problem. > > I guess your logic sounds right. DAD_NS should sent through the TP, > which may connect to other SAVI device (and more hosts) within the > same scope, i.e. the same link, or the same broadcast domain. But the > above logic sounds not cover my concern on the host to abuse the > source address within the on-link prefix. > > Sending DAD_NS back to the VP receiving the data trigger, sounds > useful for a check. Wrong or harmful? > > > Best Regards, > Leaf > > From nobody Thu May 8 17:07:49 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 45F7E1A01B4; Thu, 8 May 2014 17:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 8p4PPirnu3WH; Thu, 8 May 2014 17:07:44 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4D81A01A0; Thu, 8 May 2014 17:07:44 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B65851801A4; Thu, 8 May 2014 17:07:00 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140509000700.B65851801A4@rfc-editor.org> Date: Thu, 8 May 2014 17:07:00 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/savi/f5DlKyhtNEYleUJ9YleDzstgo24 Cc: drafts-update-ref@iana.org, savi@ietf.org, rfc-editor@rfc-editor.org Subject: [savi] RFC 7219 on SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI) 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, 09 May 2014 00:07:46 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7219 Title: SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI) Author: M. Bagnulo, A. Garcia-Martinez Status: Standards Track Stream: IETF Date: May 2014 Mailbox: marcelo@it.uc3m.es, alberto@it.uc3m.es Pages: 38 Characters: 90423 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-savi-send-11.txt URL: http://www.rfc-editor.org/rfc/rfc7219.txt This memo specifies SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI), a mechanism to provide source address validation using the SEND protocol. The proposed mechanism complements ingress filtering techniques to provide a finer granularity on the control of IPv6 source addresses. This document is a product of the Source Address Validation Improvements Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu May 15 20:44:30 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 5B8741A00D5; Thu, 15 May 2014 20:44:27 -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 ZeRX9jQI5Die; Thu, 15 May 2014 20:44:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 424E01A00BF; Thu, 15 May 2014 20:44:26 -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.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140516034426.21660.29280.idtracker@ietfa.amsl.com> Date: Thu, 15 May 2014 20:44:26 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/savi/GQE1SplUjp5ebLzbY3T6dt0brIY Cc: savi@ietf.org Subject: [savi] I-D Action: draft-ietf-savi-mix-06.txt X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 03:44:27 -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 for Mixed Address Assignment Methods Scenario Authors : Jun Bi Guang Yao Joel M. Halpern Eric Levy-Abegnoli Filename : draft-ietf-savi-mix-06.txt Pages : 11 Date : 2014-05-15 Abstract: This document reviews how multiple address discovery methods can coexist in a single SAVI device and collisions are resolved when the same binding entry is discovered by two or more methods. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-savi-mix/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-savi-mix-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-savi-mix-06 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 May 20 09:09:08 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 B17D91A010F for ; Tue, 20 May 2014 09:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.653 X-Spam-Level: X-Spam-Status: No, score=-0.653 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.651, 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 v23j1QYGVc1H for ; Tue, 20 May 2014 09:09:05 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9D61A0077 for ; Tue, 20 May 2014 09:09:05 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id C747F2380950; Tue, 20 May 2014 12:09:02 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Tue, 20 May 2014 12:08:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7D59D912-C4EA-4F56-9D37-FAA2C5BA3F71@fugue.com> References: To: Jean-Michel Combes X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/savi/NUgm8Ty7vIyVZNQRISQOtqm1eGs Cc: "" , SAVI Mailing List Subject: Re: [savi] WGLC: draft-ietf-savi-dhcp-22 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, 20 May 2014 16:09:06 -0000 Can we get a consensus evalution? Sorry to hassle you when much of the = delay for this document is on me, but it would be nice if we could move = forward. From nobody Tue May 20 09:17:59 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 DA5F81A076F for ; Tue, 20 May 2014 09:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.147 X-Spam-Level: X-Spam-Status: No, score=0.147 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.651, 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 3g7L94503GDK for ; Tue, 20 May 2014 09:17:55 -0700 (PDT) Received: from tsinghua.edu.cn (smtp08.tsinghua.edu.cn [166.111.204.37]) by ietfa.amsl.com (Postfix) with ESMTP id DC07D1A0236 for ; Tue, 20 May 2014 09:17:51 -0700 (PDT) Received: from junbithinkpadx1 (unknown [59.66.24.198]) by app5 (Coremail) with SMTP id DsxvpgA3GS4ngHtTX88YAA--.861S2; Wed, 21 May 2014 00:17:43 +0800 (CST) From: "Jun Bi" To: "'Ted Lemon'" , "'Jean-Michel Combes'" References: <7D59D912-C4EA-4F56-9D37-FAA2C5BA3F71@fugue.com> In-Reply-To: <7D59D912-C4EA-4F56-9D37-FAA2C5BA3F71@fugue.com> Date: Wed, 21 May 2014 00:17:42 +0800 Message-ID: <006001cf7447$0731fbd0$1595f370$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJ+SCgfdpNGCy/MpS4Q3KK7ONbjpgIRB8V2Apmm7OKZxqgcYA== Content-Language: zh-cn X-CM-TRANSID: DsxvpgA3GS4ngHtTX88YAA--.861S2 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUU5S7k0a2IF6F4UM7kC6x804xWl14x267AK xVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGw A2ocxC64kIII0Yj41l84ACjcxK6xIIjxv20xvE14v26ryj6F1UM28EF7xvwVC0I7IYx2IY 6xkF7I0E14v26F4j6r4UJwA2z4x0Y4vEx4A2jsIE14v26r4j6F4UM28EF7xvwVC2z280aV CY1x0267AKxVW8JVW8Jr1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE 5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeV CFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCY02Avz4vE14v_JwCF04k20xvY0x0E wIxGrwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67 kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY 6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMI IF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2 KfnxnUUI43ZEXa7xUUe_lUUUUUU== X-CM-SenderInfo: xmxquxo6wvx0pjkxthxhgxhubq/ Archived-At: http://mailarchive.ietf.org/arch/msg/savi/n68Z5G6Mn2jr61OY5XrHzAMFLBE Cc: draft-ietf-savi-dhcp@tools.ietf.org, 'SAVI Mailing List' Subject: Re: [savi] WGLC: draft-ietf-savi-dhcp-22 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, 20 May 2014 16:17:58 -0000 Dear WG Chair, You may conclude this version then we can move to the next step. Thank you very much! Best Regards, Jun Bi -----Original Message----- From: Ted Lemon [mailto:mellon@fugue.com] Sent: Wednesday, May 21, 2014 12:09 AM To: Jean-Michel Combes Cc: SAVI Mailing List; Subject: Re: WGLC: draft-ietf-savi-dhcp-22 Can we get a consensus evalution? Sorry to hassle you when much of the delay for this document is on me, but it would be nice if we could move forward. From nobody Mon May 26 03:51: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 DEF491A00DF for ; Mon, 26 May 2014 03:51:28 -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 6NJBft65CWku for ; Mon, 26 May 2014 03:51:27 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 386E11A00DE for ; Mon, 26 May 2014 03:51:27 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz1so7443728pad.2 for ; Mon, 26 May 2014 03:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:in-reply-to:subject:date:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=Q+RsBuIDyypkjte6HRZ9P4ZgTNqTDX0BGzoj07/5AlA=; b=SX7LvyRokqiP/dng42lqAhmoGs23P21WBFaIhdFt1CnIKVubukMBbIH9bY92yOcVnJ L/+abn4KaXm3vuHrJ0y6FMQ64zJNNiBKZVkUH9S3Hf3EoV5jIpu3auFYGqOti0+H/wF9 mkUzx4JEbYVtrPiQz1eF8+CcpRhhIHYS3JIWKWqxYzT54j9ErgXohkwUah0IqAjRu7V/ h77u2mRl48QkQuDxvGEwTTWXjO2wXecLmWi33Dp6AyLosM6oPDDaQ6cNgefQY5SGlMtE zsCrAxxzwLeC1M/Z695ZCi/E+bqZZOJ9TGGiyJMYdvHOD0hbQ9U5JRx/f1c2XAlF+dUZ +SKQ== X-Received: by 10.66.224.38 with SMTP id qz6mr9255848pac.153.1401101484488; Mon, 26 May 2014 03:51:24 -0700 (PDT) Received: from PC ([218.241.103.194]) by mx.google.com with ESMTPSA id cj1sm56588763pac.40.2014.05.26.03.51.22 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 26 May 2014 03:51:23 -0700 (PDT) Message-ID: <53831cab.a1b0420a.1cbc.ffff9470@mx.google.com> X-Google-Original-Message-ID: <002601cf78d0$6f1d5e00$4d581a00$@yeh.sdo@gmail.com> From: "Leaf Yeh" To: References: <20140505091848.12496.42827.idtracker@ietfa.amsl.com> In-Reply-To: <20140505091848.12496.42827.idtracker@ietfa.amsl.com> Date: Mon, 26 May 2014 18:51:19 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9oQw0qCfx5UrtDQxGIuVCMXgqALAQcqndA Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/savi/nAMbTWnnRZ5mtR9c95-ynCpXif0 Subject: Re: [savi] I-D Action: draft-ietf-savi-dhcp-24.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: Mon, 26 May 2014 10:51:29 -0000 After reading section 6.4 - 'The State Machine of DHCP Snooping Process' of this draft again, I still need more clarification on it. #1. I am not sure about the reason why the binding entry need necessarily to record the TID-Transaction ID of the DHCPv6 message. @ section 4.2 of RFC3315 transaction ID An opaque value used to match responses with replies initiated either by a client or server. @ section 15.1 of RFC3315 The "transaction-id" field holds a value used by clients and servers to synchronize server responses to client messages. A client SHOULD generate a random number that cannot easily be guessed or predicted to use as the transaction ID for each new message it sends. ... A client MUST leave the transaction ID unchanged in retransmissions of a message. To my understanding on DHCPv6, the TID of Renew should be a different one as that of Request. If the entry in the BST-binding state table includes the field of TID, when the VP-Validating Port of SAVI switch receives a Renew message with a new TID, it needs to update the binding entry with a new TID; then the TP-Trust Port of SAVI switch receives the Reply message responding from the server, the reply message could pass the TID check defined in section 6.3.2 in this draft, ... only if a DHCP message can pass the following checks, the corresponding event is regarded as a valid event:... o TID check: the DHCP Server-Client/Client-Server messages which may cause modification on existing binding entries must have matched TID with the corresponding entry. ... Right? Moreover, the SAVI switch also need to check the client ID in the reply message? These sounds a little complex in the implementation, but the binding entry in the SAVI table could focus on the data packet filtering. #2. @ section 6.4.2.2 of this draft If the status code is "Success", the SAVI device checks the IA options in the Reply message. ...If the SAVI device does not send the LEASEQUERY message, a pre-configured lifetime DHCP_DEFAULT_LEASE MUST be set on the corresponding entry. Do we have a recommended value for ' DHCP_DEFAULT_LEASE '? It sounds the server shall set the value of T1 for some IAs less than DHCP_DEFAULT_LEASE to guarantee the client sent Renew before the BOND state expired. #3. If a DHCPv6 client physically moves from SAVI-switch-1 to SAVI-switch-2 in the same broadcasting domain, how to use the Confirm->Reply messages to remove the binding entry in the SAVI-switch-1 to preserve the coherency in the same broadcasting domain? Best Regards, Leaf -----Original Message----- From: savi [mailto:savi-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Monday, May 05, 2014 5:19 PM To: i-d-announce@ietf.org Cc: savi@ietf.org Subject: [savi] I-D Action: draft-ietf-savi-dhcp-24.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-24.txt Pages : 43 Date : 2014-05-05 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-24 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-savi-dhcp-24 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 From nobody Thu May 29 20:19: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 08ADD1A02E8; Thu, 29 May 2014 20:19:43 -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 tkEAsJsEPG83; Thu, 29 May 2014 20:19:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C861A07BB; Thu, 29 May 2014 20:19:41 -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.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140530031941.4283.57220.idtracker@ietfa.amsl.com> Date: Thu, 29 May 2014 20:19:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/savi/JBsed0bOy4q1kvZvkY8UCWJpzkg Cc: savi@ietf.org Subject: [savi] I-D Action: draft-ietf-savi-dhcp-25.txt X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 03:19:43 -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-25.txt Pages : 43 Date : 2014-05-29 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-25 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-savi-dhcp-25 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 Sat May 31 06:33:29 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 13B8A1A00F9; Sat, 31 May 2014 06:33:26 -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 oOpAvWof4uFr; Sat, 31 May 2014 06:33:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9BD1A08CA; Sat, 31 May 2014 06:33:22 -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.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140531133322.11844.36130.idtracker@ietfa.amsl.com> Date: Sat, 31 May 2014 06:33:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/savi/wBiErzTD0z4PV12PJ6GfY6wrVjI Cc: savi@ietf.org Subject: [savi] I-D Action: draft-ietf-savi-dhcp-26.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: Sat, 31 May 2014 13:33:26 -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-26.txt Pages : 43 Date : 2014-05-31 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-26 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-savi-dhcp-26 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 Sat May 31 22:34:51 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 C868E1A0179 for ; Sat, 31 May 2014 22:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 qZfuIaOzyjOY for ; Sat, 31 May 2014 22:34:46 -0700 (PDT) Received: from tsinghua.edu.cn (smtp06.tsinghua.edu.cn [166.111.204.35]) by ietfa.amsl.com (Postfix) with ESMTP id D30171A017F for ; Sat, 31 May 2014 22:34:44 -0700 (PDT) Received: from junbithinkpadx1 (unknown [118.186.239.193]) by app2 (Coremail) with SMTP id C8xvpgCnOkRpu4pTmpMsAA--.5811S2; Sun, 01 Jun 2014 13:34:33 +0800 (CST) From: "Jun Bi" To: References: <20140531133322.11844.36130.idtracker@ietfa.amsl.com> In-Reply-To: <20140531133322.11844.36130.idtracker@ietfa.amsl.com> Date: Sun, 1 Jun 2014 13:34:30 +0800 Message-ID: <003301cf7d5b$298b3a80$7ca1af80$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQI/zp4eUGU/EUrL2zkUoFRZLnTbupp7GOUg Content-Language: zh-cn X-CM-TRANSID: C8xvpgCnOkRpu4pTmpMsAA--.5811S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Zw13Kw4xCr1ftry8Zr18Xwb_yoW8CF13pa yxJ3y3K34rtw1kGws7Xw10vw1kZ347WFWfAFnxGr1qya45J3WqyrySk345A34DJF95Gws2 yr4Uuwn8tw4fXr7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU7Gb7Iv0xC_Cr1lb4IE77IF4wAFc2x0x2IEx4CE42xK8VAvwI8I cIk0rVWrJVCq3wA2ocxC64kIII0Yj41le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64 xvF2IEw4CE5I8CrVC2j2WlYx0E74AGY7Cv6cx26w4UJr1UMcvjeVCFs4IE7xkEbVWUJVW8 JwACjcxG0xvY0x0EwIxGrwCF04k20xvY0x0EwIxGrwCF04k20xvE74AGY7Cv6cx26w4UJr 1UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF 67AKxVWUJVWUXwCIc40Y0x0EwIxGrbIYCTnIWIevJa73UjIFyTuYvj7UU6E8UUUUU X-CM-SenderInfo: xmxquxo6wvx0pjkxthxhgxhubq/ Archived-At: http://mailarchive.ietf.org/arch/msg/savi/6LZXEra7iAZE9dyg-Wbpfo9EF_M Subject: Re: [savi] I-D Action: draft-ietf-savi-dhcp-26.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: Sun, 01 Jun 2014 05:34:49 -0000 This version only correct some typos at savi-dhcp-25 version. Thanks, Jun -----Original Message----- From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Saturday, May 31, 2014 9:33 PM To: i-d-announce@ietf.org Cc: savi@ietf.org Subject: [savi] I-D Action: draft-ietf-savi-dhcp-26.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-26.txt Pages : 43 Date : 2014-05-31 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-26 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-savi-dhcp-26 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