From zhangdong_rh@huaweisymantec.com Mon Jun 1 01:42:19 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6B683A69FF for ; Mon, 1 Jun 2009 01:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGAhp+B7VWVo for ; Mon, 1 Jun 2009 01:42:19 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id E8F643A6CAB for ; Mon, 1 Jun 2009 01:42:18 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KKJ00IOGXI8I860@hstga02-in.huaweisymantec.com> for savi@ietf.org; Mon, 01 Jun 2009 16:42:08 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KKJ00D2BXI85910@hstml01-in.huaweisymantec.com> for savi@ietf.org; Mon, 01 Jun 2009 16:42:08 +0800 (CST) Received: from [10.27.154.181] by hstml01-in.huaweisymantec.com (mshttpd); Mon, 01 Jun 2009 16:42:08 +0800 From: ZhangDong To: Christian Vogt Message-id: Date: Mon, 01 Jun 2009 16:42:08 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <3C7216EA-FE6C-4151-8468-B9F7FFF87D06@ericsson.com> References: <2AE43E7B-7B84-4751-8871-B8A949F52666@ericsson.com> <001201c9e1c6$399cc780$acd65680$@tsinghua.edu.cn> <4A225E1C.1080300@it.uc3m.es> <3C7216EA-FE6C-4151-8468-B9F7FFF87D06@ericsson.com> Cc: SAVI Mailing List , Guang Yao Subject: Re: [savi] SAVI Bindings For Hosts Behind Legacy Switches? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 08:42:19 -0000 > FCFS. All it requires is adding an option to disable SAVI protection > for certain ports. Such an option would be useful anyhow, as Marcelo > stated earlier. And I would encourage Marcelo to add this feature to > the FCFS specification. IMHO, though protection of certain ports which are connected with legacy switchs is disabled, the binding should be established still. I mean for the certain ports the bindings are also created according to FCFS. What is really disabled is the action of dropping the following packets that are not coincident with the bindings in SAVI device, while not the action of creating bindings. I suppose that the bindings created from the certain ports should be added a special mark in the binding table of SAVI device. When the SAVI device receives packets that are not coincident with the bindings created from the certain ports, it lets the packets pass. At the same time, the SAVI device should send a warning or write a warning in the log. It will be very helpful to analyze and track who is spoofing or what the real problem of IP duplication is. So my point is the SAVI device should not only disabling protection of certain ports, but also need to record the occurrence of IP duplication after the bindings created from the certain ports. Thank you. Dong Zhang From yaoa02@mails.tsinghua.edu.cn Mon Jun 1 07:50:27 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 211C23A6F34 for ; Mon, 1 Jun 2009 07:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOCuFiYxWA9Z for ; Mon, 1 Jun 2009 07:50:26 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id 2544A3A6D04 for ; Mon, 1 Jun 2009 07:50:25 -0700 (PDT) Received: from tu132214.ip.tsinghua.edu.cn ([166.111.132.214] helo=netarchld5f663) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1MB8q2-0002zS-At; Mon, 01 Jun 2009 22:50:10 +0800 From: "Guang Yao" To: "'ZhangDong'" , "'Christian Vogt'" References: <2AE43E7B-7B84-4751-8871-B8A949F52666@ericsson.com> <001201c9e1c6$399cc780$acd65680$@tsinghua.edu.cn> <4A225E1C.1080300@it.uc3m.es> <3C7216EA-FE6C-4151-8468-B9F7FFF87D06@ericsson.com> In-Reply-To: Date: Mon, 1 Jun 2009 22:49:53 +0800 Message-ID: <005101c9e2c8$3938a540$aba9efc0$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnilNtbEmGl4Q0uQ5GdM+LTcyj3/QAM09KQ Content-Language: zh-cn Cc: 'SAVI Mailing List' Subject: Re: [savi] SAVI Bindings For Hosts Behind Legacy Switches? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 14:50:27 -0000 I agree. This is similar with what I mentioned: "Use local bindings to deny packets from indirect connected host.". > -----Original Message----- > From: ZhangDong [mailto:zhangdong_rh@huaweisymantec.com] > Sent: Monday, June 01, 2009 4:42 PM > To: Christian Vogt > Cc: Marcelo Bagnulo Braun; Guang Yao; SAVI Mailing List > Subject: Re: Re: [savi] SAVI Bindings For Hosts Behind Legacy Switches? > > > > FCFS. All it requires is adding an option to disable SAVI protection > > for certain ports. Such an option would be useful anyhow, as Marcelo > > stated earlier. And I would encourage Marcelo to add this feature to > > the FCFS specification. > > IMHO, though protection of certain ports which are connected with legacy > switchs is disabled, the binding should be established still. > I mean for the certain ports the bindings are also created according to FCFS. > What is really disabled is the action of dropping the following packets that > are not coincident with the bindings in SAVI device, while not the action of > creating bindings. > I suppose that the bindings created from the certain ports should be added a > special mark in the binding table of SAVI device. When the SAVI device > receives packets that are not coincident with the bindings created from the > certain ports, it lets the packets pass. At the same time, the SAVI device > should send a warning or write a warning in the log. It will be very helpful to > analyze and track who is spoofing or what the real problem of IP > duplication is. > > So my point is the SAVI device should not only disabling protection of certain > ports, but also need to record the occurrence of IP duplication after the > bindings created from the certain ports. > > > Thank you. > > Dong Zhang > > From yaoa02@mails.tsinghua.edu.cn Mon Jun 1 07:51:42 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCA6B28C15B for ; Mon, 1 Jun 2009 07:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBQA41uGKEUb for ; Mon, 1 Jun 2009 07:51:41 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id A4DD928C179 for ; Mon, 1 Jun 2009 07:51:41 -0700 (PDT) Received: from tu132214.ip.tsinghua.edu.cn ([166.111.132.214] helo=netarchld5f663) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1MB8rP-000308-IF; Mon, 01 Jun 2009 22:51:35 +0800 From: "Guang Yao" To: "'Christian Vogt'" References: <001101c9c874$23988750$6ac995f0$@tsinghua.edu.cn> <9F7E4D0A-C5B3-4F3A-9025-B7BB78997B8E@ericsson.com> In-Reply-To: <9F7E4D0A-C5B3-4F3A-9025-B7BB78997B8E@ericsson.com> Date: Mon, 1 Jun 2009 22:51:18 +0800 Message-ID: <005201c9e2c8$6c065260$4412f720$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnZjP7IGp0v6XA2QCGAsysybNeDSgJO04dg Content-Language: zh-cn Cc: savi@ietf.org Subject: Re: [savi] DAD as a binding distribution protocol: why not X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 14:51:42 -0000 Because currently CPS only set up bindings for directly connected hosts, the possibility of DAD packet loss is low. However, it will be argued this would happen anyway. I have to say, it is partly cause by the defect of DAD. I wonder whether there would always be argument that DAD should never be used because unreliable DAD would lead to a wrong configuration in the network, unless in the future, DAD is design to be a reliable model (a model I can't image now). However, after all, DAD is widely used. Packet loss can never be eliminated. I just want to argue: 1 DAD packet loss wouldn't happen that frequently. And things will be better in the future. (1) In wired network, zero-frame loss is not a new concept, which means no frame will be dropped within the throughput. I think more devices will have zero-frame loss feature, because of the requirement of real-time multimedia, online game, etc. (2) The number of DAD NS is configurable. Though currently it is 1, I think 3 is a good number, as the collision detection number of IPv4 (3) Wireless network has higher loss possibility. But the things are some different from wired network. Some research has been performed on spoofing in wireless network, including MANET. I'm not quite familiar with this area. I will check related papers. 2 Even it happens, the damage is not that great. Stop a session before it is initialized maybe is better than shut it when it is alive. In a typical scene, a host finds it cannot send packets, thus it will configure another address or re-initialize interface, then everything is OK, nothing get lost. Actually I always have to re-configure my address because the address in our lab is manually configured. If someone has used my address ahead, I have to change my address. Regards, Guang > -----Original Message----- > From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of > Christian Vogt > Sent: Thursday, May 21, 2009 4:52 AM > To: Guang Yao > Cc: SAVI Mailing List > Subject: Re: [savi] DAD as a binding distribution protocol: why not > > On Apr 28, 2009, Guang Yao wrote: > > > Thus, without DAD, the SAVI device cannot get known whether this > > address > > has been used by other nodes. Only after a successful DAD, the SAVI > > device has confident to set up a binding for that address; or else, it > > may cause fallacious binding. > > > Guang - > > As with the first data packet, also the DAD packets are not guaranteed > to > reach the SAVI device. There are two reasons for this: First, DAD > packets may get lost, as Marcelo has mentioned. This is in particular > so > if the DAD packets have to make an extra hop via a legacy switch. > Second, > because the DAD packets may deliberately not be forwarded to the SAVI > device. DAD packets are not broadcast; they are either unicast or > limited > to a certain multicast group, so they may not reach the SAVI device. > > Since DAD packets are not guaranteed to reach the SAVI device just as > data packets, CPS may run into problems that are very similar to the > FCFS- > specific problems you have identified. > > - Christian > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From fred@cisco.com Mon Jun 1 09:11:41 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDEDF3A6CB5 for ; Mon, 1 Jun 2009 09:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.519 X-Spam-Level: X-Spam-Status: No, score=-105.519 tagged_above=-999 required=5 tests=[AWL=1.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYMtiCtPYSqS for ; Mon, 1 Jun 2009 09:11:40 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id CF78E3A6B80 for ; Mon, 1 Jun 2009 09:11:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,285,1241395200"; d="scan'208";a="171082143" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 01 Jun 2009 16:11:41 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n51GBfb8022958 for ; Mon, 1 Jun 2009 09:11:41 -0700 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n51GBfdZ023374 for ; Mon, 1 Jun 2009 16:11:41 GMT Message-Id: <59D15025-814F-4967-84EC-50FCA0225CC1@cisco.com> From: Fred Baker To: SAVI Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 1 Jun 2009 09:11:38 -0700 X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4057; t=1243872701; x=1244736701; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20forwarding=20datagrams=20without=20bindings |Sender:=20; bh=FPXqWPUgaNQgghfsfEbiZvZ5T/NdsUEaNrLISggp0eA=; b=r5wfJyc4awUBIZapGltMFM037I4qmMzcwBs8WWFWW4YrcNAcztx0z5Zknd mzLoS/rk37/qMivWqywG3QqhCw8MYv/fdjKwfdntKuugD5DvJtoZq6CwzuGV HrToNeooFb; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [savi] forwarding datagrams without bindings X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 16:11:42 -0000 Marcelo will, when he gets a few minutes (he is traveling this week), flesh out the idea that he discussed on the call this morning. While I'm thinking about it, I would like to summarize the thought and the question that was running through my head. The discussion related to whether we should set up SAVI bindings using FCFS only on control datagrams or also on data exchanges. He suggested that we only set up binding state on control packets but that we permit data packets that correspond to no binding (eg, from is an address that nobody in the LAN is known to be using) to pass. My question goes to the heart of what we are trying to do here. It seems to me that SAVI is trying, ultimately, to guarantee that if one system sends a datagram to another system, the second system's reply will make it back to the first system barring system or network failure. Address spoofing is the obvious attack that we have been trying to prevent - the use of a source address such that A sends to B and B's reply is delivered to some third party. But it seems to me that address anonymization is also an attack that the technology is trying to prevent - if A sends to B, B might reply but the network be systemically unable to deliver it and the original source of the datagram is not determinable. In short, I think SAVI is trying to do more than "prevent spoofing", it is trying to ensure that datagrams in the wild are valid and useful as opposed to being attack traffic. To do that, the point is not the negative statement that "it doesn't spoof someone else's address", the point is the positive statement that "it uses its own address". To make that positive statement, whether we set up bindings on control or data packets, we can only allow datagrams to pass that originate from addresses that are associated with the putative sender, apart from systems that routinely originate datagrams at L2 from other L3 addresses, such as routers do. In case what I just said is not clear, let me put together an attack example. We often see DDOS attacks in which some large number of systems simultaneously send a datagram to some targeted address using a random source address. To track these back, what operations folks try to do is track the trajectory of those attacking datagrams. The effectiveness of the attack is limited by BCP 38 filters (uRPF or whatever), which only allow packets through for which the random number in fact selected the right source prefix. But in IPv6, selecting the right /64 still means one has 2^64 interface identifiers to choose from, and that the probability of randomly selecting that of a neighbor is pretty low. So while preventing address spoofing is an obvious goal, simply doing that doesn't prevent attacks in which the source address is incorrect; one also has to prevent address anonymization. Which brings us back to the question of address binding. If what we are doing is preventing systems from sending from addresses that are not their own, then there is no real question of interoperating with non-SAVI switches in other parts of the network. SAVI switches somehow know which ports connect to hosts (as opposed to routers, switch/ switch trunks, and some kinds of servers), and drop datagrams they send that are not from addresses bound to them. If one wants to have a SAVI network, one doesn't try to be backward compatible with non-SAVI equipment, one replaces non-SAVI equipment with SAVI equipment, hopefully by an upgrade for large switches, but for consumer grade equipment by replacing it. The one case where that does not follow is a desktop switch, in which the larger switch may not be able to distinguish between a virtual host and a set of hosts connected by a 5 port potentially-non-SAVI switch and that to the wall; there, the big switch might associate IPv6 addresses with MAC Addresses and those in turn with a port. From elevyabe@cisco.com Tue Jun 2 03:00:17 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95A263A6B15 for ; Tue, 2 Jun 2009 03:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7g2-lDOCvH1 for ; Tue, 2 Jun 2009 03:00:16 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 85F933A69B7 for ; Tue, 2 Jun 2009 03:00:16 -0700 (PDT) X-Files: New Version Notification for draft-levy-abegnoli-savi-plbt-00.eml : None X-IronPort-AV: E=Sophos;i="4.41,290,1241395200"; d="eml'208?scan'208,208";a="171417260" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-2.cisco.com with ESMTP; 02 Jun 2009 10:00:08 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n52A07ZA024377 for ; Tue, 2 Jun 2009 12:00:07 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n52A08wQ015859 for ; Tue, 2 Jun 2009 10:00:08 GMT Received: from xmb-ams-335.cisco.com ([144.254.231.80]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jun 2009 12:00:08 +0200 Received: from [144.254.53.102] ([144.254.53.102]) by xmb-ams-335.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jun 2009 12:00:07 +0200 Message-ID: <4A24F827.8070400@cisco.com> Date: Tue, 02 Jun 2009 12:00:07 +0200 From: Eric Levy-Abegnoli User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: SAVI Mailing List Content-Type: multipart/mixed; boundary="------------040103070702050204020009" X-OriginalArrivalTime: 02 Jun 2009 10:00:07.0849 (UTC) FILETIME=[E8CAF990:01C9E368] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4286; t=1243936808; x=1244800808; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=elevyabe@cisco.com; z=From:=20Eric=20Levy-Abegnoli=20 |Subject:=20[Fwd=3A=20New=20Version=20Notification=20for=20 draft-levy-abegnoli-savi-plbt-00] |Sender:=20; bh=uGPkWcuhH7K6rba8KLrBz4wKazh7AE7/95jYuTxiyUw=; b=p0yek6CCTuVKOH6+H/a20s/9Uwc2qXihz5Iy8K+iyakQ5w9+5ge2k60jfy mgZSBN/lPjHPJ5W2wnmsEd2o9W8aPmDAuGzlmSme81i7PiMrvZi2UA3PNGKE KeDux82n2M; Authentication-Results: ams-dkim-2; header.From=elevyabe@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [savi] [Fwd: New Version Notification for draft-levy-abegnoli-savi-plbt-00] X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 10:00:17 -0000 This is a multi-part message in MIME format. --------------040103070702050204020009 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit --------------040103070702050204020009 Content-Type: message/rfc822; name="New Version Notification for draft-levy-abegnoli-savi-plbt-00.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="New Version Notification for draft-levy-abegnoli-savi-plbt-0"; filename*1="0.eml" X-Account-Key: account2 X-Mozilla-Keys: Received: from xbh-ams-332.emea.cisco.com ([144.254.231.87]) by xmb-ams-335.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jun 2009 11:53:57 +0200 Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jun 2009 11:53:57 +0200 Received: from sj-iport-1.cisco.com ([171.71.176.70]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Jun 2009 02:53:21 -0700 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 02 Jun 2009 09:53:21 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n529rL99032730 for ; Tue, 2 Jun 2009 02:53:21 -0700 Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n529rL4v003715 for ; Tue, 2 Jun 2009 09:53:21 GMT X-from-outside-Cisco: 64.170.98.32 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At0EAOOSJEpAqmIgjmdsb2JhbACOJQGJaQEBAQEJCwgJDwedMpdHhAwF X-IronPort-AV: E=Sophos;i="4.41,290,1241395200"; d="scan'208";a="129976049" Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-a.cisco.com with ESMTP; 02 Jun 2009 09:53:21 +0000 Received: by core3.amsl.com (Postfix, from userid 30) id 0703B3A6AD9; Tue, 2 Jun 2009 02:53:19 -0700 (PDT) From: IETF I-D Submission Tool To: elevyabe@cisco.com Subject: New Version Notification for draft-levy-abegnoli-savi-plbt-00 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090602095320.0703B3A6AD9@core3.amsl.com> Date: Tue, 2 Jun 2009 02:53:20 -0700 (PDT) Authentication-Results: sj-dkim-1; header.From=idsubmission@ietf.org; dkim=neutral Return-Path: wwwrun@core3.amsl.com X-OriginalArrivalTime: 02 Jun 2009 09:53:21.0329 (UTC) FILETIME=[F67CF210:01C9E367] A new version of I-D, draft-levy-abegnoli-savi-plbt-00.txt has been successfuly submitted by Eric Levy-Abegnoli and posted to the IETF repository. Filename: draft-levy-abegnoli-savi-plbt Revision: 00 Title: Preference Level based Binding Table Creation_date: 2009-06-02 WG ID: Independent Submission Number_of_pages: 18 Abstract: A trusted database located on the first switch, storing the binding between end-nodes Link-Layer-Addresses (LLA) and their IPv6 addresses would be an essential part of source address validation. To build such a database, one must: 1. Describe the source of information 2. How the information is maintained 3. How the collisions are resolved. and solutions would differ by one or more of these elements. While also getting its binding data from NDP, this draft proposes an alternate to "first-come-first-serve" basis [fcfs]), by specifying a preference algorithm to deal with collisions. Instead of the simplistic first-come first serve collision handling, the proposed algorithm relies on the following criterias to choose between two coliding entries: o Where the entries were learnt from (access port, trunk port, etc) o Credential carried by the entries (CGA proof, certificate, mac/lla match, etc.) o State of the current entry o Age of the entry Since the state of the entry is one of the element of the algorithm, this draft also describes a tracking mechanism to maintain entries in states where the preference algorithm can enable end-nodes movement. The IETF Secretariat. --------------040103070702050204020009-- From marcelo@it.uc3m.es Tue Jun 2 10:24:46 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37F053A69B4 for ; Tue, 2 Jun 2009 10:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.53 X-Spam-Level: X-Spam-Status: No, score=-5.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyfGbRnRCBrN for ; Tue, 2 Jun 2009 10:24:45 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 712DD3A67B7 for ; Tue, 2 Jun 2009 10:24:45 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [163.117.203.88]) by smtp01.uc3m.es (Postfix) with ESMTP id 69D2DB4D449; Tue, 2 Jun 2009 19:24:44 +0200 (CEST) Message-ID: <4A24DC68.1000508@it.uc3m.es> Date: Tue, 02 Jun 2009 10:01:44 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Guang Yao References: <001101c9c874$23988750$6ac995f0$@tsinghua.edu.cn> <9F7E4D0A-C5B3-4F3A-9025-B7BB78997B8E@ericsson.com> <005201c9e2c8$6c065260$4412f720$@tsinghua.edu.cn> In-Reply-To: <005201c9e2c8$6c065260$4412f720$@tsinghua.edu.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16680.000 Cc: savi@ietf.org, 'Christian Vogt' Subject: Re: [savi] DAD as a binding distribution protocol: why not X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 17:24:46 -0000 Guang Yao escribió: > Because currently CPS only set up bindings for directly connected hosts, the > possibility of DAD packet loss is low. However, it will be argued this would > happen anyway. > exactly, it will happen > I have to say, it is partly cause by the defect of DAD. > i wouldn't call it a defect, it is simply an unreliable protocol, cause it was not designed to be reliable In any case, it is not relevant to use whehter we can change DAD to make it reliable, since no hosts changes are acceptable. So, the bottom line is it is not accpetable to design a SAVI solution that relies on DAD to grant access to the network. Regards, marcelo From gdaley@netstarnetworks.com Tue Jun 2 16:05:52 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8FDE3A68E0 for ; Tue, 2 Jun 2009 16:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B67skzTUOr74 for ; Tue, 2 Jun 2009 16:05:51 -0700 (PDT) Received: from mail.syd.netstarnetworks.com (mail.syd.netstarnetworks.com [203.8.7.220]) by core3.amsl.com (Postfix) with ESMTP id 9A7B83A6897 for ; Tue, 2 Jun 2009 16:05:50 -0700 (PDT) Received: from sydmail.netstarnetworks.com ([10.18.193.13]) by mail.syd.netstarnetworks.com (8.12.8/8.12.8) with ESMTP id n52N5PRs018040; Wed, 3 Jun 2009 09:05:26 +1000 Received: from melmail.netstarnetworks.com ([10.20.193.13]) by sydmail.netstarnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 09:05:21 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 09:05:20 +1000 Message-ID: <6983BF97BFC24D4EA551F14071232918010A1A2E@melmail.netstarnetworks.com> In-Reply-To: <4A24DC68.1000508@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [savi] DAD as a binding distribution protocol: why not Thread-Index: AcnjpwoSAgddrGZGQX6t4pmayx5ObQALSklA References: <001101c9c874$23988750$6ac995f0$@tsinghua.edu.cn> <9F7E4D0A-C5B3-4F3A-9025-B7BB78997B8E@ericsson.com><005201c9e2c8$6c065260$4412f720$@tsinghua.edu.cn> <4A24DC68.1000508@it.uc3m.es> From: "Greg Daley" To: "marcelo bagnulo braun" , "Guang Yao" X-OriginalArrivalTime: 02 Jun 2009 23:05:21.0233 (UTC) FILETIME=[9A8EDC10:01C9E3D6] Cc: savi@ietf.org, Christian Vogt Subject: Re: [savi] DAD as a binding distribution protocol: why not X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 23:05:52 -0000 Hi Marcelo, > Guang Yao escribi=F3: > > Because currently CPS only set up bindings for directly connected=20 > > hosts, the possibility of DAD packet loss is low. However, it will = be=20 > > argued this would happen anyway. > > =20 > exactly, it will happen > > I have to say, it is partly cause by the defect of DAD.=20 > > =20 > i wouldn't call it a defect, it is simply an unreliable protocol, = cause it was not designed to be reliable > > In any case, it is not relevant to use whehter we can change DAD to = make it reliable, since no hosts changes are acceptable. > > So, the bottom line is it is not accpetable to design a SAVI solution = that relies on DAD to grant access to the network. > > Regards, marcelo I agree that DAD is insufficient as a binding discovery protocol since = it is an instantaneous action with no inherent reliability. Once an address is known, NS is a valid = (perhaps reliable) way of testing the address's continued presence, but loss of the initial packet inhibits subsequent = testing. An existing protocol which reliably reports addresses is MLDv2. This = protocol periodically reports only multicast addresses, including the Solicited Nodes' multicast addresses which are = required to be bound for successful multicast Neighbour Discovery Message reception. Presence of a reported Solicited Nodes' address indicates that a unicast = address may continue to be present on the link. (It shows at least that the port is interested in receiving the = Multicast packets to this solicited nodes' address). Solicited nodes addresses do not uniquely identify addresses, though, so = presence of a solicited nodes' address without seeing a commensurate DAD message cannot identify which of the 2^24 (per = prefix) mapped to the group is in use. No other mandatory link-local IPv6 protocol has a continual reporting = mechanism which identifies all participants. The closest to this is DHCPv6 on a managed network (RFC4862 M=3D1), but = this doesn't manage link-local addressing issues, as link-locals are required before DHCPv6 can be attempted. Greg _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi From marcelo@it.uc3m.es Sun Jun 7 11:59:07 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D97583A6AED for ; Sun, 7 Jun 2009 11:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dh-6QYlkebw4 for ; Sun, 7 Jun 2009 11:59:07 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id B01053A69FC for ; Sun, 7 Jun 2009 11:59:06 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (106.pool85-59-203.dynamic.orange.es [85.59.203.106]) by smtp03.uc3m.es (Postfix) with ESMTP id A6C1472D904 for ; Sun, 7 Jun 2009 20:59:07 +0200 (CEST) Message-ID: <4A2C0DFB.3040803@it.uc3m.es> Date: Sun, 07 Jun 2009 20:59:07 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: SAVI Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16690.001 Subject: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2009 18:59:07 -0000 Over the last few weeks, we have been discussing different approaches for SAVI to be used in conjunction IPv6 stateless address autconfiguration. the different proposed approaches have different pros and cons, due to different tradeoffs being made. In this email, i describe an intermediate approach that may be worth to be considered. So, i will first try to summarize the design questions that we have been considering. The first question is whether we create bindings using only DAD packets or we also create bindings using data packet. Creating bindings only with DAD packets, imposes the questions about what can be done when a packets with a source address for which there is no binding. One option would be discard the packet. The problem with this approach is that legitimate packets can be drop. In particular, DAD is not a reliable protocol, so it is possible that DAD packets are lost and do not reach the SAVI device. Similarly, it is also possible that a SAVI device reboots, which would imply that the bindings are lost and since the host may not perform the DAD again, legitimate packets would be lost. It is important to quantify this risk. In my personal opinion, the risk is high enough that i am not comfortable designing a SAVI solution that will discard legitimate packets. OTOH, it is likely that in an important number of cases, the DAD messages are actually delivered and the SAVI device creates the binding using them. So, we return to the initial question about what do we do with data packets containing a source address for which there is no binding. As i mentioned, the other option is to create a binding. The drawback of that approach is that we need to distribute the binding information to the other SAVI devices, so that the configure the binding. (I am here assuming that the DAD messages are in general distributed to all the SAVI devices in the link. In order to do so, we need to require that the SAVI devices receive the packets for all solicited nodes multicast groups, but i understand this is feasible). So, it seems than that in order to distribute the bindings created by the corner case that the DAD packet is lost, we need to require the usage of a SAVI protocol to exchange binding data. If we don't think that discarding them is acceptable and we think that creating a SAVI protocol is an overkill for supporting the case where the DAD packets were lost, we may want to consider a middle ground option. An intermediate option would be to simply forward (and eventually log) data packets with source address for which there is no binding. So, let me expand on this. The behaviour of this approach would be: If DAD exchange is detected by the SAVI device, a binding is created. If a data packet containing a source address for which a binding exists and the same lower layer anchor is received, then the packet is forwarded. If a data packet containing a source address for which a binding exists and a different lower layer anchor is received, then the packet is drop. If a data packet containing a source address for which no binding exists the data packet is forwarded and optionally logged. So what are the security properties of such a solution? If a host starts using an address and performs the DAD procedure, then no other host can use its address as a source address in data packets. An attacker can start using an address for which there is no binding. In order for this address to be the address of another host, this can only happen if the DAD packet was lost. I am not sure how concerned should we be about preventing this from attackers that have the capability of disturbing DAD, I mean, if they are able to do that, i guess they can launch worse attacks than spoof a source address. An attacker can use a given address from different lower layer anchors. I am not sure why this would be an attack though. As i said earlier it would be possible for the SAVI device to log the occurrence of these packets and allow to trace back to the lower layer anchor. So, this option seems like a middle ground option with a somehow reduced level of security but with a low level of complexity and without the possibility of disturbing the network behaviour by discarding legitimate packets. Comments? Regards, marcelo From marcelo@it.uc3m.es Sun Jun 7 12:12:12 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5823A3A6D04 for ; Sun, 7 Jun 2009 12:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXz59keoRYco for ; Sun, 7 Jun 2009 12:12:11 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 097883A6CC1 for ; Sun, 7 Jun 2009 12:12:10 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (106.pool85-59-203.dynamic.orange.es [85.59.203.106]) by smtp03.uc3m.es (Postfix) with ESMTP id 30744732810; Sun, 7 Jun 2009 21:12:11 +0200 (CEST) Message-ID: <4A2C110A.6090602@it.uc3m.es> Date: Sun, 07 Jun 2009 21:12:10 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Fred Baker References: <59D15025-814F-4967-84EC-50FCA0225CC1@cisco.com> In-Reply-To: <59D15025-814F-4967-84EC-50FCA0225CC1@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16690.001 Cc: SAVI Mailing List Subject: Re: [savi] forwarding datagrams without bindings X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2009 19:12:12 -0000 FWIW, i think it is very important to understand the security implications of this alternative approach. I am not sure i understnad the implications myself, so, this dicussion is useful for that purpose. Fred Baker escribió: > Marcelo will, when he gets a few minutes (he is traveling this week), > flesh out the idea that he discussed on the call this morning. While > I'm thinking about it, I would like to summarize the thought and the > question that was running through my head. > > The discussion related to whether we should set up SAVI bindings using > FCFS only on control datagrams or also on data exchanges. He suggested > that we only set up binding state on control packets but that we > permit data packets that correspond to no binding (eg, from is an > address that nobody in the LAN is known to be using) to pass. > > My question goes to the heart of what we are trying to do here. It > seems to me that SAVI is trying, ultimately, to guarantee that if one > system sends a datagram to another system, the second system's reply > will make it back to the first system barring system or network > failure. Address spoofing is the obvious attack that we have been > trying to prevent - the use of a source address such that A sends to B > and B's reply is delivered to some third party. I am not sure how this could happen with the proposed approach, since the attacker cannot use the address of a real host, since the real host would normally had perform DAD, so a binding would exist in the SAVI device, so packets coming from the attacker with that address would be drop. > But it seems to me that address anonymization is also an attack that > the technology is trying to prevent - if A sends to B, B might reply > but the network be systemically unable to deliver it and the original > source of the datagram is not determinable. not dropping the packet doesn't mean that the SAVI device cannot log the occurrence of such data packet,s which would allow to trace back to the lower anchor of those packets. > In short, I think SAVI is trying to do more than "prevent spoofing", > it is trying to ensure that datagrams in the wild are valid and useful > as opposed to being attack traffic. To do that, the point is not the > negative statement that "it doesn't spoof someone else's address", the > point is the positive statement that "it uses its own address". > > To make that positive statement, whether we set up bindings on control > or data packets, we can only allow datagrams to pass that originate > from addresses that are associated with the putative sender, apart > from systems that routinely originate datagrams at L2 from other L3 > addresses, such as routers do. > > > In case what I just said is not clear, let me put together an attack > example. We often see DDOS attacks in which some large number of > systems simultaneously send a datagram to some targeted address using > a random source address. To track these back, what operations folks > try to do is track the trajectory of those attacking datagrams. The > effectiveness of the attack is limited by BCP 38 filters (uRPF or > whatever), which only allow packets through for which the random > number in fact selected the right source prefix. But in IPv6, > selecting the right /64 still means one has 2^64 interface identifiers > to choose from, and that the probability of randomly selecting that of > a neighbor is pretty low. So while preventing address spoofing is an > obvious goal, simply doing that doesn't prevent attacks in which the > source address is incorrect; one also has to prevent address > anonymization. I fail to see why these attacking hosts would simply do the DAD for the addresses they want to use and get access to the savi filters by doing so. I mean, if you have a solution that drops packets if there is no binding, then the attacker simply needs to perform the DAD , create the binding and then send the packets (which would be the easier thing to do, cause that is what OS do by default) > > > Which brings us back to the question of address binding. If what we > are doing is preventing systems from sending from addresses that are > not their own, So, there are 2 types of addresses in a link. the addresses that already belong to a host and the addresses that don't belong to anyone. The proposed approach of forwarding packets wihtout bindings prevents the attacker to use the address of other hosts. What the proposed approach doens't do is to prevent an attacker to use addresses that do not belong to any host. But, if they do not belong to nay host, the attacker can simply perform DAD and create the binding and own the address. So, what is that we are missing form the security perspective in this appraoch? Regards, marcelo > then there is no real question of interoperating with non-SAVI > switches in other parts of the network. SAVI switches somehow know > which ports connect to hosts (as opposed to routers, switch/switch > trunks, and some kinds of servers), and drop datagrams they send that > are not from addresses bound to them. If one wants to have a SAVI > network, one doesn't try to be backward compatible with non-SAVI > equipment, one replaces non-SAVI equipment with SAVI equipment, > hopefully by an upgrade for large switches, but for consumer grade > equipment by replacing it. The one case where that does not follow is > a desktop switch, in which the larger switch may not be able to > distinguish between a virtual host and a set of hosts connected by a 5 > port potentially-non-SAVI switch and that to the wall; there, the big > switch might associate IPv6 addresses with MAC Addresses and those in > turn with a port. > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From zhangdong_rh@huaweisymantec.com Sun Jun 7 19:35:22 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F9EF3A6BE3 for ; Sun, 7 Jun 2009 19:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.911 X-Spam-Level: X-Spam-Status: No, score=-0.911 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8LDRmGuxEUw for ; Sun, 7 Jun 2009 19:35:21 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 86F4D3A6973 for ; Sun, 7 Jun 2009 19:35:21 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KKW00FLHF6RFV40@hstga01-in.huaweisymantec.com> for savi@ietf.org; Mon, 08 Jun 2009 10:35:15 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KKW008PHF6RCI00@hstml01-in.huaweisymantec.com> for savi@ietf.org; Mon, 08 Jun 2009 10:35:15 +0800 (CST) Received: from [10.27.154.181] by hstml01-in.huaweisymantec.com (mshttpd); Mon, 08 Jun 2009 10:35:15 +0800 From: ZhangDong To: marcelo bagnulo braun Message-id: Date: Mon, 08 Jun 2009 10:35:15 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <4A2C0DFB.3040803@it.uc3m.es> References: <4A2C0DFB.3040803@it.uc3m.es> Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 02:35:22 -0000 > If a data packet containing a source address for which no binding exists > the data packet is forwarded and optionally logged. Agree. The basic principle is not to disturb the legitimat packets. So forwarding is the reasonable choice. However, it seems that there is something different with my view. I already have stated my view in the last mail. The difference is that for the data packet with no binding exists, whether the savi device creats binding with a special mark first, then forwards and logs. I think in this way, we could look at this kind of the data packet binding with mark as a temporary binding. If the source address in the data packet is really used by a legitimate user, we could eliminate the special mark of the binding under some conditions (the conditions need to be considered.). Then it become the normal binding in the table. Imho, it seems that it is better than just forwarding without a binding. Because for the legitimate use of a source, it can not be disbelieved forever. Is that feasible? Thank you. Dong Zhang From marcelo@it.uc3m.es Mon Jun 8 00:25:25 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8FD23A6B5E for ; Mon, 8 Jun 2009 00:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3KmyfgDnQmU for ; Mon, 8 Jun 2009 00:25:23 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 8272E3A6810 for ; Mon, 8 Jun 2009 00:25:23 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (106.pool85-59-203.dynamic.orange.es [85.59.203.106]) by smtp02.uc3m.es (Postfix) with ESMTP id 86538655FBE; Mon, 8 Jun 2009 09:25:26 +0200 (CEST) Message-ID: <4A2CBCE7.40505@it.uc3m.es> Date: Mon, 08 Jun 2009 09:25:27 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: ZhangDong References: <4A2C0DFB.3040803@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16690.005 Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 07:25:25 -0000 ZhangDong escribió: >> If a data packet containing a source address for which no binding exists >> the data packet is forwarded and optionally logged. >> > Agree. The basic principle is not to disturb the legitimat packets. So forwarding is the reasonable choice. However, it seems that there is something different with my view. I already have stated my view in the last mail. The difference is that for the data packet with no binding exists, whether the savi device creats binding with a special mark first, then forwards and logs. > As i mentioned in the previous email, you can certainly log info about these packets in order to allow traceability. This is a tradeoff between memory and security. > I think in this way, we could look at this kind of the data packet binding with mark as a temporary binding. If the source address in the data packet is really used by a legitimate user, we could eliminate the special mark of the binding under some conditions (the conditions need to be considered.). Then it become the normal binding in the table. > the problem with that is that the binding would only exist in the devices that have forwarded this packet and not the others. So, we could create a binding, even from the first packet and also discard packets based on this binding. The difference is that this particular binding is likely not the be in all the savi devices, so the degree of security for this binding is lower than the ones created by DAD. So, one option would be to create the bindings as normal bindings and discard the packets that come with a different lower layer anchor. the basic difference is the scope of the protection. DAD created bindings are protected by all the SAVI devices, while data packet created bindings are only protected by the SAVI devices that forwarded the packet. The potential problem with this is inconsistent bindings. I.e. a SAVI device creates one binding using a data packet, and another savi device creates a different binding with a different data packet. This may create problems. In particular, with respect to mobility. > Imho, it seems that it is better than just forwarding without a binding. Because for the legitimate use of a source, it can not be disbelieved forever. it is not a problem of believing or not. It is a problem of the scope of the protection. Regards, marcelo > Is that feasible? > > Thank you. > > Dong Zhang > > > > > From elevyabe@cisco.com Mon Jun 8 07:37:19 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C12203A6857 for ; Mon, 8 Jun 2009 07:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhQ0cAqJMiOm for ; Mon, 8 Jun 2009 07:37:18 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id CEA353A682B for ; Mon, 8 Jun 2009 07:37:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,325,1241395200"; d="scan'208";a="42307200" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Jun 2009 14:37:21 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n58EbLP5005943; Mon, 8 Jun 2009 16:37:21 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n58EbLEl012622; Mon, 8 Jun 2009 14:37:22 GMT Received: from xmb-ams-335.cisco.com ([144.254.231.80]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jun 2009 16:37:21 +0200 Received: from [144.254.53.102] ([144.254.53.102]) by xmb-ams-335.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jun 2009 16:37:21 +0200 Message-ID: <4A2D2221.4030503@cisco.com> Date: Mon, 08 Jun 2009 16:37:21 +0200 From: Eric Levy-Abegnoli User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: marcelo bagnulo braun References: <4A2C0DFB.3040803@it.uc3m.es> In-Reply-To: <4A2C0DFB.3040803@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 08 Jun 2009 14:37:21.0652 (UTC) FILETIME=[A1CA6340:01C9E846] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7695; t=1244471841; x=1245335841; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=elevyabe@cisco.com; z=From:=20Eric=20Levy-Abegnoli=20 |Subject:=20Re=3A=20[savi]=20A=20different=20trade=20off=20 for=20SAVI |Sender:=20; bh=l6tIPJpT7Jjq7VputT/iSQIq2s4zCDaQw7UVm/RDj50=; b=h4oakiXkCrIX4/dpomQdT0onXyxQ7nHeoB46uBq3OEPYeLTLnuZgmEyscI aZ1lSMvfKtiY2Z/ODmasTKROQmcVlxjQpWv56Vj4dDCLp0v8UzE+qd7N+xsu GlBt7Dxb0n; Authentication-Results: ams-dkim-2; header.From=elevyabe@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 14:37:19 -0000 marcelo bagnulo braun a écrit : > Over the last few weeks, we have been discussing different approaches > for SAVI to be used in conjunction IPv6 stateless address > autconfiguration. > the different proposed approaches have different pros and cons, due to > different tradeoffs being made. > In this email, i describe an intermediate approach that may be worth > to be considered. > > So, i will first try to summarize the design questions that we have > been considering. > The first question is whether we create bindings using only DAD packets > or we also create bindings using data packet. There is something "in-between" DAD and data: other NDP messages. If the savi device misses the DAD packet, chances are that the binding owner will soon send another NDP message. Typically, it will send an NA to all-nodes. It will also at some point have to resolve its neighbors addresses. Those messages are not "required" by the protocol, or they could happen prior to DAD for a given address. However, snooping them (and using them for build the binding table) will greatly lower the chances that the binding was missed.. For end-nodes attached to the savi switch via an access port, it is not un-reasonnable to assume that the switch should have learn a binding prior to see a data packet carrying it. However, when the end-node is attached to the savi switch_A via another switch_B (trunk port), this maybe problematic. Because the savi switch_A could typically come up long after switch_B and all nodes attached to switch_B have already done DAD etc. Chances that switch_A missed the bindings are much higher than the one of a DAD packet getting lost. One policy for switch_A could be to not_drop anything coming over a "savi-trunk", a trunk connected to a savi-device, relying on switch_B to drop traffic from the node "directly-attached" to it (if no binding is available). That way you don't really need to have the switches synchronysing their binding table. The scenario where switch_B is not a savi-device does not fit at all there though. > Creating bindings only with DAD packets, imposes the questions about > what can be done when a packets with a source address for which there > is no binding. > One option would be discard the packet. The problem with this approach > is that legitimate packets can be drop. In particular, DAD is not a > reliable protocol, so it is possible that DAD packets are lost and > do not reach the SAVI device. Similarly, it is also possible that a > SAVI device reboots, which would imply that the bindings are lost and > since the host may not perform the DAD again, legitimate packets would > be lost. If the SAVI device is the switch that attaches the end-nodes, the interface will go down, and the DAD will happen again. In addition, I think we should assume that is it the responsability of the implementation to preserve its states during a reboot. There are countless techniques to do that, and accepting this is an implementation problem would greatly simplify the problem. > It is important to quantify this risk. In my personal opinion, the risk > is high enough that i am not comfortable designing a SAVI solution > that will discard legitimate packets. OTOH, it is likely that in an > important number of cases, the DAD messages are actually delivered and > the SAVI device creates the binding using them. > > So, we return to the initial question about what do we do with data > packets containing a source address for which there is no binding. > As i mentioned, the other option is to create a binding. The drawback of > that approach is that we need to distribute the binding information > to the other SAVI devices, so that the configure the binding. (I am > here assuming that the DAD messages are in general distributed to all > the SAVI devices in the link. In order to do so, we need to require > that the SAVI devices receive the packets for all solicited nodes > multicast groups, but i understand this is feasible). So, it seems > than that in order to distribute the bindings created by the corner case > that the DAD packet is lost, we need to require the usage of a SAVI > protocol to exchange binding data. > > If we don't think that discarding them is acceptable and we > think that creating a SAVI protocol is an overkill for supporting the > case where the DAD packets were lost, we may want to consider a middle > ground option. > > An intermediate option would be to simply forward (and eventually log) > data packets with source address for which there is no binding. > > So, let me expand on this. The behaviour of this approach would be: > If DAD exchange is detected by the SAVI device, a binding is created. > > If a data packet containing a source address for which a binding exists > and the same lower layer anchor is received, then the packet is > forwarded. > > If a data packet containing a source address for which a binding exists > and a different lower layer anchor is received, then the packet is drop. > > If a data packet containing a source address for which no binding exists > the data packet is forwarded and optionally logged. > > So what are the security properties of such a solution? > > If a host starts using an address and performs the DAD procedure, then > no other host can use its address as a source address in data packets. > > An attacker can start using an address for which there is no binding. > In order for this address to be the address of another host, this > can only happen if the DAD packet was lost. I am not sure how concerned > should we be about preventing this from attackers that have the > capability of disturbing DAD, I mean, if they are able to do that, > i guess they can launch worse attacks than spoof a source address. > An attacker can use a given address from different lower layer anchors. > I am not sure why this would be an attack though. As i said earlier > it would be possible for the SAVI device to log the occurrence of these > packets and allow to trace back to the lower layer anchor. > > So, this option seems like a middle ground option with a somehow reduced > level of security but with a low level of complexity and without > the possibility of disturbing the network behaviour by discarding > legitimate packets. > > Comments? Logging is useful, but not practical in case of an attack; Especially logging on data-packet events. Switches/routers are usually very efficient at droping, and very in-efficient at logging, as the latter requires to go very high in the software stack. So you would actually help the attacker there. I think relying on NDP snooping (DAD+other NDP) is a viable short-term solution. And droping traffic when no binding is recorded is the core of what we are trying to achieve, isn't it? On the longer term, a pro-active scheme that would have the hosts announcing their binding would be safer. I'd suggest to re-use something like draft-thubert-3122bis-01.txt (InverseND+) rather than re-inventing something new. Another aspect that would be worth discussing the binding table replacement algorithm, or which biding should be preferred in case of collision. First-come first serve does not work well in a number of basic scenarios (movement, multiple switches, etc.). I proposed a different algorthm (draft-levy-abegnoli-savi-plbt-00.txt). Feel free to comment. Eric > > Regards, marcelo > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From marcelo@it.uc3m.es Mon Jun 8 07:59:05 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F64E3A6D34 for ; Mon, 8 Jun 2009 07:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.69 X-Spam-Level: X-Spam-Status: No, score=-5.69 tagged_above=-999 required=5 tests=[AWL=0.909, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRprgkPqu7vr for ; Mon, 8 Jun 2009 07:59:03 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 11D553A682B for ; Mon, 8 Jun 2009 07:59:02 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp01.uc3m.es (Postfix) with ESMTP id ED9DFBA5EF8; Mon, 8 Jun 2009 16:59:05 +0200 (CEST) Message-ID: <4A2D2739.1000206@it.uc3m.es> Date: Mon, 08 Jun 2009 16:59:05 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Eric Levy-Abegnoli References: <4A2C0DFB.3040803@it.uc3m.es> <4A2D2221.4030503@cisco.com> In-Reply-To: <4A2D2221.4030503@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16690.007 Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 14:59:05 -0000 Eric Levy-Abegnoli escribió: > marcelo bagnulo braun a écrit : >> Over the last few weeks, we have been discussing different approaches >> for SAVI to be used in conjunction IPv6 stateless address >> autconfiguration. >> the different proposed approaches have different pros and cons, due to >> different tradeoffs being made. >> In this email, i describe an intermediate approach that may be worth >> to be considered. >> >> So, i will first try to summarize the design questions that we have >> been considering. >> The first question is whether we create bindings using only DAD packets >> or we also create bindings using data packet. > There is something "in-between" DAD and data: other NDP messages. If > the savi device misses the DAD packet, chances are that the binding > owner will soon send another NDP message. you could go down the paht the SAVI device looks into every ND packet and interprets them and based on that it infers who is the owner of each address. The problem here is that we will need to make inferences from different ND packets, depending on how they are dsitributed (i.e. depending if they are send to all nodes, to a multicast group or to a node). That would essentially imply that any change in the ND spec would potentially have an impact on the SAVI spec and it would result in hardcoding the current ND behaviour. BEsides, the complexity increases since each ND exchange need to be tracked uan understood by the SAVI device to properly infer the resulting binding. > Typically, it will send an NA to all-nodes. what NA would that be? > It will also at some point have to resolve its neighbors addresses. > Those messages are not "required" by the protocol, or they could > happen prior to DAD for a given address. However, snooping them (and > using them for build the binding table) will greatly lower the > chances that the binding was missed.. > > For end-nodes attached to the savi switch via an access port, it is > not un-reasonnable to assume that the switch should have learn a > binding prior to see a data packet carrying it. > However, when the end-node is attached to the savi switch_A via > another switch_B (trunk port), this maybe problematic. Because the > savi switch_A could typically come up long after switch_B and all > nodes attached to switch_B have already done DAD etc. Chances that > switch_A missed the bindings are much higher than the one of a DAD > packet getting lost. right, so are you arguing that a solution that solely relies on DAD is not enough in your opinion? > One policy for switch_A could be to not_drop anything coming over a > "savi-trunk", a trunk connected to a savi-device, relying on switch_B > to drop traffic from the node "directly-attached" to it (if no binding > is available). That way you don't really need to have the switches > synchronysing their binding table. but it would imply that you need to configure which ports are connected to hosts and which ones are connected to other savi devices, right? and that is likely to be a manual configuration, right? and if the topology changes you would need to update that, correct? > > The scenario where switch_B is not a savi-device does not fit at all > there though. >> Creating bindings only with DAD packets, imposes the questions about >> what can be done when a packets with a source address for which there >> is no binding. >> One option would be discard the packet. The problem with this approach >> is that legitimate packets can be drop. In particular, DAD is not a >> reliable protocol, so it is possible that DAD packets are lost and >> do not reach the SAVI device. Similarly, it is also possible that a >> SAVI device reboots, which would imply that the bindings are lost and >> since the host may not perform the DAD again, legitimate packets would >> be lost. > If the SAVI device is the switch that attaches the end-nodes, the > interface will go down, and the DAD will happen again. this is not required by rfc4862 (but i agree that normally happens) > > In addition, I think we should assume that is it the responsability of > the implementation to preserve its states during a reboot. There are > countless techniques to do that, and accepting this is an > implementation problem would greatly simplify the problem. i don't think it is acceptable to rely on this for not blocking legitimate users from sending traffic. >> It is important to quantify this risk. In my personal opinion, the risk >> is high enough that i am not comfortable designing a SAVI solution >> that will discard legitimate packets. OTOH, it is likely that in an >> important number of cases, the DAD messages are actually delivered and >> the SAVI device creates the binding using them. >> >> So, we return to the initial question about what do we do with data >> packets containing a source address for which there is no binding. >> As i mentioned, the other option is to create a binding. The drawback of >> that approach is that we need to distribute the binding information >> to the other SAVI devices, so that the configure the binding. (I am >> here assuming that the DAD messages are in general distributed to all >> the SAVI devices in the link. In order to do so, we need to require >> that the SAVI devices receive the packets for all solicited nodes >> multicast groups, but i understand this is feasible). So, it seems >> than that in order to distribute the bindings created by the corner case >> that the DAD packet is lost, we need to require the usage of a SAVI >> protocol to exchange binding data. >> >> If we don't think that discarding them is acceptable and we >> think that creating a SAVI protocol is an overkill for supporting the >> case where the DAD packets were lost, we may want to consider a middle >> ground option. >> >> An intermediate option would be to simply forward (and eventually log) >> data packets with source address for which there is no binding. >> >> So, let me expand on this. The behaviour of this approach would be: >> If DAD exchange is detected by the SAVI device, a binding is created. >> >> If a data packet containing a source address for which a binding exists >> and the same lower layer anchor is received, then the packet is >> forwarded. >> >> If a data packet containing a source address for which a binding exists >> and a different lower layer anchor is received, then the packet is drop. >> >> If a data packet containing a source address for which no binding exists >> the data packet is forwarded and optionally logged. >> >> So what are the security properties of such a solution? >> >> If a host starts using an address and performs the DAD procedure, then >> no other host can use its address as a source address in data packets. >> >> An attacker can start using an address for which there is no binding. >> In order for this address to be the address of another host, this >> can only happen if the DAD packet was lost. I am not sure how concerned >> should we be about preventing this from attackers that have the >> capability of disturbing DAD, I mean, if they are able to do that, >> i guess they can launch worse attacks than spoof a source address. >> An attacker can use a given address from different lower layer anchors. >> I am not sure why this would be an attack though. As i said earlier >> it would be possible for the SAVI device to log the occurrence of these >> packets and allow to trace back to the lower layer anchor. >> >> So, this option seems like a middle ground option with a somehow reduced >> level of security but with a low level of complexity and without >> the possibility of disturbing the network behaviour by discarding >> legitimate packets. >> >> Comments? > Logging is useful, but not practical in case of an attack; Especially > logging on data-packet events. Switches/routers are usually very > efficient at droping, and very in-efficient at logging, as the latter > requires to go very high in the software stack. So you would actually > help the attacker there. > i think logging is an essential part of SAVI actually I think that the main benefit of SAVI is to know which port was associated to a given source address at some point in time, so that attackers can be traced back. I mean, SAVI does not define any restriction for getting access to an unused address. The main point is to prevent the use of somebody elses address and to use addresses in an anonymous fashion > I think relying on NDP snooping (DAD+other NDP) is a viable short-term > solution. And droping traffic when no binding is recorded is the core > of what we are trying to achieve, isn't it? i don't think so.... what attack you would be preventing in that case? Dropping packets coming from a different lower layer anchor is in the core of savi, but dropping packets with no bindings, it is not obvious to me what is provided by that... i mean, the attacker only needs to create a binding and send the packet, so what is the benefit? > On the longer term, a pro-active scheme that would have the hosts > announcing their binding would be safer. I'd suggest to re-use > something like draft-thubert-3122bis-01.txt (InverseND+) rather than > re-inventing something new. > Another aspect that would be worth discussing the binding table > replacement algorithm, or which biding should be preferred in case of > collision. First-come first serve does not work well in a number of > basic scenarios (movement, multiple switches, etc.). how come FCFS doesn't work well in movement? (in multiple switches, the fcfs behaviour is what we are currently discussing, but it can work, we just need to agree on the tradeoffs) Regards, marcelo > I proposed a different algorthm > (draft-levy-abegnoli-savi-plbt-00.txt). Feel free to comment. > Eric >> >> Regards, marcelo >> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > > From christian.vogt@ericsson.com Tue Jun 9 19:50:57 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B6A13A6830 for ; Tue, 9 Jun 2009 19:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjjWqB-wJTqZ for ; Tue, 9 Jun 2009 19:50:56 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 599D13A6A39 for ; Tue, 9 Jun 2009 19:50:56 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n5A2p1B6004174; Tue, 9 Jun 2009 21:51:02 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jun 2009 21:50:04 -0500 Received: from [155.53.234.106] ([155.53.234.106]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jun 2009 21:50:03 -0500 Message-Id: <827A0FBB-E595-4A0E-A3D8-BA0439AF7CF1@ericsson.com> From: Christian Vogt To: marcelo bagnulo braun In-Reply-To: <4A2C0DFB.3040803@it.uc3m.es> Content-Type: multipart/signed; boundary=Apple-Mail-22-7032035; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 9 Jun 2009 19:50:01 -0700 References: <4A2C0DFB.3040803@it.uc3m.es> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 10 Jun 2009 02:50:03.0911 (UTC) FILETIME=[27C08170:01C9E976] Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 02:50:57 -0000 --Apple-Mail-22-7032035 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jun 7, 2009, marcelo bagnulo braun wrote: > Over the last few weeks, we have been discussing different approaches > for SAVI to be used in conjunction IPv6 stateless address > autconfiguration. the different proposed approaches have different > pros > and cons, due to different tradeoffs being made. In this email, i > describe an intermediate approach that may be worth to be > considered... Marcelo - Thanks for proposing this compromise between DAD-only binding establishment and DAD-plus-data binding establishment. This is very interesting, as it may take us out of the dilemma of either having to cause false packet drops occasionally, or having to specify a binding distribution protocol. Thanks also for the analysis on your proposal. It is clear that, as you say, the security level of your proposed compromise will be lower than the security of both the current FCFS variant (DAD-plus-data binding establishment) and CPS (DAD-only binding establishment). But it certainly is in line with the original idea for SAVI, which was to create a simple security improvement that "does no harm". In fact, your proposed compromise is even more in line with this original idea than the current FCFS variant and CPS are, because (a) it is simpler than the current FCFS variant due to the latter's reliance on a binding distribution protocol, and (b) it does less harm than CPS due to CPS's occasional false packet drops. Of course, more analysis would be useful. Dong Zhang and Eric already contributed their useful thoughts; I'd encourage also others to share their opinion. - Christian --Apple-Mail-22-7032035 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8DCCBDIw ggMaoAMCAQICEAfnb+QKJYbrlz+OaXsA6lEwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0wNzA5MTMxMTI5 MTRaFw0xMDA5MTMxMTI5MTBaMGoxETAPBgNVBAoMCEVyaWNzc29uMRcwFQYDVQQDDA5DaHJpc3Rp YW4gVm9ndDEQMA4GA1UEBRMHZWNocnZvZzEqMCgGCSqGSIb3DQEJARYbY2hyaXN0aWFuLnZvZ3RA ZXJpY3Nzb24uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCVGNN5yyhnvz5VWwGDcmey bI9H/DGF0LQmxS+L3gJ9gJIAQ2NPhF16dsWnlpCwS+VsKwMRfh3BsYGY88Hlx/Yvo6NfqE6evobv prxbgKiFP7j1c7Ntke/6SRamUVPFnWrFuaOuXTwU7GUAd/uOoCRNs/nq1hdQRC684gX/kAfBYwID AQABo4IBhzCCAYMwgcAGA1UdHwSBuDCBtTCBsqCBr6CBrIY3aHR0cDovL2NybC50cnVzdC50ZWxp YS5jb20vRXJpY3Nzb25OTEluZGl2aWR1YWxDQTAxLmNybIZxbGRhcDovL2xkYXAudHJ1c3QudGVs aWEuY29tL2NuPUVyaWNzc29uJTIwTkwlMjBJbmRpdmlkdWFsJTIwQ0EwMSxvPUVyaWNzc29uP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2UwJgYDVR0RBB8wHYEbY2hyaXN0aWFu LnZvZ3RAZXJpY3Nzb24uY29tMEYGA1UdIAQ/MD0wOwYGKoVwawEBMDEwLwYIKwYBBQUHAgEWI2h0 dHA6Ly93d3cuZXJpY3Nzb24uY29tL2xlZ2FsLnNodG1sMB0GA1UdDgQWBBQ2hgtYCoOVEiitjMNu mLE8wGuILzAfBgNVHSMEGDAWgBSWJ8O43qVfXUQ+OVLlRbF2X2MwmzAOBgNVHQ8BAf8EBAMCBaAw DQYJKoZIhvcNAQEFBQADggEBAKYJznyxAs6fzHgXDHa00mqyU/+ykFi9HvBv9MSmD2M1X+bifCd6 /jVVrGZWfMfPSV/AbqQjXVQfyHU1R0EqtgEFLyfNVmEGI9lXkkQb5cXNwaJYVj/+ozy+oSu1ZzZA j0GM6NVvhCwGapHoNDPDWe25UdvmOFxxVo6UMq3TWPcSUMq4s3vHLe5n7tgNCdcVUMeqTrAe9cKw TGy7+eJK48rbBcBtKxq2sTY/4H5H6prEKaVlwGW96PydY0IVu4QGVhUT/ONCVByl5xLImDa0tEaX npUj0Y0ys4DneQ3Bxf6DEMuB5+BiSkBk8FmEaSaj2xA/ShtYuaKIO6e9JjpvGb0wggRFMIIDLaAD AgECAhATyer/3iatqdykyiOBg0fjMA0GCSqGSIb3DQEBBQUAMEQxGjAYBgNVBAoMEVRlbGlhU29u ZXJhIEdyb3VwMSYwJAYDVQQDDB1UZWxpYVNvbmVyYSBQdWJsaWMgUm9vdCBDQSB2MTAeFw0wNjEw MDYxMDAwNTNaFw0xNjEwMDIwNTA0MTdaMDkxETAPBgNVBAoMCEVyaWNzc29uMSQwIgYDVQQDDBtF cmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC2EHfkNR7rh8Q8jRhZRD8wsbjzxTuVtscq/p6glZzSeEGBXtRwAqmr6jS8FBiKiBMh79ay537m /SwXO3UKUR45f3YIIp9DjThSd+p2xhG3x4yyc9gczlr8JfOEnPhcdPSKw1P0mUlhUn4ak7t009/Y e/W6x3UZHTwVIAWILIhSq4hyNE4z+RvOtvB9uwQ86lKcxi0mFoLev7acLjh+ZXHzXx1jHAmF0ZaG 79CpbvJcRuWplqgJ6qx+hAjsmCU0Wx07GkyGTh8vUMP9Hlz7oyk+7VOccUiNknXHias1GwM9qBUU Oj8e/xsnaTP0ZfqmKBj3Grh1C9WknlSWagxanCBdAgMBAAGjggE8MIIBODASBgNVHRMBAf8ECDAG AQH/AgEAMEYGA1UdIAQ/MD0wOwYHKoVwIwIBATAwMC4GCCsGAQUFBwIBFiJodHRwczovL3JlcG9z aXRvcnkudHJ1c3QudGVsaWEuY29tMIGJBgNVHR8EgYEwfzB9oHugeYZ3bGRhcDovL2xkYXAudHJ1 c3QudGVsaWEuY29tL2NuPVRlbGlhU29uZXJhJTIwUHVibGljJTIwUm9vdCUyMENBJTIwdjEsbz1U ZWxpYVNvbmVyYSUyMEdyb3VwP2F1dGhvcml0eXJldm9jYXRpb25saXN0P2Jhc2UwDgYDVR0PAQH/ BAQDAgEGMB0GA1UdDgQWBBSWJ8O43qVfXUQ+OVLlRbF2X2MwmzAfBgNVHSMEGDAWgBRF2/CPuBpi oagjG2OIOKPb4Bpi8TANBgkqhkiG9w0BAQUFAAOCAQEAdgBKKkM/jN0WvWpZKZ/2J8IVyL+rT44V L0rjbNNDYXdE/V4ZSFN2uuQmgf1Ckqp2shNLe0NEKt6/sfxit4p/5opPIvzytv6vB7rc2BUs8+ja c7aaNiRuwBCjiT1Wnnm454OOZurzQu0SH81PbBtiwUf4XsEvLOnRRZ+9MO/ecVMCQVmeuzsyCl6y FVbx0zmKW1gPjBEigF8BYZ1Tjazk1pVcKzFIuB24j1qTpPsUG4HoQhIu5rt3F7GlNV6t5DF7ojbg u1SqKG/JhTvaPUU/nZYqw9rkV8Dabwrt27reisobtPp78tolxio3ZcZVk7HQ8rpV2M/jmAjGfZRV kczCDzCCBG0wggNVoAMCAQICEQCcsIwEmsuXInhjYrYbhlo9MA0GCSqGSIb3DQEBBQUAMDoxGTAX BgNVBAoTEFJTQSBTZWN1cml0eSBJbmMxHTAbBgNVBAsTFFJTQSBTZWN1cml0eSAyMDQ4IFYzMB4X DTA2MTAzMTIwNDIyN1oXDTE2MTEwMTE1NDIyNVowRDEaMBgGA1UECgwRVGVsaWFTb25lcmEgR3Jv dXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyk8QA2qQgKt5qZV+EeIDbflmXuUChp2lREEsmO5SAiheQ7lXVjzC xw484cOSMw3fOtGWcf9Fa4Rgdw5j+EgyFgiqNj8b2OTXJHQVj1qf09rmkHTgMIKh6TdKXtV+/43p efVrFmFyhoP/NVrYe92Sv4HhOxs/T749S1OjeGISzIKKMSpwkvmYweYnFgIPkHdUKUIReOh9Ym6e i7AVg6eejD6YPBeV+suzBlXCmC3Zyzj7POLsUVvarNZAaKc0AY+rOUslYfAPo+ZYgwY4IV2KcP/q WhhHahz3khWMWSniWrZoxCi2JcXGVkSn+N+ir0APYwYTBJsrTDWxonEdZkR+rQIDAQABo4IBYjCC AV4wHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFEXb8I+4GmKhqCMb Y4g4o9vgGmLxMBIGA1UdEwEB/wQIMAYBAf8CAQQwgYUGA1UdIAR+MHwwPQYJKoZIhvcNBQYBMDAw LgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wOwYHKoVwIwIB ATAwMC4GCCsGAQUFBwIBFiJodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWEuY29tMHAGA1Ud HwRpMGcwZaBjoGGGX2h0dHA6Ly93d3cucnNhc2VjdXJpdHkuY29tL3Byb2R1Y3RzL2tlb24vcmVw b3NpdG9yeS9jZXJ0aWZpY2F0ZV9zdGF0dXMvUlNBX1NlY3VyaXR5XzIwNDhfdjMuQ1JMMA4GA1Ud DwEB/wQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEABF6aLNgpyJu//O9srUqxB1mYL4TlBJFJtuT1 n/15FpKONU2i/byEtUugHVgoTalpp2Ikuxn2iIgzPbNQ+iu4YnVgQzpuOmzXTN2cITMgwn5AyUoH idMPu2Jo7wobu4Fqg2QrG7WeYANYsQk3Q57mQeuyRkjxluq+93KK2gz/HYjqYkKLjLzOmyrkzwR/ 9aaC3HLFMbCoK0NtyQvS1gkW/HGB5GY1xR9SuOE7CJeS53tqE9CSN6cHQNr+ozuKfzix57T/p6Y8 D23nTD1GZA2ApHdy0sY/HNyU8bQPEpTwrSBxNYYeucYoYNSUSJYkqYa6q/ZG38B3XlcT3TiORrQ2 DzGCAhIwggIOAgEBME0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EwMQIQB+dv5AolhuuXP45pewDqUTAJBgUrDgMCGgUAoIIBGzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2MTAwMjUwMDRaMCMGCSqGSIb3 DQEJBDEWBBS7AIvIjPrMXd99rI28Ul4RTVtxwzBcBgkrBgEEAYI3EAQxTzBNMDkxETAPBgNVBAoM CEVyaWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEAfnb+QKJYbr lz+OaXsA6lEwXgYLKoZIhvcNAQkQAgsxT6BNMDkxETAPBgNVBAoMCEVyaWNzc29uMSQwIgYDVQQD DBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEAfnb+QKJYbrlz+OaXsA6lEwDQYJKoZIhvcN AQEBBQAEgYAIoQneN/vrWpABga1Gc27Nj9w8/LcbkfQU5CUYGisBQhzwDlm4hjtXytj0cQUgwjkd maNzJ4zl3Mf3Q8n8JNA0bdAeMdHeDpDXkdCFZYUB4W2sL9bDkINsgcsT95KDvpmWuqnJ5YwrgbdT W6hqAlgGghLzeJO6uPSPH3h9fKCmnQAAAAAAAA== --Apple-Mail-22-7032035-- From christian.vogt@ericsson.com Tue Jun 9 20:06:39 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 210603A6844 for ; Tue, 9 Jun 2009 20:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.066 X-Spam-Level: X-Spam-Status: No, score=-6.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ai1eLjrpGNTp for ; Tue, 9 Jun 2009 20:06:38 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 5E2923A6405 for ; Tue, 9 Jun 2009 20:06:38 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n5A36h2q031992 for ; Tue, 9 Jun 2009 22:06:44 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jun 2009 22:06:24 -0500 Received: from [155.53.234.106] ([155.53.234.106]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jun 2009 22:06:23 -0500 Message-Id: From: Christian Vogt To: SAVI Mailing List In-Reply-To: <827A0FBB-E595-4A0E-A3D8-BA0439AF7CF1@ericsson.com> Content-Type: multipart/signed; boundary=Apple-Mail-23-8011877; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 9 Jun 2009 20:06:20 -0700 References: <4A2C0DFB.3040803@it.uc3m.es> <827A0FBB-E595-4A0E-A3D8-BA0439AF7CF1@ericsson.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 10 Jun 2009 03:06:23.0696 (UTC) FILETIME=[6FBFD500:01C9E978] Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 03:06:39 -0000 --Apple-Mail-23-8011877 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Jun 9, 2009, Christian Vogt wrote: > Of course, more analysis would be useful. Dong Zhang and Eric already > contributed their useful thoughts [...] Sorry, I should have said: "Dong Zhang, Eric, /and Fred/ already contributed their useful thoughts..." - Christian --Apple-Mail-23-8011877 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8DCCBDIw ggMaoAMCAQICEAfnb+QKJYbrlz+OaXsA6lEwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0wNzA5MTMxMTI5 MTRaFw0xMDA5MTMxMTI5MTBaMGoxETAPBgNVBAoMCEVyaWNzc29uMRcwFQYDVQQDDA5DaHJpc3Rp YW4gVm9ndDEQMA4GA1UEBRMHZWNocnZvZzEqMCgGCSqGSIb3DQEJARYbY2hyaXN0aWFuLnZvZ3RA ZXJpY3Nzb24uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCVGNN5yyhnvz5VWwGDcmey bI9H/DGF0LQmxS+L3gJ9gJIAQ2NPhF16dsWnlpCwS+VsKwMRfh3BsYGY88Hlx/Yvo6NfqE6evobv prxbgKiFP7j1c7Ntke/6SRamUVPFnWrFuaOuXTwU7GUAd/uOoCRNs/nq1hdQRC684gX/kAfBYwID AQABo4IBhzCCAYMwgcAGA1UdHwSBuDCBtTCBsqCBr6CBrIY3aHR0cDovL2NybC50cnVzdC50ZWxp YS5jb20vRXJpY3Nzb25OTEluZGl2aWR1YWxDQTAxLmNybIZxbGRhcDovL2xkYXAudHJ1c3QudGVs aWEuY29tL2NuPUVyaWNzc29uJTIwTkwlMjBJbmRpdmlkdWFsJTIwQ0EwMSxvPUVyaWNzc29uP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2UwJgYDVR0RBB8wHYEbY2hyaXN0aWFu LnZvZ3RAZXJpY3Nzb24uY29tMEYGA1UdIAQ/MD0wOwYGKoVwawEBMDEwLwYIKwYBBQUHAgEWI2h0 dHA6Ly93d3cuZXJpY3Nzb24uY29tL2xlZ2FsLnNodG1sMB0GA1UdDgQWBBQ2hgtYCoOVEiitjMNu mLE8wGuILzAfBgNVHSMEGDAWgBSWJ8O43qVfXUQ+OVLlRbF2X2MwmzAOBgNVHQ8BAf8EBAMCBaAw DQYJKoZIhvcNAQEFBQADggEBAKYJznyxAs6fzHgXDHa00mqyU/+ykFi9HvBv9MSmD2M1X+bifCd6 /jVVrGZWfMfPSV/AbqQjXVQfyHU1R0EqtgEFLyfNVmEGI9lXkkQb5cXNwaJYVj/+ozy+oSu1ZzZA j0GM6NVvhCwGapHoNDPDWe25UdvmOFxxVo6UMq3TWPcSUMq4s3vHLe5n7tgNCdcVUMeqTrAe9cKw TGy7+eJK48rbBcBtKxq2sTY/4H5H6prEKaVlwGW96PydY0IVu4QGVhUT/ONCVByl5xLImDa0tEaX npUj0Y0ys4DneQ3Bxf6DEMuB5+BiSkBk8FmEaSaj2xA/ShtYuaKIO6e9JjpvGb0wggRFMIIDLaAD AgECAhATyer/3iatqdykyiOBg0fjMA0GCSqGSIb3DQEBBQUAMEQxGjAYBgNVBAoMEVRlbGlhU29u ZXJhIEdyb3VwMSYwJAYDVQQDDB1UZWxpYVNvbmVyYSBQdWJsaWMgUm9vdCBDQSB2MTAeFw0wNjEw MDYxMDAwNTNaFw0xNjEwMDIwNTA0MTdaMDkxETAPBgNVBAoMCEVyaWNzc29uMSQwIgYDVQQDDBtF cmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC2EHfkNR7rh8Q8jRhZRD8wsbjzxTuVtscq/p6glZzSeEGBXtRwAqmr6jS8FBiKiBMh79ay537m /SwXO3UKUR45f3YIIp9DjThSd+p2xhG3x4yyc9gczlr8JfOEnPhcdPSKw1P0mUlhUn4ak7t009/Y e/W6x3UZHTwVIAWILIhSq4hyNE4z+RvOtvB9uwQ86lKcxi0mFoLev7acLjh+ZXHzXx1jHAmF0ZaG 79CpbvJcRuWplqgJ6qx+hAjsmCU0Wx07GkyGTh8vUMP9Hlz7oyk+7VOccUiNknXHias1GwM9qBUU Oj8e/xsnaTP0ZfqmKBj3Grh1C9WknlSWagxanCBdAgMBAAGjggE8MIIBODASBgNVHRMBAf8ECDAG AQH/AgEAMEYGA1UdIAQ/MD0wOwYHKoVwIwIBATAwMC4GCCsGAQUFBwIBFiJodHRwczovL3JlcG9z aXRvcnkudHJ1c3QudGVsaWEuY29tMIGJBgNVHR8EgYEwfzB9oHugeYZ3bGRhcDovL2xkYXAudHJ1 c3QudGVsaWEuY29tL2NuPVRlbGlhU29uZXJhJTIwUHVibGljJTIwUm9vdCUyMENBJTIwdjEsbz1U ZWxpYVNvbmVyYSUyMEdyb3VwP2F1dGhvcml0eXJldm9jYXRpb25saXN0P2Jhc2UwDgYDVR0PAQH/ BAQDAgEGMB0GA1UdDgQWBBSWJ8O43qVfXUQ+OVLlRbF2X2MwmzAfBgNVHSMEGDAWgBRF2/CPuBpi oagjG2OIOKPb4Bpi8TANBgkqhkiG9w0BAQUFAAOCAQEAdgBKKkM/jN0WvWpZKZ/2J8IVyL+rT44V L0rjbNNDYXdE/V4ZSFN2uuQmgf1Ckqp2shNLe0NEKt6/sfxit4p/5opPIvzytv6vB7rc2BUs8+ja c7aaNiRuwBCjiT1Wnnm454OOZurzQu0SH81PbBtiwUf4XsEvLOnRRZ+9MO/ecVMCQVmeuzsyCl6y FVbx0zmKW1gPjBEigF8BYZ1Tjazk1pVcKzFIuB24j1qTpPsUG4HoQhIu5rt3F7GlNV6t5DF7ojbg u1SqKG/JhTvaPUU/nZYqw9rkV8Dabwrt27reisobtPp78tolxio3ZcZVk7HQ8rpV2M/jmAjGfZRV kczCDzCCBG0wggNVoAMCAQICEQCcsIwEmsuXInhjYrYbhlo9MA0GCSqGSIb3DQEBBQUAMDoxGTAX BgNVBAoTEFJTQSBTZWN1cml0eSBJbmMxHTAbBgNVBAsTFFJTQSBTZWN1cml0eSAyMDQ4IFYzMB4X DTA2MTAzMTIwNDIyN1oXDTE2MTEwMTE1NDIyNVowRDEaMBgGA1UECgwRVGVsaWFTb25lcmEgR3Jv dXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyk8QA2qQgKt5qZV+EeIDbflmXuUChp2lREEsmO5SAiheQ7lXVjzC xw484cOSMw3fOtGWcf9Fa4Rgdw5j+EgyFgiqNj8b2OTXJHQVj1qf09rmkHTgMIKh6TdKXtV+/43p efVrFmFyhoP/NVrYe92Sv4HhOxs/T749S1OjeGISzIKKMSpwkvmYweYnFgIPkHdUKUIReOh9Ym6e i7AVg6eejD6YPBeV+suzBlXCmC3Zyzj7POLsUVvarNZAaKc0AY+rOUslYfAPo+ZYgwY4IV2KcP/q WhhHahz3khWMWSniWrZoxCi2JcXGVkSn+N+ir0APYwYTBJsrTDWxonEdZkR+rQIDAQABo4IBYjCC AV4wHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFEXb8I+4GmKhqCMb Y4g4o9vgGmLxMBIGA1UdEwEB/wQIMAYBAf8CAQQwgYUGA1UdIAR+MHwwPQYJKoZIhvcNBQYBMDAw LgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wOwYHKoVwIwIB ATAwMC4GCCsGAQUFBwIBFiJodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWEuY29tMHAGA1Ud HwRpMGcwZaBjoGGGX2h0dHA6Ly93d3cucnNhc2VjdXJpdHkuY29tL3Byb2R1Y3RzL2tlb24vcmVw b3NpdG9yeS9jZXJ0aWZpY2F0ZV9zdGF0dXMvUlNBX1NlY3VyaXR5XzIwNDhfdjMuQ1JMMA4GA1Ud DwEB/wQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEABF6aLNgpyJu//O9srUqxB1mYL4TlBJFJtuT1 n/15FpKONU2i/byEtUugHVgoTalpp2Ikuxn2iIgzPbNQ+iu4YnVgQzpuOmzXTN2cITMgwn5AyUoH idMPu2Jo7wobu4Fqg2QrG7WeYANYsQk3Q57mQeuyRkjxluq+93KK2gz/HYjqYkKLjLzOmyrkzwR/ 9aaC3HLFMbCoK0NtyQvS1gkW/HGB5GY1xR9SuOE7CJeS53tqE9CSN6cHQNr+ozuKfzix57T/p6Y8 D23nTD1GZA2ApHdy0sY/HNyU8bQPEpTwrSBxNYYeucYoYNSUSJYkqYa6q/ZG38B3XlcT3TiORrQ2 DzGCAhIwggIOAgEBME0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EwMQIQB+dv5AolhuuXP45pewDqUTAJBgUrDgMCGgUAoIIBGzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2MTAwMzA2MjNaMCMGCSqGSIb3 DQEJBDEWBBQ/nh3mHnpSAZ+1aJmnWO9ClDBuzDBcBgkrBgEEAYI3EAQxTzBNMDkxETAPBgNVBAoM CEVyaWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEAfnb+QKJYbr lz+OaXsA6lEwXgYLKoZIhvcNAQkQAgsxT6BNMDkxETAPBgNVBAoMCEVyaWNzc29uMSQwIgYDVQQD DBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEAfnb+QKJYbrlz+OaXsA6lEwDQYJKoZIhvcN AQEBBQAEgYB/2YLDv74W34I/3NBoCeP+dM6WKcWObvZuINu65hvKKgYPtadlE2qdAhZW+m99wn2o xd/TbpYKlXzizcE7JFTQlqRkNBqisYPUQ4zjzKW/p0n2qbIhxYxzP04yuyfXBUNs8xtJajMg+RTj EGPKy2GkEJG5yoW/Ry3aK33heh6oLAAAAAAAAA== --Apple-Mail-23-8011877-- From christian.vogt@ericsson.com Tue Jun 9 20:49:49 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A7993A67C0 for ; Tue, 9 Jun 2009 20:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNeprxdpZ5-Y for ; Tue, 9 Jun 2009 20:49:48 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 0BA653A6452 for ; Tue, 9 Jun 2009 20:49:47 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n5A3nqZG010949; Tue, 9 Jun 2009 22:49:52 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jun 2009 22:49:49 -0500 Received: from [155.53.234.106] ([155.53.234.106]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jun 2009 22:49:48 -0500 Message-Id: From: Christian Vogt To: Fred Baker , SAVI Mailing List In-Reply-To: <59D15025-814F-4967-84EC-50FCA0225CC1@cisco.com> Content-Type: multipart/signed; boundary=Apple-Mail-24-10616670; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 9 Jun 2009 20:49:46 -0700 References: <59D15025-814F-4967-84EC-50FCA0225CC1@cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 10 Jun 2009 03:49:48.0475 (UTC) FILETIME=[805190B0:01C9E97E] Subject: [savi] On Protecting Unused Addresses in IPv6 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 03:49:49 -0000 --Apple-Mail-24-10616670 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Forked from thread: "Forwarding datagrams without bindings." Fred and all - A few personal comments, which I would like to state outside of my role as a working group chair: Fred, you are calling for a SAVI solution that prevents attackers from hijacking unused addresses. I think you are too ambitious. The only solution proposal on the table that satisfies your requirement is CPS, and we have seen that CPS suffers from the problem of occasional false packet drops. While I would love to see a solution that satisfies your requirement without the risk of false packet drops, I believe that such a solution does not exist. Let me explain why: To prevent attackers from hijacking unused addresses, you need a method to distinguish between used and unused addresses. This, in turn, means that you need a method by which hosts can announce ownership of an address. Such a method must be reliable, since failure to successfully announce ownership of an address could result in false drops of packets originating from that address. Unfortunately, in IPv6, due to Stateless Address Autoconfiguration, there is no reliable way in which hosts can announce ownership of an address. DAD, which does serve the function of announcing address ownerships, is only best-effort. Therefore, if you were to drop packets from apparently unused addresses in IPv6, you would risk that those packet drops are false because the corresponding address ownership announcement might have been unsuccessful. This is why, in IPv6, preventing attackers from hijacking unused addresses inevitably implies a risk of false packet drops. A related question is how important it is in the first place to prevent attackers from hijacking unused addresses in IPv6. After all, the boundary between an IPv6 address being unused and being used is negligible: All an attacker needs to do to turn an unused address into a used address is to send a DAD Neighbor Solicitation. In summary, I think that preventing attackers from hijacking unused addresses is (1) not possible without introducing a risk of false packet drops, and (2) not absolutely necessary. What do you think? Does this make sense? - Christian On Jun 1, 2009, Fred Baker wrote: > Marcelo will, when he gets a few minutes (he is traveling this week), > flesh out the idea that he discussed on the call this morning. While > I'm > thinking about it, I would like to summarize the thought and the > question that was running through my head. > > The discussion related to whether we should set up SAVI bindings using > FCFS only on control datagrams or also on data exchanges. He suggested > that we only set up binding state on control packets but that we > permit > data packets that correspond to no binding (eg, from is an address > that > nobody in the LAN is known to be using) to pass. > > My question goes to the heart of what we are trying to do here. It > seems > to me that SAVI is trying, ultimately, to guarantee that if one system > sends a datagram to another system, the second system's reply will > make > it back to the first system barring system or network failure. Address > spoofing is the obvious attack that we have been trying to prevent - > the > use of a source address such that A sends to B and B's reply is > delivered to some third party. But it seems to me that address > anonymization is also an attack that the technology is trying to > prevent > - if A sends to B, B might reply but the network be systemically > unable > to deliver it and the original source of the datagram is not > determinable. In short, I think SAVI is trying to do more than > "prevent > spoofing", it is trying to ensure that datagrams in the wild are valid > and useful as opposed to being attack traffic. To do that, the point > is > not the negative statement that "it doesn't spoof someone else's > address", the point is the positive statement that "it uses its own > address". > > To make that positive statement, whether we set up bindings on control > or data packets, we can only allow datagrams to pass that originate > from > addresses that are associated with the putative sender, apart from > systems that routinely originate datagrams at L2 from other L3 > addresses, such as routers do. > > In case what I just said is not clear, let me put together an attack > example. We often see DDOS attacks in which some large number of > systems > simultaneously send a datagram to some targeted address using a random > source address. To track these back, what operations folks try to do > is > track the trajectory of those attacking datagrams. The effectiveness > of > the attack is limited by BCP 38 filters (uRPF or whatever), which only > allow packets through for which the random number in fact selected the > right source prefix. But in IPv6, selecting the right /64 still means > one has 2^64 interface identifiers to choose from, and that the > probability of randomly selecting that of a neighbor is pretty low. So > while preventing address spoofing is an obvious goal, simply doing > that > doesn't prevent attacks in which the source address is incorrect; one > also has to prevent address anonymization. > > Which brings us back to the question of address binding. If what we > are > doing is preventing systems from sending from addresses that are not > their own, then there is no real question of interoperating with > non-SAVI switches in other parts of the network. SAVI switches somehow > know which ports connect to hosts (as opposed to routers, switch/ > switch > trunks, and some kinds of servers), and drop datagrams they send that > are not from addresses bound to them. If one wants to have a SAVI > network, one doesn't try to be backward compatible with non-SAVI > equipment, one replaces non-SAVI equipment with SAVI equipment, > hopefully by an upgrade for large switches, but for consumer grade > equipment by replacing it. The one case where that does not follow > is a > desktop switch, in which the larger switch may not be able to > distinguish between a virtual host and a set of hosts connected by a 5 > port potentially-non-SAVI switch and that to the wall; there, the big > switch might associate IPv6 addresses with MAC Addresses and those in > turn with a port. --Apple-Mail-24-10616670 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8DCCBDIw ggMaoAMCAQICEAfnb+QKJYbrlz+OaXsA6lEwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0wNzA5MTMxMTI5 MTRaFw0xMDA5MTMxMTI5MTBaMGoxETAPBgNVBAoMCEVyaWNzc29uMRcwFQYDVQQDDA5DaHJpc3Rp YW4gVm9ndDEQMA4GA1UEBRMHZWNocnZvZzEqMCgGCSqGSIb3DQEJARYbY2hyaXN0aWFuLnZvZ3RA ZXJpY3Nzb24uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCVGNN5yyhnvz5VWwGDcmey bI9H/DGF0LQmxS+L3gJ9gJIAQ2NPhF16dsWnlpCwS+VsKwMRfh3BsYGY88Hlx/Yvo6NfqE6evobv prxbgKiFP7j1c7Ntke/6SRamUVPFnWrFuaOuXTwU7GUAd/uOoCRNs/nq1hdQRC684gX/kAfBYwID AQABo4IBhzCCAYMwgcAGA1UdHwSBuDCBtTCBsqCBr6CBrIY3aHR0cDovL2NybC50cnVzdC50ZWxp YS5jb20vRXJpY3Nzb25OTEluZGl2aWR1YWxDQTAxLmNybIZxbGRhcDovL2xkYXAudHJ1c3QudGVs aWEuY29tL2NuPUVyaWNzc29uJTIwTkwlMjBJbmRpdmlkdWFsJTIwQ0EwMSxvPUVyaWNzc29uP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2UwJgYDVR0RBB8wHYEbY2hyaXN0aWFu LnZvZ3RAZXJpY3Nzb24uY29tMEYGA1UdIAQ/MD0wOwYGKoVwawEBMDEwLwYIKwYBBQUHAgEWI2h0 dHA6Ly93d3cuZXJpY3Nzb24uY29tL2xlZ2FsLnNodG1sMB0GA1UdDgQWBBQ2hgtYCoOVEiitjMNu mLE8wGuILzAfBgNVHSMEGDAWgBSWJ8O43qVfXUQ+OVLlRbF2X2MwmzAOBgNVHQ8BAf8EBAMCBaAw DQYJKoZIhvcNAQEFBQADggEBAKYJznyxAs6fzHgXDHa00mqyU/+ykFi9HvBv9MSmD2M1X+bifCd6 /jVVrGZWfMfPSV/AbqQjXVQfyHU1R0EqtgEFLyfNVmEGI9lXkkQb5cXNwaJYVj/+ozy+oSu1ZzZA j0GM6NVvhCwGapHoNDPDWe25UdvmOFxxVo6UMq3TWPcSUMq4s3vHLe5n7tgNCdcVUMeqTrAe9cKw TGy7+eJK48rbBcBtKxq2sTY/4H5H6prEKaVlwGW96PydY0IVu4QGVhUT/ONCVByl5xLImDa0tEaX npUj0Y0ys4DneQ3Bxf6DEMuB5+BiSkBk8FmEaSaj2xA/ShtYuaKIO6e9JjpvGb0wggRFMIIDLaAD AgECAhATyer/3iatqdykyiOBg0fjMA0GCSqGSIb3DQEBBQUAMEQxGjAYBgNVBAoMEVRlbGlhU29u ZXJhIEdyb3VwMSYwJAYDVQQDDB1UZWxpYVNvbmVyYSBQdWJsaWMgUm9vdCBDQSB2MTAeFw0wNjEw MDYxMDAwNTNaFw0xNjEwMDIwNTA0MTdaMDkxETAPBgNVBAoMCEVyaWNzc29uMSQwIgYDVQQDDBtF cmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC2EHfkNR7rh8Q8jRhZRD8wsbjzxTuVtscq/p6glZzSeEGBXtRwAqmr6jS8FBiKiBMh79ay537m /SwXO3UKUR45f3YIIp9DjThSd+p2xhG3x4yyc9gczlr8JfOEnPhcdPSKw1P0mUlhUn4ak7t009/Y e/W6x3UZHTwVIAWILIhSq4hyNE4z+RvOtvB9uwQ86lKcxi0mFoLev7acLjh+ZXHzXx1jHAmF0ZaG 79CpbvJcRuWplqgJ6qx+hAjsmCU0Wx07GkyGTh8vUMP9Hlz7oyk+7VOccUiNknXHias1GwM9qBUU Oj8e/xsnaTP0ZfqmKBj3Grh1C9WknlSWagxanCBdAgMBAAGjggE8MIIBODASBgNVHRMBAf8ECDAG AQH/AgEAMEYGA1UdIAQ/MD0wOwYHKoVwIwIBATAwMC4GCCsGAQUFBwIBFiJodHRwczovL3JlcG9z aXRvcnkudHJ1c3QudGVsaWEuY29tMIGJBgNVHR8EgYEwfzB9oHugeYZ3bGRhcDovL2xkYXAudHJ1 c3QudGVsaWEuY29tL2NuPVRlbGlhU29uZXJhJTIwUHVibGljJTIwUm9vdCUyMENBJTIwdjEsbz1U ZWxpYVNvbmVyYSUyMEdyb3VwP2F1dGhvcml0eXJldm9jYXRpb25saXN0P2Jhc2UwDgYDVR0PAQH/ BAQDAgEGMB0GA1UdDgQWBBSWJ8O43qVfXUQ+OVLlRbF2X2MwmzAfBgNVHSMEGDAWgBRF2/CPuBpi oagjG2OIOKPb4Bpi8TANBgkqhkiG9w0BAQUFAAOCAQEAdgBKKkM/jN0WvWpZKZ/2J8IVyL+rT44V L0rjbNNDYXdE/V4ZSFN2uuQmgf1Ckqp2shNLe0NEKt6/sfxit4p/5opPIvzytv6vB7rc2BUs8+ja c7aaNiRuwBCjiT1Wnnm454OOZurzQu0SH81PbBtiwUf4XsEvLOnRRZ+9MO/ecVMCQVmeuzsyCl6y FVbx0zmKW1gPjBEigF8BYZ1Tjazk1pVcKzFIuB24j1qTpPsUG4HoQhIu5rt3F7GlNV6t5DF7ojbg u1SqKG/JhTvaPUU/nZYqw9rkV8Dabwrt27reisobtPp78tolxio3ZcZVk7HQ8rpV2M/jmAjGfZRV kczCDzCCBG0wggNVoAMCAQICEQCcsIwEmsuXInhjYrYbhlo9MA0GCSqGSIb3DQEBBQUAMDoxGTAX BgNVBAoTEFJTQSBTZWN1cml0eSBJbmMxHTAbBgNVBAsTFFJTQSBTZWN1cml0eSAyMDQ4IFYzMB4X DTA2MTAzMTIwNDIyN1oXDTE2MTEwMTE1NDIyNVowRDEaMBgGA1UECgwRVGVsaWFTb25lcmEgR3Jv dXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyk8QA2qQgKt5qZV+EeIDbflmXuUChp2lREEsmO5SAiheQ7lXVjzC xw484cOSMw3fOtGWcf9Fa4Rgdw5j+EgyFgiqNj8b2OTXJHQVj1qf09rmkHTgMIKh6TdKXtV+/43p efVrFmFyhoP/NVrYe92Sv4HhOxs/T749S1OjeGISzIKKMSpwkvmYweYnFgIPkHdUKUIReOh9Ym6e i7AVg6eejD6YPBeV+suzBlXCmC3Zyzj7POLsUVvarNZAaKc0AY+rOUslYfAPo+ZYgwY4IV2KcP/q WhhHahz3khWMWSniWrZoxCi2JcXGVkSn+N+ir0APYwYTBJsrTDWxonEdZkR+rQIDAQABo4IBYjCC AV4wHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFEXb8I+4GmKhqCMb Y4g4o9vgGmLxMBIGA1UdEwEB/wQIMAYBAf8CAQQwgYUGA1UdIAR+MHwwPQYJKoZIhvcNBQYBMDAw LgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wOwYHKoVwIwIB ATAwMC4GCCsGAQUFBwIBFiJodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWEuY29tMHAGA1Ud HwRpMGcwZaBjoGGGX2h0dHA6Ly93d3cucnNhc2VjdXJpdHkuY29tL3Byb2R1Y3RzL2tlb24vcmVw b3NpdG9yeS9jZXJ0aWZpY2F0ZV9zdGF0dXMvUlNBX1NlY3VyaXR5XzIwNDhfdjMuQ1JMMA4GA1Ud DwEB/wQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEABF6aLNgpyJu//O9srUqxB1mYL4TlBJFJtuT1 n/15FpKONU2i/byEtUugHVgoTalpp2Ikuxn2iIgzPbNQ+iu4YnVgQzpuOmzXTN2cITMgwn5AyUoH idMPu2Jo7wobu4Fqg2QrG7WeYANYsQk3Q57mQeuyRkjxluq+93KK2gz/HYjqYkKLjLzOmyrkzwR/ 9aaC3HLFMbCoK0NtyQvS1gkW/HGB5GY1xR9SuOE7CJeS53tqE9CSN6cHQNr+ozuKfzix57T/p6Y8 D23nTD1GZA2ApHdy0sY/HNyU8bQPEpTwrSBxNYYeucYoYNSUSJYkqYa6q/ZG38B3XlcT3TiORrQ2 DzGCAhIwggIOAgEBME0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EwMQIQB+dv5AolhuuXP45pewDqUTAJBgUrDgMCGgUAoIIBGzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2MTAwMzQ5NDlaMCMGCSqGSIb3 DQEJBDEWBBSyxa+CHYd4ahRtw46VMwsZhu7oRTBcBgkrBgEEAYI3EAQxTzBNMDkxETAPBgNVBAoM CEVyaWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEAfnb+QKJYbr lz+OaXsA6lEwXgYLKoZIhvcNAQkQAgsxT6BNMDkxETAPBgNVBAoMCEVyaWNzc29uMSQwIgYDVQQD DBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEAfnb+QKJYbrlz+OaXsA6lEwDQYJKoZIhvcN AQEBBQAEgYAJOOchZm5Re9sNFYXTV/fzfzLh9KmuhuyXCNmRy179fFeyXOByOI+NoUCIxNIjh/TP QdTqONacaZlskWCmmfX1HZAS31LAGyit3ldWuyWqHRitil7oNj7GDZ647JuGpuyij+shM0zpqhA7 ggz5MdXvNyD0ufTJmK49WVpsDXz6dgAAAAAAAA== --Apple-Mail-24-10616670-- From gdaley@netstarnetworks.com Tue Jun 9 21:08:56 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADCD73A67AD for ; Tue, 9 Jun 2009 21:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyUxlVCmOPUm for ; Tue, 9 Jun 2009 21:08:55 -0700 (PDT) Received: from mail.syd.netstarnetworks.com (mail.syd.netstarnetworks.com [203.8.7.220]) by core3.amsl.com (Postfix) with ESMTP id 21FDF3A6359 for ; Tue, 9 Jun 2009 21:08:54 -0700 (PDT) Received: from sydmail.netstarnetworks.com ([10.18.193.13]) by mail.syd.netstarnetworks.com (8.12.8/8.12.8) with ESMTP id n5A48NRs014887; Wed, 10 Jun 2009 14:08:23 +1000 Received: from melmail.netstarnetworks.com ([10.20.193.13]) by sydmail.netstarnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Jun 2009 14:08:15 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Jun 2009 14:08:14 +1000 Message-ID: <6983BF97BFC24D4EA551F14071232918010CD676@melmail.netstarnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [savi] On Protecting Unused Addresses in IPv6 Thread-Index: AcnpfoeSEUIxg1AsSFyoTwj9UGTpbAAANveg References: <59D15025-814F-4967-84EC-50FCA0225CC1@cisco.com> From: "Greg Daley" To: "Christian Vogt" , "Fred Baker" , "SAVI Mailing List" X-OriginalArrivalTime: 10 Jun 2009 04:08:15.0729 (UTC) FILETIME=[144B1E10:01C9E981] Subject: Re: [savi] On Protecting Unused Addresses in IPv6 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 04:08:56 -0000 Hi Chris,=20 I think that if a prefix must be statefully configured, it would be possible to make use of DHCPv6 to=20 control address allocation for those prefixes. Devices could be configured with such prefixes, or identify them by seeing Router Advertisements. Devices which do not get addresses allocated via DHCP then do not get transmission rights. This is essentially what some deployed products do today with IPv4. It is fairly reliable, although I personally have reservations about what should be done in the case of state loss on the snooping device (for IPv4). =20 This may actually be an important use case: Spoofing on address managed networks. Greg Daley Security Consultant NetStar Australia Pty Ltd E-mail: gdaley@netstarnetworks.com Mobile: +61 401 772 770 Direct: +61 3 8532 4042 Fax: +61 3 8532 4032 -----Original Message----- From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Christian Vogt Sent: Wednesday, 10 June 2009 1:50 PM To: Fred Baker; SAVI Mailing List Subject: [savi] On Protecting Unused Addresses in IPv6 Forked from thread: "Forwarding datagrams without bindings." Fred and all - A few personal comments, which I would like to state outside of my role as a working group chair: Fred, you are calling for a SAVI solution that prevents attackers from hijacking unused addresses. I think you are too ambitious. The only solution proposal on the table that satisfies your requirement is CPS, and we have seen that CPS suffers from the problem of occasional false packet drops. While I would love to see a solution that satisfies your requirement without the risk of false packet drops, I believe that such a solution does not exist. Let me explain why: To prevent attackers from hijacking unused addresses, you need a method to distinguish between used and unused addresses. This, in turn, means that you need a method by which hosts can announce ownership of an address. Such a method must be reliable, since failure to successfully announce ownership of an address could result in false drops of packets originating from that address. Unfortunately, in IPv6, due to Stateless Address Autoconfiguration, there is no reliable way in which hosts can announce ownership of an address. DAD, which does serve the function of announcing address ownerships, is only best-effort. Therefore, if you were to drop packets from apparently unused addresses in IPv6, you would risk that those packet drops are false because the corresponding address ownership announcement might have been unsuccessful. This is why, in IPv6, preventing attackers from hijacking unused addresses inevitably implies a risk of false packet drops. A related question is how important it is in the first place to prevent attackers from hijacking unused addresses in IPv6. After all, the boundary between an IPv6 address being unused and being used is negligible: All an attacker needs to do to turn an unused address into a used address is to send a DAD Neighbor Solicitation. In summary, I think that preventing attackers from hijacking unused addresses is (1) not possible without introducing a risk of false packet drops, and (2) not absolutely necessary. What do you think? Does this make sense? - Christian On Jun 1, 2009, Fred Baker wrote: > Marcelo will, when he gets a few minutes (he is traveling this week),=20 > flesh out the idea that he discussed on the call this morning. While=20 > I'm thinking about it, I would like to summarize the thought and the=20 > question that was running through my head. > > The discussion related to whether we should set up SAVI bindings using > FCFS only on control datagrams or also on data exchanges. He suggested > that we only set up binding state on control packets but that we=20 > permit data packets that correspond to no binding (eg, from is an=20 > address that nobody in the LAN is known to be using) to pass. > > My question goes to the heart of what we are trying to do here. It=20 > seems to me that SAVI is trying, ultimately, to guarantee that if one=20 > system sends a datagram to another system, the second system's reply=20 > will make it back to the first system barring system or network=20 > failure. Address spoofing is the obvious attack that we have been=20 > trying to prevent - the use of a source address such that A sends to B > and B's reply is delivered to some third party. But it seems to me=20 > that address anonymization is also an attack that the technology is=20 > trying to prevent > - if A sends to B, B might reply but the network be systemically=20 > unable to deliver it and the original source of the datagram is not=20 > determinable. In short, I think SAVI is trying to do more than=20 > "prevent spoofing", it is trying to ensure that datagrams in the wild=20 > are valid and useful as opposed to being attack traffic. To do that,=20 > the point is not the negative statement that "it doesn't spoof someone > else's address", the point is the positive statement that "it uses its > own address". > > To make that positive statement, whether we set up bindings on control > or data packets, we can only allow datagrams to pass that originate=20 > from addresses that are associated with the putative sender, apart=20 > from systems that routinely originate datagrams at L2 from other L3=20 > addresses, such as routers do. > > In case what I just said is not clear, let me put together an attack=20 > example. We often see DDOS attacks in which some large number of=20 > systems simultaneously send a datagram to some targeted address using=20 > a random source address. To track these back, what operations folks=20 > try to do is track the trajectory of those attacking datagrams. The=20 > effectiveness of the attack is limited by BCP 38 filters (uRPF or=20 > whatever), which only allow packets through for which the random=20 > number in fact selected the right source prefix. But in IPv6,=20 > selecting the right /64 still means one has 2^64 interface identifiers > to choose from, and that the probability of randomly selecting that of > a neighbor is pretty low. So while preventing address spoofing is an=20 > obvious goal, simply doing that doesn't prevent attacks in which the=20 > source address is incorrect; one also has to prevent address=20 > anonymization. > > Which brings us back to the question of address binding. If what we=20 > are doing is preventing systems from sending from addresses that are=20 > not their own, then there is no real question of interoperating with=20 > non-SAVI switches in other parts of the network. SAVI switches somehow > know which ports connect to hosts (as opposed to routers, switch/=20 > switch trunks, and some kinds of servers), and drop datagrams they=20 > send that are not from addresses bound to them. If one wants to have a > SAVI network, one doesn't try to be backward compatible with non-SAVI=20 > equipment, one replaces non-SAVI equipment with SAVI equipment,=20 > hopefully by an upgrade for large switches, but for consumer grade=20 > equipment by replacing it. The one case where that does not follow is=20 > a desktop switch, in which the larger switch may not be able to=20 > distinguish between a virtual host and a set of hosts connected by a 5 > port potentially-non-SAVI switch and that to the wall; there, the big=20 > switch might associate IPv6 addresses with MAC Addresses and those in=20 > turn with a port. From marcelo@it.uc3m.es Wed Jun 10 01:28:56 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2B253A6DA5 for ; Wed, 10 Jun 2009 01:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.74 X-Spam-Level: X-Spam-Status: No, score=-6.74 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xv6oU768Flco for ; Wed, 10 Jun 2009 01:28:55 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 2319D3A6CD5 for ; Wed, 10 Jun 2009 01:28:54 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (119.pool85-53-144.dynamic.orange.es [85.53.144.119]) by smtp03.uc3m.es (Postfix) with ESMTP id BDE027325FF; Wed, 10 Jun 2009 10:28:59 +0200 (CEST) Message-ID: <4A2F6ECB.2010400@it.uc3m.es> Date: Wed, 10 Jun 2009 10:28:59 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christian Vogt References: <59D15025-814F-4967-84EC-50FCA0225CC1@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16694.005 Cc: SAVI Mailing List Subject: Re: [savi] On Protecting Unused Addresses in IPv6 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 08:28:56 -0000 Christian Vogt escribió: > Forked from thread: "Forwarding datagrams without bindings." > > > Fred and all - > > A few personal comments, which I would like to state outside of my role > as a working group chair: Fred, you are calling for a SAVI solution > that prevents attackers from hijacking unused addresses. I fail to see what this means. Whether you use CPS or FCFS, an attacker can simply send a DAD and acquire an address that is unused... So what exactly means to prevent hijacking of unused addresses to you? > I think you > are too ambitious. > > The only solution proposal on the table that satisfies your requirement > is CPS, i disagree. You can use FCFS and eventually a savi protocol to propagate the information and you reach a similar level of security (wihtout the false drop problem) > and we have seen that CPS suffers from the problem of occasional > false packet drops. While I would love to see a solution that satisfies > your requirement without the risk of false packet drops, I believe that > such a solution does not exist. Let me explain why: > > To prevent attackers from hijacking unused addresses, you need a method > to distinguish between used and unused addresses. This, in turn, means > that you need a method by which hosts can announce ownership of an > address. Such a method must be reliable, since failure to successfully > announce ownership of an address could result in false drops of packets > originating from that address. Unfortunately, in IPv6, due to Stateless > Address Autoconfiguration, there is no reliable way in which hosts can > announce ownership of an address. DAD, which does serve the function of > announcing address ownerships, is only best-effort. Therefore, if you > were to drop packets from apparently unused addresses in IPv6, you would > risk that those packet drops are false because the corresponding address > ownership announcement might have been unsuccessful. This is why, in > IPv6, preventing attackers from hijacking unused addresses inevitably > implies a risk of false packet drops. > i agree with all the argument above, i.e. you cannot rely on DAD to grant access to the network. My only discrpancy is that DAD does not actually provide hijacking of unused addresses since an attacker can perform dad as well an get the address (bypassing DAD) In other words, i don't understand what it means to protect an unused address in the stateless autoconf case > A related question is how important it is in the first place to prevent > attackers from hijacking unused addresses in IPv6. After all, the > boundary between an IPv6 address being unused and being used is > negligible: All an attacker needs to do to turn an unused address into > a used address is to send a DAD Neighbor Solicitation. > exactly! > In summary, I think that preventing attackers from hijacking unused > addresses is i think these are true for using DAD to grant access to the network, > (1) not possible without introducing a risk of false packet > drops, and (2) not absolutely necessary. > > What do you think? Does this make sense? > > - Christian > > > > On Jun 1, 2009, Fred Baker wrote: > >> Marcelo will, when he gets a few minutes (he is traveling this week), >> flesh out the idea that he discussed on the call this morning. While I'm >> thinking about it, I would like to summarize the thought and the >> question that was running through my head. >> >> The discussion related to whether we should set up SAVI bindings using >> FCFS only on control datagrams or also on data exchanges. He suggested >> that we only set up binding state on control packets but that we permit >> data packets that correspond to no binding (eg, from is an address that >> nobody in the LAN is known to be using) to pass. >> >> My question goes to the heart of what we are trying to do here. It seems >> to me that SAVI is trying, ultimately, to guarantee that if one system >> sends a datagram to another system, the second system's reply will make >> it back to the first system barring system or network failure. Address >> spoofing is the obvious attack that we have been trying to prevent - the >> use of a source address such that A sends to B and B's reply is >> delivered to some third party. But it seems to me that address >> anonymization is also an attack that the technology is trying to prevent >> - if A sends to B, B might reply but the network be systemically unable >> to deliver it and the original source of the datagram is not >> determinable. In short, I think SAVI is trying to do more than "prevent >> spoofing", it is trying to ensure that datagrams in the wild are valid >> and useful as opposed to being attack traffic. To do that, the point is >> not the negative statement that "it doesn't spoof someone else's >> address", the point is the positive statement that "it uses its own >> address". >> >> To make that positive statement, whether we set up bindings on control >> or data packets, we can only allow datagrams to pass that originate from >> addresses that are associated with the putative sender, apart from >> systems that routinely originate datagrams at L2 from other L3 >> addresses, such as routers do. >> >> In case what I just said is not clear, let me put together an attack >> example. We often see DDOS attacks in which some large number of systems >> simultaneously send a datagram to some targeted address using a random >> source address. To track these back, what operations folks try to do is >> track the trajectory of those attacking datagrams. The effectiveness of >> the attack is limited by BCP 38 filters (uRPF or whatever), which only >> allow packets through for which the random number in fact selected the >> right source prefix. But in IPv6, selecting the right /64 still means >> one has 2^64 interface identifiers to choose from, and that the >> probability of randomly selecting that of a neighbor is pretty low. So >> while preventing address spoofing is an obvious goal, simply doing that >> doesn't prevent attacks in which the source address is incorrect; one >> also has to prevent address anonymization. >> >> Which brings us back to the question of address binding. If what we are >> doing is preventing systems from sending from addresses that are not >> their own, then there is no real question of interoperating with >> non-SAVI switches in other parts of the network. SAVI switches somehow >> know which ports connect to hosts (as opposed to routers, switch/switch >> trunks, and some kinds of servers), and drop datagrams they send that >> are not from addresses bound to them. If one wants to have a SAVI >> network, one doesn't try to be backward compatible with non-SAVI >> equipment, one replaces non-SAVI equipment with SAVI equipment, >> hopefully by an upgrade for large switches, but for consumer grade >> equipment by replacing it. The one case where that does not follow is a >> desktop switch, in which the larger switch may not be able to >> distinguish between a virtual host and a set of hosts connected by a 5 >> port potentially-non-SAVI switch and that to the wall; there, the big >> switch might associate IPv6 addresses with MAC Addresses and those in >> turn with a port. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From marcelo@it.uc3m.es Wed Jun 10 01:31:27 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4238C3A6DD8 for ; Wed, 10 Jun 2009 01:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.725 X-Spam-Level: X-Spam-Status: No, score=-6.725 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8vnuWjfmB8X for ; Wed, 10 Jun 2009 01:31:26 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 93EAE3A6CD5 for ; Wed, 10 Jun 2009 01:31:25 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (119.pool85-53-144.dynamic.orange.es [85.53.144.119]) by smtp02.uc3m.es (Postfix) with ESMTP id 2BA1E657410; Wed, 10 Jun 2009 10:31:30 +0200 (CEST) Message-ID: <4A2F6F60.1040007@it.uc3m.es> Date: Wed, 10 Jun 2009 10:31:28 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Greg Daley References: <59D15025-814F-4967-84EC-50FCA0225CC1@cisco.com> <6983BF97BFC24D4EA551F14071232918010CD676@melmail.netstarnetworks.com> In-Reply-To: <6983BF97BFC24D4EA551F14071232918010CD676@melmail.netstarnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16694.005 Cc: SAVI Mailing List , Christian Vogt Subject: Re: [savi] On Protecting Unused Addresses in IPv6 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 08:31:27 -0000 Greg Daley escribió: > Hi Chris, > > I think that if a prefix must be statefully configured, it would be > possible to make use of DHCPv6 to > control address allocation for those prefixes. Devices could be > configured with such prefixes, > or identify them by seeing Router Advertisements. > mmm, this would be essentially a subset of what ingress filtering does, right? i mean verifying that the prefix comes from the subnet that the prefix was assigned. The current scope of SAVI assumes that we have ingress filtering and attempts to increase the security i.e. we are assuming that the prefix cannot be spoofed, and we try to say something about the address. Regards, marcelo > Devices which do not get addresses allocated via DHCP then do not get > transmission rights. > > This is essentially what some deployed products do today with IPv4. It > is fairly reliable, although > I personally have reservations about what should be done in the case of > state loss on the snooping device > (for IPv4). > > This may actually be an important use case: Spoofing on address managed > networks. > > Greg Daley > Security Consultant > NetStar Australia Pty Ltd > > E-mail: gdaley@netstarnetworks.com > Mobile: +61 401 772 770 > Direct: +61 3 8532 4042 > Fax: +61 3 8532 4032 > -----Original Message----- > From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of > Christian Vogt > Sent: Wednesday, 10 June 2009 1:50 PM > To: Fred Baker; SAVI Mailing List > Subject: [savi] On Protecting Unused Addresses in IPv6 > > Forked from thread: "Forwarding datagrams without bindings." > > > Fred and all - > > A few personal comments, which I would like to state outside of my role > as a working group chair: Fred, you are calling for a SAVI solution > that prevents attackers from hijacking unused addresses. I think you > are too ambitious. > > The only solution proposal on the table that satisfies your requirement > is CPS, and we have seen that CPS suffers from the problem of occasional > false packet drops. While I would love to see a solution that satisfies > your requirement without the risk of false packet drops, I believe that > such a solution does not exist. Let me explain why: > > To prevent attackers from hijacking unused addresses, you need a method > to distinguish between used and unused addresses. This, in turn, means > that you need a method by which hosts can announce ownership of an > address. Such a method must be reliable, since failure to successfully > announce ownership of an address could result in false drops of packets > originating from that address. Unfortunately, in IPv6, due to Stateless > Address Autoconfiguration, there is no reliable way in which hosts can > announce ownership of an address. DAD, which does serve the function of > announcing address ownerships, is only best-effort. Therefore, if you > were to drop packets from apparently unused addresses in IPv6, you would > risk that those packet drops are false because the corresponding address > ownership announcement might have been unsuccessful. This is why, in > IPv6, preventing attackers from hijacking unused addresses inevitably > implies a risk of false packet drops. > > A related question is how important it is in the first place to prevent > attackers from hijacking unused addresses in IPv6. After all, the > boundary between an IPv6 address being unused and being used is > negligible: All an attacker needs to do to turn an unused address into > a used address is to send a DAD Neighbor Solicitation. > > In summary, I think that preventing attackers from hijacking unused > addresses is (1) not possible without introducing a risk of false packet > drops, and (2) not absolutely necessary. > > What do you think? Does this make sense? > > - Christian > > > > On Jun 1, 2009, Fred Baker wrote: > > >> Marcelo will, when he gets a few minutes (he is traveling this week), >> flesh out the idea that he discussed on the call this morning. While >> I'm thinking about it, I would like to summarize the thought and the >> question that was running through my head. >> >> The discussion related to whether we should set up SAVI bindings using >> > > >> FCFS only on control datagrams or also on data exchanges. He suggested >> > > >> that we only set up binding state on control packets but that we >> permit data packets that correspond to no binding (eg, from is an >> address that nobody in the LAN is known to be using) to pass. >> >> My question goes to the heart of what we are trying to do here. It >> seems to me that SAVI is trying, ultimately, to guarantee that if one >> system sends a datagram to another system, the second system's reply >> will make it back to the first system barring system or network >> failure. Address spoofing is the obvious attack that we have been >> trying to prevent - the use of a source address such that A sends to B >> > > >> and B's reply is delivered to some third party. But it seems to me >> that address anonymization is also an attack that the technology is >> trying to prevent >> - if A sends to B, B might reply but the network be systemically >> unable to deliver it and the original source of the datagram is not >> determinable. In short, I think SAVI is trying to do more than >> "prevent spoofing", it is trying to ensure that datagrams in the wild >> are valid and useful as opposed to being attack traffic. To do that, >> the point is not the negative statement that "it doesn't spoof someone >> > > >> else's address", the point is the positive statement that "it uses its >> > > >> own address". >> >> To make that positive statement, whether we set up bindings on control >> > > >> or data packets, we can only allow datagrams to pass that originate >> from addresses that are associated with the putative sender, apart >> from systems that routinely originate datagrams at L2 from other L3 >> addresses, such as routers do. >> >> In case what I just said is not clear, let me put together an attack >> example. We often see DDOS attacks in which some large number of >> systems simultaneously send a datagram to some targeted address using >> a random source address. To track these back, what operations folks >> try to do is track the trajectory of those attacking datagrams. The >> effectiveness of the attack is limited by BCP 38 filters (uRPF or >> whatever), which only allow packets through for which the random >> number in fact selected the right source prefix. But in IPv6, >> selecting the right /64 still means one has 2^64 interface identifiers >> > > >> to choose from, and that the probability of randomly selecting that of >> > > >> a neighbor is pretty low. So while preventing address spoofing is an >> obvious goal, simply doing that doesn't prevent attacks in which the >> source address is incorrect; one also has to prevent address >> anonymization. >> >> Which brings us back to the question of address binding. If what we >> are doing is preventing systems from sending from addresses that are >> not their own, then there is no real question of interoperating with >> non-SAVI switches in other parts of the network. SAVI switches somehow >> > > >> know which ports connect to hosts (as opposed to routers, switch/ >> switch trunks, and some kinds of servers), and drop datagrams they >> send that are not from addresses bound to them. If one wants to have a >> > > >> SAVI network, one doesn't try to be backward compatible with non-SAVI >> equipment, one replaces non-SAVI equipment with SAVI equipment, >> hopefully by an upgrade for large switches, but for consumer grade >> equipment by replacing it. The one case where that does not follow is >> a desktop switch, in which the larger switch may not be able to >> distinguish between a virtual host and a set of hosts connected by a 5 >> > > >> port potentially-non-SAVI switch and that to the wall; there, the big >> switch might associate IPv6 addresses with MAC Addresses and those in >> turn with a port. >> > > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > > From elevyabe@cisco.com Wed Jun 10 04:51:03 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 192DA3A69C3 for ; Wed, 10 Jun 2009 04:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxtPWvu5a4Wv for ; Wed, 10 Jun 2009 04:51:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9B0B43A6833 for ; Wed, 10 Jun 2009 04:51:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,341,1241395200"; d="scan'208";a="42483406" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 10 Jun 2009 11:51:06 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5ABp6FH002117; Wed, 10 Jun 2009 13:51:06 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5ABp6Ru016706; Wed, 10 Jun 2009 11:51:06 GMT Received: from xmb-ams-335.cisco.com ([144.254.231.80]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jun 2009 13:51:06 +0200 Received: from [144.254.53.102] ([144.254.53.102]) by xmb-ams-335.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jun 2009 13:51:05 +0200 Message-ID: <4A2F9E29.5070704@cisco.com> Date: Wed, 10 Jun 2009 13:51:05 +0200 From: Eric Levy-Abegnoli User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: marcelo bagnulo braun References: <4A2C0DFB.3040803@it.uc3m.es> <4A2D2221.4030503@cisco.com> <4A2D2739.1000206@it.uc3m.es> In-Reply-To: <4A2D2739.1000206@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 10 Jun 2009 11:51:05.0815 (UTC) FILETIME=[BC8DF670:01C9E9C1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12509; t=1244634666; x=1245498666; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=elevyabe@cisco.com; z=From:=20Eric=20Levy-Abegnoli=20 |Subject:=20Re=3A=20[savi]=20A=20different=20trade=20off=20 for=20SAVI |Sender:=20; bh=ouhkkAjrS4v9Zr1iDgrJB2FbNoim2q2X4eY8X2kVjR4=; b=r2u+UeRTCVTBa2v+s148R1yin7Z45ISvXjtwgIGkkYoLRZ6Gn2Mgwy546R tMT8yYfZg2/yydYiEVS2Yh9KYbdEWuHaWAeGln8b7+ysT2aEeG3gIhUseONr vvssZBgZS4; Authentication-Results: ams-dkim-2; header.From=elevyabe@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 11:51:03 -0000 marcelo bagnulo braun a écrit : > Eric Levy-Abegnoli escribió: >> marcelo bagnulo braun a écrit : >>> Over the last few weeks, we have been discussing different approaches >>> for SAVI to be used in conjunction IPv6 stateless address >>> autconfiguration. >>> the different proposed approaches have different pros and cons, due to >>> different tradeoffs being made. >>> In this email, i describe an intermediate approach that may be worth >>> to be considered. >>> >>> So, i will first try to summarize the design questions that we have >>> been considering. >>> The first question is whether we create bindings using only DAD packets >>> or we also create bindings using data packet. >> There is something "in-between" DAD and data: other NDP messages. If >> the savi device misses the DAD packet, chances are that the binding >> owner will soon send another NDP message. > you could go down the paht the SAVI device looks into every ND packet > and interprets them and based on that it infers who is the owner of > each address. The problem here is that we will need to make inferences > from different ND packets, depending on how they are dsitributed (i.e. > depending if they are send to all nodes, to a multicast group or to a > node). That would essentially imply that any change in the ND spec > would potentially have an impact on the SAVI spec and it would result > in hardcoding the current ND behaviour. BEsides, the complexity > increases since each ND exchange need to be tracked uan understood by > the SAVI device to properly infer the resulting binding. Not every packets. packets carrying binding information. And credentials (CGA, ...). Relying on the sole L2 information of DAD packets is going to lead to approximations that will then lead to loose decisions. >> Typically, it will send an NA to all-nodes. > what NA would that be? 7.2.6. Sending Unsolicited Neighbor Advertisements It's not "required". However, pretty much all IPv6 implementations are sending NA to "all nodes" with override nit on, when the interface goes up. >> It will also at some point have to resolve its neighbors addresses. >> Those messages are not "required" by the protocol, or they could >> happen prior to DAD for a given address. However, snooping them (and >> using them for build the binding table) will greatly lower the >> chances that the binding was missed.. >> >> For end-nodes attached to the savi switch via an access port, it is >> not un-reasonnable to assume that the switch should have learn a >> binding prior to see a data packet carrying it. >> However, when the end-node is attached to the savi switch_A via >> another switch_B (trunk port), this maybe problematic. Because the >> savi switch_A could typically come up long after switch_B and all >> nodes attached to switch_B have already done DAD etc. Chances that >> switch_A missed the bindings are much higher than the one of a DAD >> packet getting lost. > right, so are you arguing that a solution that solely relies on DAD is > not enough in your opinion? I am arguing that if we look at more than DAD packets, we decrease the already low chances that the information is missed. Making sure the L2 and L3/LLA are consistent has also some value. > >> One policy for switch_A could be to not_drop anything coming over a >> "savi-trunk", a trunk connected to a savi-device, relying on switch_B >> to drop traffic from the node "directly-attached" to it (if no >> binding is available). That way you don't really need to have the >> switches synchronysing their binding table. > but it would imply that you need to configure which ports are > connected to hosts and which ones are connected to other savi devices, > right? > and that is likely to be a manual configuration, right? > and if the topology changes you would need to update that, correct? Indeed. But configuration recommendation is not excluded from specification, is it? Can have defaults. In the absence of such configuration, we either need a protocol to signal the type of device connected, or assume the worse case. In that case, the two switches scenario is very broken. > >> >> The scenario where switch_B is not a savi-device does not fit at all >> there though. >>> Creating bindings only with DAD packets, imposes the questions about >>> what can be done when a packets with a source address for which there >>> is no binding. >>> One option would be discard the packet. The problem with this approach >>> is that legitimate packets can be drop. In particular, DAD is not a >>> reliable protocol, so it is possible that DAD packets are lost and >>> do not reach the SAVI device. Similarly, it is also possible that a >>> SAVI device reboots, which would imply that the bindings are lost and >>> since the host may not perform the DAD again, legitimate packets would >>> be lost. >> If the SAVI device is the switch that attaches the end-nodes, the >> interface will go down, and the DAD will happen again. > this is not required by rfc4862 (but i agree that normally happens) Because it would be broken otherwise. > >> >> In addition, I think we should assume that is it the responsability >> of the implementation to preserve its states during a reboot. There >> are countless techniques to do that, and accepting this is an >> implementation problem would greatly simplify the problem. > i don't think it is acceptable to rely on this for not blocking > legitimate users from sending traffic. There are many stateful protocols that just cannot afford to loose their state on box failure. Assuming this is outside the scope of the specification will give us a chance to specify something useful. Note that I don't however suggest to block traffic if we don't have a binding (for instance because the box lost its state). > >>> It is important to quantify this risk. In my personal opinion, the risk >>> is high enough that i am not comfortable designing a SAVI solution >>> that will discard legitimate packets. OTOH, it is likely that in an >>> important number of cases, the DAD messages are actually delivered and >>> the SAVI device creates the binding using them. >>> >>> So, we return to the initial question about what do we do with data >>> packets containing a source address for which there is no binding. >>> As i mentioned, the other option is to create a binding. The >>> drawback of >>> that approach is that we need to distribute the binding information >>> to the other SAVI devices, so that the configure the binding. (I am >>> here assuming that the DAD messages are in general distributed to all >>> the SAVI devices in the link. In order to do so, we need to require >>> that the SAVI devices receive the packets for all solicited nodes >>> multicast groups, but i understand this is feasible). So, it seems >>> than that in order to distribute the bindings created by the corner >>> case >>> that the DAD packet is lost, we need to require the usage of a SAVI >>> protocol to exchange binding data. >>> >>> If we don't think that discarding them is acceptable and we >>> think that creating a SAVI protocol is an overkill for supporting the >>> case where the DAD packets were lost, we may want to consider a middle >>> ground option. >>> >>> An intermediate option would be to simply forward (and eventually log) >>> data packets with source address for which there is no binding. >>> >>> So, let me expand on this. The behaviour of this approach would be: >>> If DAD exchange is detected by the SAVI device, a binding is created. >>> >>> If a data packet containing a source address for which a binding exists >>> and the same lower layer anchor is received, then the packet is >>> forwarded. >>> >>> If a data packet containing a source address for which a binding exists >>> and a different lower layer anchor is received, then the packet is >>> drop. >>> >>> If a data packet containing a source address for which no binding >>> exists >>> the data packet is forwarded and optionally logged. >>> >>> So what are the security properties of such a solution? >>> >>> If a host starts using an address and performs the DAD procedure, then >>> no other host can use its address as a source address in data packets. >>> >>> An attacker can start using an address for which there is no binding. >>> In order for this address to be the address of another host, this >>> can only happen if the DAD packet was lost. I am not sure how concerned >>> should we be about preventing this from attackers that have the >>> capability of disturbing DAD, I mean, if they are able to do that, >>> i guess they can launch worse attacks than spoof a source address. >>> An attacker can use a given address from different lower layer anchors. >>> I am not sure why this would be an attack though. As i said earlier >>> it would be possible for the SAVI device to log the occurrence of these >>> packets and allow to trace back to the lower layer anchor. >>> >>> So, this option seems like a middle ground option with a somehow >>> reduced >>> level of security but with a low level of complexity and without >>> the possibility of disturbing the network behaviour by discarding >>> legitimate packets. >>> >>> Comments? >> Logging is useful, but not practical in case of an attack; Especially >> logging on data-packet events. Switches/routers are usually very >> efficient at droping, and very in-efficient at logging, as the latter >> requires to go very high in the software stack. So you would actually >> help the attacker there. >> > i think logging is an essential part of SAVI actually > I think that the main benefit of SAVI is to know which port was > associated to a given source address at some point in time, so that > attackers can be traced back. > > I mean, SAVI does not define any restriction for getting access to an > unused address. The main point is to prevent the use of somebody elses > address and to use addresses in an anonymous fashion Logging does not prevent the use of somebody else address. In some real life scenarios, we will be logging dozen of thousands messages per second. They won't be human readable in real-time. And logging can be easily attacked, and rendered un-usable. So it's certainly part of the solution, but is not enough in my opinion. > >> I think relying on NDP snooping (DAD+other NDP) is a viable >> short-term solution. And droping traffic when no binding is recorded >> is the core of what we are trying to achieve, isn't it? > i don't think so.... what attack you would be preventing in that case? > Dropping packets coming from a different lower layer anchor is in the > core of savi, but dropping packets with no bindings, it is not obvious > to me what is provided by that... i mean, the attacker only needs to > create a binding and send the packet, so what is the benefit? I meant conflicting bindings.Not no bindings. My mistake > >> On the longer term, a pro-active scheme that would have the hosts >> announcing their binding would be safer. I'd suggest to re-use >> something like draft-thubert-3122bis-01.txt (InverseND+) rather than >> re-inventing something new. >> Another aspect that would be worth discussing the binding table >> replacement algorithm, or which biding should be preferred in case of >> collision. First-come first serve does not work well in a number of >> basic scenarios (movement, multiple switches, etc.). > > how come FCFS doesn't work well in movement? (in multiple switches, > the fcfs behaviour is what we are currently discussing, but it can > work, we just need to agree on the tradeoffs) What tradeoffs? I think tradeoffs means moving away from fcfs. If there are cases where the "second come" should replace the binding, and I think there are many such cases, then it's no longer first-come-first-serve. And we should describe this in various scenarios, because the devil is in the details. Eric > > Regards, marcelo > > >> I proposed a different algorthm >> (draft-levy-abegnoli-savi-plbt-00.txt). Feel free to comment. >> Eric >>> >>> Regards, marcelo >>> >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> >> >> > > From gdaley@netstarnetworks.com Wed Jun 10 17:50:32 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12A1A3A692C for ; Wed, 10 Jun 2009 17:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6r49ZBeNSKXf for ; Wed, 10 Jun 2009 17:50:30 -0700 (PDT) Received: from mail.syd.netstarnetworks.com (mail.syd.netstarnetworks.com [203.8.7.220]) by core3.amsl.com (Postfix) with ESMTP id 95C0C3A68AF for ; Wed, 10 Jun 2009 17:50:29 -0700 (PDT) Received: from sydmail.netstarnetworks.com ([10.18.193.13]) by mail.syd.netstarnetworks.com (8.12.8/8.12.8) with ESMTP id n5B0oGRs028433; Thu, 11 Jun 2009 10:50:17 +1000 Received: from melmail.netstarnetworks.com ([10.20.193.13]) by sydmail.netstarnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Jun 2009 10:50:10 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Jun 2009 10:50:09 +1000 Message-ID: <6983BF97BFC24D4EA551F14071232918010CD796@melmail.netstarnetworks.com> In-Reply-To: <4A2F6F60.1040007@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [savi] On Protecting Unused Addresses in IPv6 Thread-Index: Acnppd+JH6ym5gyFSE61EOSOcajWTQAf80zQ References: <59D15025-814F-4967-84EC-50FCA0225CC1@cisco.com> <6983BF97BFC24D4EA551F14071232918010CD676@melmail.netstarnetworks.com> <4A2F6F60.1040007@it.uc3m.es> From: "Greg Daley" To: "marcelo bagnulo braun" X-OriginalArrivalTime: 11 Jun 2009 00:50:10.0658 (UTC) FILETIME=[92A6F420:01C9EA2E] Cc: SAVI Mailing List , Christian Vogt Subject: Re: [savi] On Protecting Unused Addresses in IPv6 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 00:50:32 -0000 Hi Marcelo, Sorry to misdirect the conversation, the issue is about knowledge of = existing address state, and the inability of most IPv6 protocols to handle this. DHCPv6 is placed here as an example that the protection is available = under some constraints. > Greg Daley escribi=F3: > > Hi Chris, > > > > I think that if a prefix must be statefully configured, it would be=20 > > possible to make use of DHCPv6 to control address allocation for = those=20 > > prefixes. Devices could be configured with such prefixes, or = identify=20 > > them by seeing Router Advertisements. > > =20 > mmm, this would be essentially a subset of what ingress filtering = does, right? > i mean verifying that the prefix comes from the subnet that the prefix = was assigned. The verification is not the important part of the process. The = important part is the certainty that all address allocations (for a non link-local prefix) must come = from a valid DHCP Relay or Server. > The current scope of SAVI assumes that we have ingress filtering and = attempts to > increase the security i.e. we are assuming that the prefix cannot be = spoofed, and we try to say something about the address. This has nothing to do with ingress filtering, as all communications for = address configuration are link-local. The inference that addresses must use DHCP to bind addresses in a = particular prefix is made either: a) via manual DHCPv6 snooping switch configuration (for one or all = on-link global prefixes) or b) by monitoring the Router Advertisements' own Prefix Information = Options (which may also have SEND authorization). Once the inference is made (about a global prefix), only DHCP link-local = messages (and the mechanisms to bootstrap link-local addresses) would be allowed by LAN switch ports. Reception of a DHCPv6 = REPLY messages with an address binding would create state. Some exceptions for DAD defence may be allowed for responses to = Neighbour Solicitation from unknown ports (not yet explored). =20 All other source address presentations from unknown ports would be = dropped. DHCPv6 message monitoring mechanisms could also be used to create = ingress filtering in adjacent LAN switches when DHCPv6-PD is in use. In terms of motivation, this is not intended to resolve the entire = situation for IPv6 access networks, but should provide access network Global Address to switch port mappings in = controlled addressing domains. The mechanism described is reliable in that it makes use of DHCPv6's = retransmission timers, and the state created by the allocation of addresses by using the (Request, Renew, Rebind, = Release)/Reply exchange. Greg From marcelo@it.uc3m.es Thu Jun 11 08:40:26 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD04428C136 for ; Thu, 11 Jun 2009 08:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.297 X-Spam-Level: X-Spam-Status: No, score=-6.297 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2w9kqqxtYKbb for ; Thu, 11 Jun 2009 08:40:25 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id A38B028C13C for ; Thu, 11 Jun 2009 08:40:24 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [163.117.203.209]) by smtp03.uc3m.es (Postfix) with ESMTP id 5E5A17EEFEE; Thu, 11 Jun 2009 17:40:30 +0200 (CEST) Message-ID: <4A30D6CD.8060209@it.uc3m.es> Date: Thu, 11 Jun 2009 06:05:01 -0400 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Eric Levy-Abegnoli References: <4A2C0DFB.3040803@it.uc3m.es> <4A2D2221.4030503@cisco.com> <4A2D2739.1000206@it.uc3m.es> <4A2F9E29.5070704@cisco.com> In-Reply-To: <4A2F9E29.5070704@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16696.004 Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 15:40:26 -0000 Eric Levy-Abegnoli escribió: > marcelo bagnulo braun a écrit : >> Eric Levy-Abegnoli escribió: >>> marcelo bagnulo braun a écrit : >>>> Over the last few weeks, we have been discussing different approaches >>>> for SAVI to be used in conjunction IPv6 stateless address >>>> autconfiguration. >>>> the different proposed approaches have different pros and cons, due to >>>> different tradeoffs being made. >>>> In this email, i describe an intermediate approach that may be worth >>>> to be considered. >>>> >>>> So, i will first try to summarize the design questions that we have >>>> been considering. >>>> The first question is whether we create bindings using only DAD >>>> packets >>>> or we also create bindings using data packet. >>> There is something "in-between" DAD and data: other NDP messages. If >>> the savi device misses the DAD packet, chances are that the binding >>> owner will soon send another NDP message. >> you could go down the paht the SAVI device looks into every ND packet >> and interprets them and based on that it infers who is the owner of >> each address. The problem here is that we will need to make >> inferences from different ND packets, depending on how they are >> dsitributed (i.e. depending if they are send to all nodes, to a >> multicast group or to a node). That would essentially imply that any >> change in the ND spec would potentially have an impact on the SAVI >> spec and it would result in hardcoding the current ND behaviour. >> BEsides, the complexity increases since each ND exchange need to be >> tracked uan understood by the SAVI device to properly infer the >> resulting binding. > Not every packets. packets carrying binding information. And > credentials (CGA, ...). Relying on the sole L2 information of DAD > packets is going to lead to approximations that will then lead to > loose decisions. mmm, i think we will always end up in somehow loose decisions... I mean, SAVI is guessing and infering from the traffic it sees, It is likely that it will guess wrong sometimes. So, for me the question is not whether we will have loose decision, but: - What is the tradeoff between complexity of tracking the different packets for infer bindings and how accurate the guess will be - towards which side do we err i.e. we discard too much or we let too many packets pass >>> Typically, it will send an NA to all-nodes. >> what NA would that be? > 7.2.6. Sending Unsolicited Neighbor Advertisements > > It's not "required". However, pretty much all IPv6 implementations are > sending NA to "all nodes" with override nit on, when the interface > goes up. > mmm, what would happen if an attacker sends one of these packets for a target address that it is not his own? > >>> It will also at some point have to resolve its neighbors addresses. >>> Those messages are not "required" by the protocol, or they could >>> happen prior to DAD for a given address. However, snooping them (and >>> using them for build the binding table) will greatly lower the >>> chances that the binding was missed.. >>> >>> For end-nodes attached to the savi switch via an access port, it is >>> not un-reasonnable to assume that the switch should have learn a >>> binding prior to see a data packet carrying it. >>> However, when the end-node is attached to the savi switch_A via >>> another switch_B (trunk port), this maybe problematic. Because the >>> savi switch_A could typically come up long after switch_B and all >>> nodes attached to switch_B have already done DAD etc. Chances that >>> switch_A missed the bindings are much higher than the one of a DAD >>> packet getting lost. >> right, so are you arguing that a solution that solely relies on DAD >> is not enough in your opinion? > I am arguing that if we look at more than DAD packets, we decrease the > already low chances that the information is missed. Making sure the > L2 and L3/LLA are consistent has also some value. right, that is certianly true. My question is how much complexity are we willing to accept and how much gain do we get from this >> >>> One policy for switch_A could be to not_drop anything coming over a >>> "savi-trunk", a trunk connected to a savi-device, relying on >>> switch_B to drop traffic from the node "directly-attached" to it (if >>> no binding is available). That way you don't really need to have the >>> switches synchronysing their binding table. >> but it would imply that you need to configure which ports are >> connected to hosts and which ones are connected to other savi >> devices, right? >> and that is likely to be a manual configuration, right? >> and if the topology changes you would need to update that, correct? > Indeed. But configuration recommendation is not excluded from > specification, is it? no, it is not excluded. I personally think it is important to keep it to a maximum if we want to see this deployed, but it is certainly up for discussion > Can have defaults. In the absence of such configuration, we either > need a protocol to signal the type of device connected, how do you secure such a protocol? Probably any acceptable security will require some confuguration afaics > or assume the worse case. In that case, the two switches scenario is > very broken. >> >>> >>> The scenario where switch_B is not a savi-device does not fit at all >>> there though. >>>> Creating bindings only with DAD packets, imposes the questions about >>>> what can be done when a packets with a source address for which there >>>> is no binding. >>>> One option would be discard the packet. The problem with this approach >>>> is that legitimate packets can be drop. In particular, DAD is not a >>>> reliable protocol, so it is possible that DAD packets are lost and >>>> do not reach the SAVI device. Similarly, it is also possible that a >>>> SAVI device reboots, which would imply that the bindings are lost and >>>> since the host may not perform the DAD again, legitimate packets would >>>> be lost. >>> If the SAVI device is the switch that attaches the end-nodes, the >>> interface will go down, and the DAD will happen again. >> this is not required by rfc4862 (but i agree that normally happens) > Because it would be broken otherwise. why do you say so? AFAIK, rfc4862 is on purpose vague on this case, in order to allow not doing DAD in this case >> >>> >>> In addition, I think we should assume that is it the responsability >>> of the implementation to preserve its states during a reboot. There >>> are countless techniques to do that, and accepting this is an >>> implementation problem would greatly simplify the problem. >> i don't think it is acceptable to rely on this for not blocking >> legitimate users from sending traffic. > There are many stateful protocols that just cannot afford to loose > their state on box failure. Assuming this is outside the scope of the > specification will give us a chance to specify something useful. > Note that I don't however suggest to block traffic if we don't have a > binding (for instance because the box lost its state). So this basically imply that if we receive a data packet for which we don't have a binding for, then we cannot discard it, right? So what do we do with this data packet? >> >>>> It is important to quantify this risk. In my personal opinion, the >>>> risk >>>> is high enough that i am not comfortable designing a SAVI solution >>>> that will discard legitimate packets. OTOH, it is likely that in an >>>> important number of cases, the DAD messages are actually delivered and >>>> the SAVI device creates the binding using them. >>>> >>>> So, we return to the initial question about what do we do with data >>>> packets containing a source address for which there is no binding. >>>> As i mentioned, the other option is to create a binding. The >>>> drawback of >>>> that approach is that we need to distribute the binding information >>>> to the other SAVI devices, so that the configure the binding. (I am >>>> here assuming that the DAD messages are in general distributed to all >>>> the SAVI devices in the link. In order to do so, we need to require >>>> that the SAVI devices receive the packets for all solicited nodes >>>> multicast groups, but i understand this is feasible). So, it seems >>>> than that in order to distribute the bindings created by the corner >>>> case >>>> that the DAD packet is lost, we need to require the usage of a SAVI >>>> protocol to exchange binding data. >>>> >>>> If we don't think that discarding them is acceptable and we >>>> think that creating a SAVI protocol is an overkill for supporting the >>>> case where the DAD packets were lost, we may want to consider a middle >>>> ground option. >>>> >>>> An intermediate option would be to simply forward (and eventually log) >>>> data packets with source address for which there is no binding. >>>> >>>> So, let me expand on this. The behaviour of this approach would be: >>>> If DAD exchange is detected by the SAVI device, a binding is created. >>>> >>>> If a data packet containing a source address for which a binding >>>> exists >>>> and the same lower layer anchor is received, then the packet is >>>> forwarded. >>>> >>>> If a data packet containing a source address for which a binding >>>> exists >>>> and a different lower layer anchor is received, then the packet is >>>> drop. >>>> >>>> If a data packet containing a source address for which no binding >>>> exists >>>> the data packet is forwarded and optionally logged. >>>> >>>> So what are the security properties of such a solution? >>>> >>>> If a host starts using an address and performs the DAD procedure, then >>>> no other host can use its address as a source address in data packets. >>>> >>>> An attacker can start using an address for which there is no binding. >>>> In order for this address to be the address of another host, this >>>> can only happen if the DAD packet was lost. I am not sure how >>>> concerned >>>> should we be about preventing this from attackers that have the >>>> capability of disturbing DAD, I mean, if they are able to do that, >>>> i guess they can launch worse attacks than spoof a source address. >>>> An attacker can use a given address from different lower layer >>>> anchors. >>>> I am not sure why this would be an attack though. As i said earlier >>>> it would be possible for the SAVI device to log the occurrence of >>>> these >>>> packets and allow to trace back to the lower layer anchor. >>>> >>>> So, this option seems like a middle ground option with a somehow >>>> reduced >>>> level of security but with a low level of complexity and without >>>> the possibility of disturbing the network behaviour by discarding >>>> legitimate packets. >>>> >>>> Comments? >>> Logging is useful, but not practical in case of an attack; >>> Especially logging on data-packet events. Switches/routers are >>> usually very efficient at droping, and very in-efficient at logging, >>> as the latter requires to go very high in the software stack. So you >>> would actually help the attacker there. >>> >> i think logging is an essential part of SAVI actually >> I think that the main benefit of SAVI is to know which port was >> associated to a given source address at some point in time, so that >> attackers can be traced back. >> >> I mean, SAVI does not define any restriction for getting access to an >> unused address. The main point is to prevent the use of somebody >> elses address and to use addresses in an anonymous fashion > Logging does not prevent the use of somebody else address. right, logging helps with the second part, using an address in an anonymous fashion > In some real life scenarios, we will be logging dozen of thousands > messages per second. They won't be human readable in real-time. that is true if you don't know what you are looking for. In this case, if an attack has occur using a given address, you would be looking the L2 anchor bound to the source address used in the attack at a given moment. That information should be easy to get from a log, even a very large one > And logging can be easily attacked, and rendered un-usable. So it's > certainly part of the solution, but is not enough in my opinion. enough for what? I think this is probably the best we can do for preventing anonymous use of an address... what else can we do? >> >>> I think relying on NDP snooping (DAD+other NDP) is a viable >>> short-term solution. And droping traffic when no binding is recorded >>> is the core of what we are trying to achieve, isn't it? >> i don't think so.... what attack you would be preventing in that case? >> Dropping packets coming from a different lower layer anchor is in the >> core of savi, but dropping packets with no bindings, it is not >> obvious to me what is provided by that... i mean, the attacker only >> needs to create a binding and send the packet, so what is the benefit? > I meant conflicting bindings.Not no bindings. My mistake ok >> >>> On the longer term, a pro-active scheme that would have the hosts >>> announcing their binding would be safer. I'd suggest to re-use >>> something like draft-thubert-3122bis-01.txt (InverseND+) rather than >>> re-inventing something new. >>> Another aspect that would be worth discussing the binding table >>> replacement algorithm, or which biding should be preferred in case >>> of collision. First-come first serve does not work well in a number >>> of basic scenarios (movement, multiple switches, etc.). >> >> how come FCFS doesn't work well in movement? (in multiple switches, >> the fcfs behaviour is what we are currently discussing, but it can >> work, we just need to agree on the tradeoffs) > What tradeoffs? I think tradeoffs means moving away from fcfs. If > there are cases where the "second come" should replace the binding, mmm, in the case of movement, this is only true when there is nobody replying in the first binding, right? or, do you have other cases in mind? > and I think there are many such cases, then it's no longer > first-come-first-serve. And we should describe this in various > scenarios, because the devil is in the details. right, could you describe the scenarios you have in mind? Regards, marcelo > Eric >> >> Regards, marcelo >> >> >>> I proposed a different algorthm >>> (draft-levy-abegnoli-savi-plbt-00.txt). Feel free to comment. >>> Eric >>>> >>>> Regards, marcelo >>>> >>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>>> >>> >>> >> >> > > From christian.vogt@ericsson.com Thu Jun 11 13:15:20 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C4A13A68B8 for ; Thu, 11 Jun 2009 13:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.279 X-Spam-Level: X-Spam-Status: No, score=-6.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfIZyC+EGVKS for ; Thu, 11 Jun 2009 13:15:18 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id ABE803A682A for ; Thu, 11 Jun 2009 13:15:18 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n5BKEwkV027802; Thu, 11 Jun 2009 15:15:03 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jun 2009 15:15:02 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jun 2009 15:15:01 -0500 Message-Id: <15A410E1-2A4C-4861-BF07-CFD5EBFA8F8C@ericsson.com> From: Christian Vogt To: Greg Daley In-Reply-To: <6983BF97BFC24D4EA551F14071232918010CD676@melmail.netstarnetworks.com> Content-Type: multipart/signed; boundary=Apple-Mail-6-156129408; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 11 Jun 2009 13:14:59 -0700 References: <59D15025-814F-4967-84EC-50FCA0225CC1@cisco.com> <6983BF97BFC24D4EA551F14071232918010CD676@melmail.netstarnetworks.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 11 Jun 2009 20:15:01.0804 (UTC) FILETIME=[4D057EC0:01C9EAD1] Cc: SAVI Mailing List Subject: Re: [savi] On Protecting Unused Addresses in IPv6 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 20:15:21 -0000 --Apple-Mail-6-156129408 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Greg - If I understand you correctly, you are proposing a "DHCP-only mode" for SAVI, for use in networks where Stateless Address Autoconfiguration is disabled. In DHCP-only mode, due to DHCP exchanges being reliable, SAVI devices could drop packets without corresponding binding without risking false packet drops. Please correct me if I misinterpreted your email. I think your observations are correct. Yet we have to analyze what the implications of a DHCP-only mode would be. The proposed DHCP-only option was discussed before in the working group, although this discussion hasn't gotten far yet. One of the difficulties is to prevent spoofing of DHCP messages. Another is to prevent SAVI devices from getting tricked into DHCP-only mode. Especially the latter would be a disaster in networks where no DHCP is used. - Christian On Jun 9, 2009, Greg Daley wrote: > Hi Chris, > > I think that if a prefix must be statefully configured, it would be > possible to make use of DHCPv6 to control address allocation for those > prefixes. Devices could be configured with such prefixes, or identify > them by seeing Router Advertisements. > > Devices which do not get addresses allocated via DHCP then do not get > transmission rights. > > This is essentially what some deployed products do today with IPv4. > It > is fairly reliable, although I personally have reservations about what > should be done in the case of state loss on the snooping device (for > IPv4). > > This may actually be an important use case: Spoofing on address > managed > networks. > > Greg Daley --Apple-Mail-6-156129408 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8DCCBDIw ggMaoAMCAQICEAfnb+QKJYbrlz+OaXsA6lEwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0wNzA5MTMxMTI5 MTRaFw0xMDA5MTMxMTI5MTBaMGoxETAPBgNVBAoMCEVyaWNzc29uMRcwFQYDVQQDDA5DaHJpc3Rp YW4gVm9ndDEQMA4GA1UEBRMHZWNocnZvZzEqMCgGCSqGSIb3DQEJARYbY2hyaXN0aWFuLnZvZ3RA ZXJpY3Nzb24uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCVGNN5yyhnvz5VWwGDcmey bI9H/DGF0LQmxS+L3gJ9gJIAQ2NPhF16dsWnlpCwS+VsKwMRfh3BsYGY88Hlx/Yvo6NfqE6evobv prxbgKiFP7j1c7Ntke/6SRamUVPFnWrFuaOuXTwU7GUAd/uOoCRNs/nq1hdQRC684gX/kAfBYwID AQABo4IBhzCCAYMwgcAGA1UdHwSBuDCBtTCBsqCBr6CBrIY3aHR0cDovL2NybC50cnVzdC50ZWxp YS5jb20vRXJpY3Nzb25OTEluZGl2aWR1YWxDQTAxLmNybIZxbGRhcDovL2xkYXAudHJ1c3QudGVs aWEuY29tL2NuPUVyaWNzc29uJTIwTkwlMjBJbmRpdmlkdWFsJTIwQ0EwMSxvPUVyaWNzc29uP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2UwJgYDVR0RBB8wHYEbY2hyaXN0aWFu LnZvZ3RAZXJpY3Nzb24uY29tMEYGA1UdIAQ/MD0wOwYGKoVwawEBMDEwLwYIKwYBBQUHAgEWI2h0 dHA6Ly93d3cuZXJpY3Nzb24uY29tL2xlZ2FsLnNodG1sMB0GA1UdDgQWBBQ2hgtYCoOVEiitjMNu mLE8wGuILzAfBgNVHSMEGDAWgBSWJ8O43qVfXUQ+OVLlRbF2X2MwmzAOBgNVHQ8BAf8EBAMCBaAw DQYJKoZIhvcNAQEFBQADggEBAKYJznyxAs6fzHgXDHa00mqyU/+ykFi9HvBv9MSmD2M1X+bifCd6 /jVVrGZWfMfPSV/AbqQjXVQfyHU1R0EqtgEFLyfNVmEGI9lXkkQb5cXNwaJYVj/+ozy+oSu1ZzZA j0GM6NVvhCwGapHoNDPDWe25UdvmOFxxVo6UMq3TWPcSUMq4s3vHLe5n7tgNCdcVUMeqTrAe9cKw TGy7+eJK48rbBcBtKxq2sTY/4H5H6prEKaVlwGW96PydY0IVu4QGVhUT/ONCVByl5xLImDa0tEaX npUj0Y0ys4DneQ3Bxf6DEMuB5+BiSkBk8FmEaSaj2xA/ShtYuaKIO6e9JjpvGb0wggRFMIIDLaAD AgECAhATyer/3iatqdykyiOBg0fjMA0GCSqGSIb3DQEBBQUAMEQxGjAYBgNVBAoMEVRlbGlhU29u ZXJhIEdyb3VwMSYwJAYDVQQDDB1UZWxpYVNvbmVyYSBQdWJsaWMgUm9vdCBDQSB2MTAeFw0wNjEw MDYxMDAwNTNaFw0xNjEwMDIwNTA0MTdaMDkxETAPBgNVBAoMCEVyaWNzc29uMSQwIgYDVQQDDBtF cmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC2EHfkNR7rh8Q8jRhZRD8wsbjzxTuVtscq/p6glZzSeEGBXtRwAqmr6jS8FBiKiBMh79ay537m /SwXO3UKUR45f3YIIp9DjThSd+p2xhG3x4yyc9gczlr8JfOEnPhcdPSKw1P0mUlhUn4ak7t009/Y e/W6x3UZHTwVIAWILIhSq4hyNE4z+RvOtvB9uwQ86lKcxi0mFoLev7acLjh+ZXHzXx1jHAmF0ZaG 79CpbvJcRuWplqgJ6qx+hAjsmCU0Wx07GkyGTh8vUMP9Hlz7oyk+7VOccUiNknXHias1GwM9qBUU Oj8e/xsnaTP0ZfqmKBj3Grh1C9WknlSWagxanCBdAgMBAAGjggE8MIIBODASBgNVHRMBAf8ECDAG AQH/AgEAMEYGA1UdIAQ/MD0wOwYHKoVwIwIBATAwMC4GCCsGAQUFBwIBFiJodHRwczovL3JlcG9z aXRvcnkudHJ1c3QudGVsaWEuY29tMIGJBgNVHR8EgYEwfzB9oHugeYZ3bGRhcDovL2xkYXAudHJ1 c3QudGVsaWEuY29tL2NuPVRlbGlhU29uZXJhJTIwUHVibGljJTIwUm9vdCUyMENBJTIwdjEsbz1U ZWxpYVNvbmVyYSUyMEdyb3VwP2F1dGhvcml0eXJldm9jYXRpb25saXN0P2Jhc2UwDgYDVR0PAQH/ BAQDAgEGMB0GA1UdDgQWBBSWJ8O43qVfXUQ+OVLlRbF2X2MwmzAfBgNVHSMEGDAWgBRF2/CPuBpi oagjG2OIOKPb4Bpi8TANBgkqhkiG9w0BAQUFAAOCAQEAdgBKKkM/jN0WvWpZKZ/2J8IVyL+rT44V L0rjbNNDYXdE/V4ZSFN2uuQmgf1Ckqp2shNLe0NEKt6/sfxit4p/5opPIvzytv6vB7rc2BUs8+ja c7aaNiRuwBCjiT1Wnnm454OOZurzQu0SH81PbBtiwUf4XsEvLOnRRZ+9MO/ecVMCQVmeuzsyCl6y FVbx0zmKW1gPjBEigF8BYZ1Tjazk1pVcKzFIuB24j1qTpPsUG4HoQhIu5rt3F7GlNV6t5DF7ojbg u1SqKG/JhTvaPUU/nZYqw9rkV8Dabwrt27reisobtPp78tolxio3ZcZVk7HQ8rpV2M/jmAjGfZRV kczCDzCCBG0wggNVoAMCAQICEQCcsIwEmsuXInhjYrYbhlo9MA0GCSqGSIb3DQEBBQUAMDoxGTAX BgNVBAoTEFJTQSBTZWN1cml0eSBJbmMxHTAbBgNVBAsTFFJTQSBTZWN1cml0eSAyMDQ4IFYzMB4X DTA2MTAzMTIwNDIyN1oXDTE2MTEwMTE1NDIyNVowRDEaMBgGA1UECgwRVGVsaWFTb25lcmEgR3Jv dXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyk8QA2qQgKt5qZV+EeIDbflmXuUChp2lREEsmO5SAiheQ7lXVjzC xw484cOSMw3fOtGWcf9Fa4Rgdw5j+EgyFgiqNj8b2OTXJHQVj1qf09rmkHTgMIKh6TdKXtV+/43p efVrFmFyhoP/NVrYe92Sv4HhOxs/T749S1OjeGISzIKKMSpwkvmYweYnFgIPkHdUKUIReOh9Ym6e i7AVg6eejD6YPBeV+suzBlXCmC3Zyzj7POLsUVvarNZAaKc0AY+rOUslYfAPo+ZYgwY4IV2KcP/q WhhHahz3khWMWSniWrZoxCi2JcXGVkSn+N+ir0APYwYTBJsrTDWxonEdZkR+rQIDAQABo4IBYjCC AV4wHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFEXb8I+4GmKhqCMb Y4g4o9vgGmLxMBIGA1UdEwEB/wQIMAYBAf8CAQQwgYUGA1UdIAR+MHwwPQYJKoZIhvcNBQYBMDAw LgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wOwYHKoVwIwIB ATAwMC4GCCsGAQUFBwIBFiJodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWEuY29tMHAGA1Ud HwRpMGcwZaBjoGGGX2h0dHA6Ly93d3cucnNhc2VjdXJpdHkuY29tL3Byb2R1Y3RzL2tlb24vcmVw b3NpdG9yeS9jZXJ0aWZpY2F0ZV9zdGF0dXMvUlNBX1NlY3VyaXR5XzIwNDhfdjMuQ1JMMA4GA1Ud DwEB/wQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEABF6aLNgpyJu//O9srUqxB1mYL4TlBJFJtuT1 n/15FpKONU2i/byEtUugHVgoTalpp2Ikuxn2iIgzPbNQ+iu4YnVgQzpuOmzXTN2cITMgwn5AyUoH idMPu2Jo7wobu4Fqg2QrG7WeYANYsQk3Q57mQeuyRkjxluq+93KK2gz/HYjqYkKLjLzOmyrkzwR/ 9aaC3HLFMbCoK0NtyQvS1gkW/HGB5GY1xR9SuOE7CJeS53tqE9CSN6cHQNr+ozuKfzix57T/p6Y8 D23nTD1GZA2ApHdy0sY/HNyU8bQPEpTwrSBxNYYeucYoYNSUSJYkqYa6q/ZG38B3XlcT3TiORrQ2 DzGCAhIwggIOAgEBME0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EwMQIQB+dv5AolhuuXP45pewDqUTAJBgUrDgMCGgUAoIIBGzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2MTEyMDE1MDJaMCMGCSqGSIb3 DQEJBDEWBBQjBOf96lLmDiE5zr4PH67Xcm5eCjBcBgkrBgEEAYI3EAQxTzBNMDkxETAPBgNVBAoM CEVyaWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEAfnb+QKJYbr lz+OaXsA6lEwXgYLKoZIhvcNAQkQAgsxT6BNMDkxETAPBgNVBAoMCEVyaWNzc29uMSQwIgYDVQQD DBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEAfnb+QKJYbrlz+OaXsA6lEwDQYJKoZIhvcN AQEBBQAEgYAGbi1PCzio9Xow/znB2RnV2TriTqoQxzuubUkYoA1+9wC8mdeFHb7ATkSnckyHXaSg k0pm1+HhxPn37jaPHerJEE1ClqQ254+zpK+ZJBKgjTibyge7JL6zq5LXm7fe8oerhZ1LcJIioqiD k4xzfQ6KyjdBQq9ggxp/qFefMdNW4QAAAAAAAA== --Apple-Mail-6-156129408-- From christian.vogt@ericsson.com Thu Jun 11 13:34:22 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C12303A67CC for ; Thu, 11 Jun 2009 13:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.332 X-Spam-Level: X-Spam-Status: No, score=-6.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBI9bhNYMn99 for ; Thu, 11 Jun 2009 13:34:21 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 111CD3A69EF for ; Thu, 11 Jun 2009 13:34:20 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n5BKYQ4q001116; Thu, 11 Jun 2009 15:34:27 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jun 2009 15:34:26 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jun 2009 15:34:26 -0500 Message-Id: <72862102-55BF-4196-8DEA-D4B366497F0C@ericsson.com> From: Christian Vogt To: marcelo bagnulo braun In-Reply-To: <4A2F6ECB.2010400@it.uc3m.es> Content-Type: multipart/signed; boundary=Apple-Mail-7-157293723; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 11 Jun 2009 13:34:23 -0700 References: <59D15025-814F-4967-84EC-50FCA0225CC1@cisco.com> <4A2F6ECB.2010400@it.uc3m.es> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 11 Jun 2009 20:34:26.0070 (UTC) FILETIME=[02FA6360:01C9EAD4] Cc: SAVI Mailing List Subject: Re: [savi] On Protecting Unused Addresses in IPv6 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 20:34:22 -0000 --Apple-Mail-7-157293723 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jun 10, 2009, marcelo bagnulo braun wrote: >> A few personal comments, which I would like to state outside of my >> role >> as a working group chair: Fred, you are calling for a SAVI solution >> that prevents attackers from hijacking unused addresses. > > I fail to see what this means. Marcelo - The discussion Fred initiated was about whether or not to protect addresses without a corresponding binding. These addresses are what I called "unused" in my previous email. After all, for addresses that are used legitimately, the modified FCFS approach that you had been describing would normally have a binding -- barring premature binding expiration or loss of DAD packets. The conclusion is hence that the modified FCFS approach may actually be good enough. After all, its only disadvantage is that packets from unused addresses are not discarded. But since all that is needed to turn an unused address into a used address is DAD, there is not much value in discarding packets from unused addresses anyway. - Christian --Apple-Mail-7-157293723 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8DCCBDIw ggMaoAMCAQICEAfnb+QKJYbrlz+OaXsA6lEwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0wNzA5MTMxMTI5 MTRaFw0xMDA5MTMxMTI5MTBaMGoxETAPBgNVBAoMCEVyaWNzc29uMRcwFQYDVQQDDA5DaHJpc3Rp YW4gVm9ndDEQMA4GA1UEBRMHZWNocnZvZzEqMCgGCSqGSIb3DQEJARYbY2hyaXN0aWFuLnZvZ3RA ZXJpY3Nzb24uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCVGNN5yyhnvz5VWwGDcmey bI9H/DGF0LQmxS+L3gJ9gJIAQ2NPhF16dsWnlpCwS+VsKwMRfh3BsYGY88Hlx/Yvo6NfqE6evobv prxbgKiFP7j1c7Ntke/6SRamUVPFnWrFuaOuXTwU7GUAd/uOoCRNs/nq1hdQRC684gX/kAfBYwID AQABo4IBhzCCAYMwgcAGA1UdHwSBuDCBtTCBsqCBr6CBrIY3aHR0cDovL2NybC50cnVzdC50ZWxp YS5jb20vRXJpY3Nzb25OTEluZGl2aWR1YWxDQTAxLmNybIZxbGRhcDovL2xkYXAudHJ1c3QudGVs aWEuY29tL2NuPUVyaWNzc29uJTIwTkwlMjBJbmRpdmlkdWFsJTIwQ0EwMSxvPUVyaWNzc29uP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2UwJgYDVR0RBB8wHYEbY2hyaXN0aWFu LnZvZ3RAZXJpY3Nzb24uY29tMEYGA1UdIAQ/MD0wOwYGKoVwawEBMDEwLwYIKwYBBQUHAgEWI2h0 dHA6Ly93d3cuZXJpY3Nzb24uY29tL2xlZ2FsLnNodG1sMB0GA1UdDgQWBBQ2hgtYCoOVEiitjMNu mLE8wGuILzAfBgNVHSMEGDAWgBSWJ8O43qVfXUQ+OVLlRbF2X2MwmzAOBgNVHQ8BAf8EBAMCBaAw DQYJKoZIhvcNAQEFBQADggEBAKYJznyxAs6fzHgXDHa00mqyU/+ykFi9HvBv9MSmD2M1X+bifCd6 /jVVrGZWfMfPSV/AbqQjXVQfyHU1R0EqtgEFLyfNVmEGI9lXkkQb5cXNwaJYVj/+ozy+oSu1ZzZA j0GM6NVvhCwGapHoNDPDWe25UdvmOFxxVo6UMq3TWPcSUMq4s3vHLe5n7tgNCdcVUMeqTrAe9cKw TGy7+eJK48rbBcBtKxq2sTY/4H5H6prEKaVlwGW96PydY0IVu4QGVhUT/ONCVByl5xLImDa0tEaX npUj0Y0ys4DneQ3Bxf6DEMuB5+BiSkBk8FmEaSaj2xA/ShtYuaKIO6e9JjpvGb0wggRFMIIDLaAD AgECAhATyer/3iatqdykyiOBg0fjMA0GCSqGSIb3DQEBBQUAMEQxGjAYBgNVBAoMEVRlbGlhU29u ZXJhIEdyb3VwMSYwJAYDVQQDDB1UZWxpYVNvbmVyYSBQdWJsaWMgUm9vdCBDQSB2MTAeFw0wNjEw MDYxMDAwNTNaFw0xNjEwMDIwNTA0MTdaMDkxETAPBgNVBAoMCEVyaWNzc29uMSQwIgYDVQQDDBtF cmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC2EHfkNR7rh8Q8jRhZRD8wsbjzxTuVtscq/p6glZzSeEGBXtRwAqmr6jS8FBiKiBMh79ay537m /SwXO3UKUR45f3YIIp9DjThSd+p2xhG3x4yyc9gczlr8JfOEnPhcdPSKw1P0mUlhUn4ak7t009/Y e/W6x3UZHTwVIAWILIhSq4hyNE4z+RvOtvB9uwQ86lKcxi0mFoLev7acLjh+ZXHzXx1jHAmF0ZaG 79CpbvJcRuWplqgJ6qx+hAjsmCU0Wx07GkyGTh8vUMP9Hlz7oyk+7VOccUiNknXHias1GwM9qBUU Oj8e/xsnaTP0ZfqmKBj3Grh1C9WknlSWagxanCBdAgMBAAGjggE8MIIBODASBgNVHRMBAf8ECDAG AQH/AgEAMEYGA1UdIAQ/MD0wOwYHKoVwIwIBATAwMC4GCCsGAQUFBwIBFiJodHRwczovL3JlcG9z aXRvcnkudHJ1c3QudGVsaWEuY29tMIGJBgNVHR8EgYEwfzB9oHugeYZ3bGRhcDovL2xkYXAudHJ1 c3QudGVsaWEuY29tL2NuPVRlbGlhU29uZXJhJTIwUHVibGljJTIwUm9vdCUyMENBJTIwdjEsbz1U ZWxpYVNvbmVyYSUyMEdyb3VwP2F1dGhvcml0eXJldm9jYXRpb25saXN0P2Jhc2UwDgYDVR0PAQH/ BAQDAgEGMB0GA1UdDgQWBBSWJ8O43qVfXUQ+OVLlRbF2X2MwmzAfBgNVHSMEGDAWgBRF2/CPuBpi oagjG2OIOKPb4Bpi8TANBgkqhkiG9w0BAQUFAAOCAQEAdgBKKkM/jN0WvWpZKZ/2J8IVyL+rT44V L0rjbNNDYXdE/V4ZSFN2uuQmgf1Ckqp2shNLe0NEKt6/sfxit4p/5opPIvzytv6vB7rc2BUs8+ja c7aaNiRuwBCjiT1Wnnm454OOZurzQu0SH81PbBtiwUf4XsEvLOnRRZ+9MO/ecVMCQVmeuzsyCl6y FVbx0zmKW1gPjBEigF8BYZ1Tjazk1pVcKzFIuB24j1qTpPsUG4HoQhIu5rt3F7GlNV6t5DF7ojbg u1SqKG/JhTvaPUU/nZYqw9rkV8Dabwrt27reisobtPp78tolxio3ZcZVk7HQ8rpV2M/jmAjGfZRV kczCDzCCBG0wggNVoAMCAQICEQCcsIwEmsuXInhjYrYbhlo9MA0GCSqGSIb3DQEBBQUAMDoxGTAX BgNVBAoTEFJTQSBTZWN1cml0eSBJbmMxHTAbBgNVBAsTFFJTQSBTZWN1cml0eSAyMDQ4IFYzMB4X DTA2MTAzMTIwNDIyN1oXDTE2MTEwMTE1NDIyNVowRDEaMBgGA1UECgwRVGVsaWFTb25lcmEgR3Jv dXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyk8QA2qQgKt5qZV+EeIDbflmXuUChp2lREEsmO5SAiheQ7lXVjzC xw484cOSMw3fOtGWcf9Fa4Rgdw5j+EgyFgiqNj8b2OTXJHQVj1qf09rmkHTgMIKh6TdKXtV+/43p efVrFmFyhoP/NVrYe92Sv4HhOxs/T749S1OjeGISzIKKMSpwkvmYweYnFgIPkHdUKUIReOh9Ym6e i7AVg6eejD6YPBeV+suzBlXCmC3Zyzj7POLsUVvarNZAaKc0AY+rOUslYfAPo+ZYgwY4IV2KcP/q WhhHahz3khWMWSniWrZoxCi2JcXGVkSn+N+ir0APYwYTBJsrTDWxonEdZkR+rQIDAQABo4IBYjCC AV4wHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFEXb8I+4GmKhqCMb Y4g4o9vgGmLxMBIGA1UdEwEB/wQIMAYBAf8CAQQwgYUGA1UdIAR+MHwwPQYJKoZIhvcNBQYBMDAw LgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wOwYHKoVwIwIB ATAwMC4GCCsGAQUFBwIBFiJodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWEuY29tMHAGA1Ud HwRpMGcwZaBjoGGGX2h0dHA6Ly93d3cucnNhc2VjdXJpdHkuY29tL3Byb2R1Y3RzL2tlb24vcmVw b3NpdG9yeS9jZXJ0aWZpY2F0ZV9zdGF0dXMvUlNBX1NlY3VyaXR5XzIwNDhfdjMuQ1JMMA4GA1Ud DwEB/wQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEABF6aLNgpyJu//O9srUqxB1mYL4TlBJFJtuT1 n/15FpKONU2i/byEtUugHVgoTalpp2Ikuxn2iIgzPbNQ+iu4YnVgQzpuOmzXTN2cITMgwn5AyUoH idMPu2Jo7wobu4Fqg2QrG7WeYANYsQk3Q57mQeuyRkjxluq+93KK2gz/HYjqYkKLjLzOmyrkzwR/ 9aaC3HLFMbCoK0NtyQvS1gkW/HGB5GY1xR9SuOE7CJeS53tqE9CSN6cHQNr+ozuKfzix57T/p6Y8 D23nTD1GZA2ApHdy0sY/HNyU8bQPEpTwrSBxNYYeucYoYNSUSJYkqYa6q/ZG38B3XlcT3TiORrQ2 DzGCAhIwggIOAgEBME0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EwMQIQB+dv5AolhuuXP45pewDqUTAJBgUrDgMCGgUAoIIBGzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2MTEyMDM0MjZaMCMGCSqGSIb3 DQEJBDEWBBSU7YEhw4pGw4x1WRsMEwtdbMeBADBcBgkrBgEEAYI3EAQxTzBNMDkxETAPBgNVBAoM CEVyaWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEAfnb+QKJYbr lz+OaXsA6lEwXgYLKoZIhvcNAQkQAgsxT6BNMDkxETAPBgNVBAoMCEVyaWNzc29uMSQwIgYDVQQD DBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEAfnb+QKJYbrlz+OaXsA6lEwDQYJKoZIhvcN AQEBBQAEgYBhrS4zxHd+dlT1yWL0NNjs6yfLpS4uHgcwY96zXtr+6gJ9ldTqxWGcleM0DDdL5TyN 9bEKHRxNsQQdOvEi3hD0t1I+ixyws2QrLrKyp5VXhqIs1qginR6pVQKG7jP0vdX7vMvRbUBAJVE2 9/u/Wi/mOPwcecXES6Ct2kZ2eaOyvwAAAAAAAA== --Apple-Mail-7-157293723-- From christian.vogt@ericsson.com Thu Jun 11 14:24:25 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2D3D3A6B9A for ; Thu, 11 Jun 2009 14:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.37 X-Spam-Level: X-Spam-Status: No, score=-6.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCV3U-QWMxQ1 for ; Thu, 11 Jun 2009 14:24:24 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 31F4E3A6B68 for ; Thu, 11 Jun 2009 14:24:23 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n5BLO3QH017576; Thu, 11 Jun 2009 16:24:05 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jun 2009 16:23:30 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jun 2009 16:23:29 -0500 Message-Id: <49417952-8570-467E-B312-B759DC3D88DD@ericsson.com> From: Christian Vogt To: Eric Levy-Abegnoli , Marcelo Bagnulo Braun In-Reply-To: <4A30D6CD.8060209@it.uc3m.es> Content-Type: multipart/signed; boundary=Apple-Mail-8-160237414; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 11 Jun 2009 14:23:27 -0700 References: <4A2C0DFB.3040803@it.uc3m.es> <4A2D2221.4030503@cisco.com> <4A2D2739.1000206@it.uc3m.es> <4A2F9E29.5070704@cisco.com> <4A30D6CD.8060209@it.uc3m.es> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 11 Jun 2009 21:23:29.0790 (UTC) FILETIME=[DD9269E0:01C9EADA] Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 21:24:25 -0000 --Apple-Mail-8-160237414 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Eric and Marcelo - Reading the email exchange between you two, I am making the following conclusions: Using control packets other than DAD to infer address ownership could indeed help reducing the probability of false packet drops. But what should be carefully evaluated is: - How much complexity would this add to the SAVI protocol? - Would this introduce new vulnerabilities? In particular the latter seems problematic to me. If we were to use control packets other than DAD to infer address ownership, how would we prevent spoofing of those control packets? Keep in mind that, unlike many other control packets, DAD has the nice property that it gives the victim of a spoofing attack a chance to speak up. This increases the bar for spoofing DAD packets. - Christian --Apple-Mail-8-160237414 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8DCCBDIw ggMaoAMCAQICEAfnb+QKJYbrlz+OaXsA6lEwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0wNzA5MTMxMTI5 MTRaFw0xMDA5MTMxMTI5MTBaMGoxETAPBgNVBAoMCEVyaWNzc29uMRcwFQYDVQQDDA5DaHJpc3Rp YW4gVm9ndDEQMA4GA1UEBRMHZWNocnZvZzEqMCgGCSqGSIb3DQEJARYbY2hyaXN0aWFuLnZvZ3RA ZXJpY3Nzb24uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCVGNN5yyhnvz5VWwGDcmey bI9H/DGF0LQmxS+L3gJ9gJIAQ2NPhF16dsWnlpCwS+VsKwMRfh3BsYGY88Hlx/Yvo6NfqE6evobv prxbgKiFP7j1c7Ntke/6SRamUVPFnWrFuaOuXTwU7GUAd/uOoCRNs/nq1hdQRC684gX/kAfBYwID AQABo4IBhzCCAYMwgcAGA1UdHwSBuDCBtTCBsqCBr6CBrIY3aHR0cDovL2NybC50cnVzdC50ZWxp YS5jb20vRXJpY3Nzb25OTEluZGl2aWR1YWxDQTAxLmNybIZxbGRhcDovL2xkYXAudHJ1c3QudGVs aWEuY29tL2NuPUVyaWNzc29uJTIwTkwlMjBJbmRpdmlkdWFsJTIwQ0EwMSxvPUVyaWNzc29uP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2UwJgYDVR0RBB8wHYEbY2hyaXN0aWFu LnZvZ3RAZXJpY3Nzb24uY29tMEYGA1UdIAQ/MD0wOwYGKoVwawEBMDEwLwYIKwYBBQUHAgEWI2h0 dHA6Ly93d3cuZXJpY3Nzb24uY29tL2xlZ2FsLnNodG1sMB0GA1UdDgQWBBQ2hgtYCoOVEiitjMNu mLE8wGuILzAfBgNVHSMEGDAWgBSWJ8O43qVfXUQ+OVLlRbF2X2MwmzAOBgNVHQ8BAf8EBAMCBaAw DQYJKoZIhvcNAQEFBQADggEBAKYJznyxAs6fzHgXDHa00mqyU/+ykFi9HvBv9MSmD2M1X+bifCd6 /jVVrGZWfMfPSV/AbqQjXVQfyHU1R0EqtgEFLyfNVmEGI9lXkkQb5cXNwaJYVj/+ozy+oSu1ZzZA j0GM6NVvhCwGapHoNDPDWe25UdvmOFxxVo6UMq3TWPcSUMq4s3vHLe5n7tgNCdcVUMeqTrAe9cKw TGy7+eJK48rbBcBtKxq2sTY/4H5H6prEKaVlwGW96PydY0IVu4QGVhUT/ONCVByl5xLImDa0tEaX npUj0Y0ys4DneQ3Bxf6DEMuB5+BiSkBk8FmEaSaj2xA/ShtYuaKIO6e9JjpvGb0wggRFMIIDLaAD AgECAhATyer/3iatqdykyiOBg0fjMA0GCSqGSIb3DQEBBQUAMEQxGjAYBgNVBAoMEVRlbGlhU29u ZXJhIEdyb3VwMSYwJAYDVQQDDB1UZWxpYVNvbmVyYSBQdWJsaWMgUm9vdCBDQSB2MTAeFw0wNjEw MDYxMDAwNTNaFw0xNjEwMDIwNTA0MTdaMDkxETAPBgNVBAoMCEVyaWNzc29uMSQwIgYDVQQDDBtF cmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC2EHfkNR7rh8Q8jRhZRD8wsbjzxTuVtscq/p6glZzSeEGBXtRwAqmr6jS8FBiKiBMh79ay537m /SwXO3UKUR45f3YIIp9DjThSd+p2xhG3x4yyc9gczlr8JfOEnPhcdPSKw1P0mUlhUn4ak7t009/Y e/W6x3UZHTwVIAWILIhSq4hyNE4z+RvOtvB9uwQ86lKcxi0mFoLev7acLjh+ZXHzXx1jHAmF0ZaG 79CpbvJcRuWplqgJ6qx+hAjsmCU0Wx07GkyGTh8vUMP9Hlz7oyk+7VOccUiNknXHias1GwM9qBUU Oj8e/xsnaTP0ZfqmKBj3Grh1C9WknlSWagxanCBdAgMBAAGjggE8MIIBODASBgNVHRMBAf8ECDAG AQH/AgEAMEYGA1UdIAQ/MD0wOwYHKoVwIwIBATAwMC4GCCsGAQUFBwIBFiJodHRwczovL3JlcG9z aXRvcnkudHJ1c3QudGVsaWEuY29tMIGJBgNVHR8EgYEwfzB9oHugeYZ3bGRhcDovL2xkYXAudHJ1 c3QudGVsaWEuY29tL2NuPVRlbGlhU29uZXJhJTIwUHVibGljJTIwUm9vdCUyMENBJTIwdjEsbz1U ZWxpYVNvbmVyYSUyMEdyb3VwP2F1dGhvcml0eXJldm9jYXRpb25saXN0P2Jhc2UwDgYDVR0PAQH/ BAQDAgEGMB0GA1UdDgQWBBSWJ8O43qVfXUQ+OVLlRbF2X2MwmzAfBgNVHSMEGDAWgBRF2/CPuBpi oagjG2OIOKPb4Bpi8TANBgkqhkiG9w0BAQUFAAOCAQEAdgBKKkM/jN0WvWpZKZ/2J8IVyL+rT44V L0rjbNNDYXdE/V4ZSFN2uuQmgf1Ckqp2shNLe0NEKt6/sfxit4p/5opPIvzytv6vB7rc2BUs8+ja c7aaNiRuwBCjiT1Wnnm454OOZurzQu0SH81PbBtiwUf4XsEvLOnRRZ+9MO/ecVMCQVmeuzsyCl6y FVbx0zmKW1gPjBEigF8BYZ1Tjazk1pVcKzFIuB24j1qTpPsUG4HoQhIu5rt3F7GlNV6t5DF7ojbg u1SqKG/JhTvaPUU/nZYqw9rkV8Dabwrt27reisobtPp78tolxio3ZcZVk7HQ8rpV2M/jmAjGfZRV kczCDzCCBG0wggNVoAMCAQICEQCcsIwEmsuXInhjYrYbhlo9MA0GCSqGSIb3DQEBBQUAMDoxGTAX BgNVBAoTEFJTQSBTZWN1cml0eSBJbmMxHTAbBgNVBAsTFFJTQSBTZWN1cml0eSAyMDQ4IFYzMB4X DTA2MTAzMTIwNDIyN1oXDTE2MTEwMTE1NDIyNVowRDEaMBgGA1UECgwRVGVsaWFTb25lcmEgR3Jv dXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyk8QA2qQgKt5qZV+EeIDbflmXuUChp2lREEsmO5SAiheQ7lXVjzC xw484cOSMw3fOtGWcf9Fa4Rgdw5j+EgyFgiqNj8b2OTXJHQVj1qf09rmkHTgMIKh6TdKXtV+/43p efVrFmFyhoP/NVrYe92Sv4HhOxs/T749S1OjeGISzIKKMSpwkvmYweYnFgIPkHdUKUIReOh9Ym6e i7AVg6eejD6YPBeV+suzBlXCmC3Zyzj7POLsUVvarNZAaKc0AY+rOUslYfAPo+ZYgwY4IV2KcP/q WhhHahz3khWMWSniWrZoxCi2JcXGVkSn+N+ir0APYwYTBJsrTDWxonEdZkR+rQIDAQABo4IBYjCC AV4wHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFEXb8I+4GmKhqCMb Y4g4o9vgGmLxMBIGA1UdEwEB/wQIMAYBAf8CAQQwgYUGA1UdIAR+MHwwPQYJKoZIhvcNBQYBMDAw LgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wOwYHKoVwIwIB ATAwMC4GCCsGAQUFBwIBFiJodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWEuY29tMHAGA1Ud HwRpMGcwZaBjoGGGX2h0dHA6Ly93d3cucnNhc2VjdXJpdHkuY29tL3Byb2R1Y3RzL2tlb24vcmVw b3NpdG9yeS9jZXJ0aWZpY2F0ZV9zdGF0dXMvUlNBX1NlY3VyaXR5XzIwNDhfdjMuQ1JMMA4GA1Ud DwEB/wQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEABF6aLNgpyJu//O9srUqxB1mYL4TlBJFJtuT1 n/15FpKONU2i/byEtUugHVgoTalpp2Ikuxn2iIgzPbNQ+iu4YnVgQzpuOmzXTN2cITMgwn5AyUoH idMPu2Jo7wobu4Fqg2QrG7WeYANYsQk3Q57mQeuyRkjxluq+93KK2gz/HYjqYkKLjLzOmyrkzwR/ 9aaC3HLFMbCoK0NtyQvS1gkW/HGB5GY1xR9SuOE7CJeS53tqE9CSN6cHQNr+ozuKfzix57T/p6Y8 D23nTD1GZA2ApHdy0sY/HNyU8bQPEpTwrSBxNYYeucYoYNSUSJYkqYa6q/ZG38B3XlcT3TiORrQ2 DzGCAhIwggIOAgEBME0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EwMQIQB+dv5AolhuuXP45pewDqUTAJBgUrDgMCGgUAoIIBGzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2MTEyMTIzMzBaMCMGCSqGSIb3 DQEJBDEWBBSAWtWIQgFYrf9sHVHSme00FW1t6TBcBgkrBgEEAYI3EAQxTzBNMDkxETAPBgNVBAoM CEVyaWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEAfnb+QKJYbr lz+OaXsA6lEwXgYLKoZIhvcNAQkQAgsxT6BNMDkxETAPBgNVBAoMCEVyaWNzc29uMSQwIgYDVQQD DBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEAfnb+QKJYbrlz+OaXsA6lEwDQYJKoZIhvcN AQEBBQAEgYB4pN/zq3ZVg4mSK1tXnoz3/Tz3ugn7Dt05ymjssMe6SWeM7YY1OEDvr/W1UnkzPlAj gOyw/IO9Wf89So4KzVfbgAlXVCnf8ouHi7xUa4VTbgLJv1Qh5royxwuu6XjJVV1jQdmmPqJgiN/+ h2ExJ8eD0LL0pu7WuVmnbkZjf6wAkQAAAAAAAA== --Apple-Mail-8-160237414-- From marcelo@it.uc3m.es Thu Jun 11 14:28:32 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DA7228C10A for ; Thu, 11 Jun 2009 14:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.405 X-Spam-Level: X-Spam-Status: No, score=-6.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0p9oKmNS1d3 for ; Thu, 11 Jun 2009 14:28:31 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 7435528C0CF for ; Thu, 11 Jun 2009 14:28:31 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [163.117.203.209]) by smtp01.uc3m.es (Postfix) with ESMTP id 152E4B48D18; Thu, 11 Jun 2009 23:28:37 +0200 (CEST) Message-ID: <4A317704.90307@it.uc3m.es> Date: Thu, 11 Jun 2009 23:28:36 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christian Vogt References: <59D15025-814F-4967-84EC-50FCA0225CC1@cisco.com> <6983BF97BFC24D4EA551F14071232918010CD676@melmail.netstarnetworks.com> <15A410E1-2A4C-4861-BF07-CFD5EBFA8F8C@ericsson.com> In-Reply-To: <15A410E1-2A4C-4861-BF07-CFD5EBFA8F8C@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16698.000 Cc: SAVI Mailing List , Greg Daley Subject: Re: [savi] On Protecting Unused Addresses in IPv6 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 21:28:32 -0000 Christian Vogt escribió: > Greg - > > If I understand you correctly, you are proposing a "DHCP-only mode" for > SAVI, for use in networks where Stateless Address Autoconfiguration is > disabled. In DHCP-only mode, due to DHCP exchanges being reliable, SAVI > devices could drop packets without corresponding binding without risking > false packet drops. Please correct me if I misinterpreted your email. > > I think your observations are correct. Yet we have to analyze what the > implications of a DHCP-only mode would be. > > The proposed DHCP-only option was discussed before in the working group, > although this discussion hasn't gotten far yet. One of the difficulties > is to prevent spoofing of DHCP messages. Another is to prevent SAVI > devices from getting tricked into DHCP-only mode. Especially the latter > would be a disaster in networks where no DHCP is used. Other potnetial issues include: - how to recover the binding state when the savi devices reboots - how to deal with mobility like scenarions, where the two dhcp exchanges for the same address traverse different set of savi devices (woudl this imply that 2 savi devices have different bindings for the same address? would this cause any problem?) Regards, marcelo > > - Christian > > > > On Jun 9, 2009, Greg Daley wrote: > >> Hi Chris, >> >> I think that if a prefix must be statefully configured, it would be >> possible to make use of DHCPv6 to control address allocation for those >> prefixes. Devices could be configured with such prefixes, or identify >> them by seeing Router Advertisements. >> >> Devices which do not get addresses allocated via DHCP then do not get >> transmission rights. >> >> This is essentially what some deployed products do today with IPv4. It >> is fairly reliable, although I personally have reservations about what >> should be done in the case of state loss on the snooping device (for >> IPv4). >> >> This may actually be an important use case: Spoofing on address managed >> networks. >> >> Greg Daley > > > From xiayangsong@huawei.com Fri Jun 12 21:26:03 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70D023A6918 for ; Fri, 12 Jun 2009 21:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.995 X-Spam-Level: X-Spam-Status: No, score=-0.995 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nv+b33CEmkih for ; Fri, 12 Jun 2009 21:26:01 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 8387D3A67D0 for ; Fri, 12 Jun 2009 21:26:01 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL5007EBTNBCU@szxga03-in.huawei.com> for savi@ietf.org; Sat, 13 Jun 2009 12:25:59 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL500CO0TNBI5@szxga03-in.huawei.com> for savi@ietf.org; Sat, 13 Jun 2009 12:25:59 +0800 (CST) Received: from X24512z ([10.51.0.37]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KL500L8XTN6Y4@szxml04-in.huawei.com> for savi@ietf.org; Sat, 13 Jun 2009 12:25:59 +0800 (CST) Date: Fri, 12 Jun 2009 23:25:53 -0500 From: Frank Xia To: SAVI Mailing List Message-id: <00ef01c9ebdf$0d2df5c0$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <5C979E3E-1CA3-4F45-AA34-D20F7B58536A@ericsson.com> <009001c9479d$9ac662a0$0501a8c0@china.huawei.com> Subject: [savi] SAVI for Delegated IPv6 Prefixes X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2009 04:26:03 -0000 Hi Folks The linked draft is an update of our previous contribution http://www.ietf.org/internet-drafts/draft-kaippallimalil-savi-dhcp-pd-00.txt. Abstract: This memo introduces a public access topology which includes hosts, Customer Premise Equipment Router (CPE-R), switches and access routers. A CPE-R advertises prefixes to a host for its address configuration, while these prefixes are in turn delegated to the CPE-R from the access router. A switch located between the CPE-R and the router builds filtering table for traffic originating from the host by snooping prefix delegating signaling. Comments are welcome! BR Frank ----- Original Message ----- From: "Frank Xia" To: "Christian Vogt" ; "SAVI Mailing List" Sent: Saturday, November 15, 2008 10:44 PM Subject: Re: [savi] SAVI Meeting Agenda for IETF 73 > Hi Folks > > We prepared a contribution for IETF and Broadband Forum, > unfortunately, we missed the submission cutoff time. > > Here is the weblink: > http://www-etud.iro.umontreal.ca/~sarikaya/drafts/draft-kaippallimalil-savi-ipv6-bbnet-00.txt > > Comments are very welcome. > > BR > Frank > > > ----- Original Message ----- > From: "Christian Vogt" > To: "SAVI Mailing List" > Sent: Thursday, November 13, 2008 2:17 PM > Subject: [savi] SAVI Meeting Agenda for IETF 73 > > >> Dear SAVI Folks, >> >> below the agenda for our upcoming meeting in Minneapolis. >> >> CU soon, Christian >> >> >> ----------------------------------------------------------- >> Agenda of the SAVI working group meeting at IETF 73 >> Monday, November 17, 2008, 9:00 am - 11:30 am, Salon AB >> ----------------------------------------------------------- >> >> Introduction and agenda bashing 9:00 am >> Bill Fenner and Christian Vogt >> >> Summary of design decisions so far 9:10 am >> Christian Vogt >> >> First-come-first-serve SAVI for IPv4 + IPv6 9:30 am >> Marcelo Bagnulo >> >> SAVI for IPv6 Secure Neighbor Discovery 10:00 am >> Marcelo Bagnulo >> >> Thoughts about SAVI in Ethernet-based broadband 10:30 am >> David Miles and Wojciech Dec >> >> SAVI scenarios and solution space 11:00 am >> Jun Bi >> >> end at 11:30 am >> >> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From marcelo@it.uc3m.es Sun Jun 14 09:33:50 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65BBE3A6BD8 for ; Sun, 14 Jun 2009 09:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.915 X-Spam-Level: X-Spam-Status: No, score=-5.915 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClAlb3h6B+ig for ; Sun, 14 Jun 2009 09:33:49 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 66FAC3A6BF7 for ; Sun, 14 Jun 2009 09:33:48 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (130.pool85-59-201.dynamic.orange.es [85.59.201.130]) by smtp02.uc3m.es (Postfix) with ESMTP id 0BD8F6B9EAE; Sun, 14 Jun 2009 18:33:56 +0200 (CEST) Message-ID: <4A3379E8.5020202@it.uc3m.es> Date: Sat, 13 Jun 2009 12:05:28 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christian Vogt References: <4A2C0DFB.3040803@it.uc3m.es> <4A2D2221.4030503@cisco.com> <4A2D2739.1000206@it.uc3m.es> <4A2F9E29.5070704@cisco.com> <4A30D6CD.8060209@it.uc3m.es> <49417952-8570-467E-B312-B759DC3D88DD@ericsson.com> In-Reply-To: <49417952-8570-467E-B312-B759DC3D88DD@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16704.000 Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 16:33:50 -0000 Christian Vogt escribió: > Eric and Marcelo - > > Reading the email exchange between you two, I am making the following > conclusions: Using control packets other than DAD to infer address > ownership could indeed help reducing the probability of false packet > drops. But what should be carefully evaluated is: > > - How much complexity would this add to the SAVI protocol? > > - Would this introduce new vulnerabilities? > > In particular the latter seems problematic to me. If we were to use > control packets other than DAD to infer address ownership, how would we > prevent spoofing of those control packets? Keep in mind that, unlike > many other control packets, DAD has the nice property that it gives > the victim of a spoofing attack a chance to speak up. This increases > the bar for spoofing DAD packets. right it _may_ be worth considering a few other packets. For instance, the unsolicited NAdv Eric was mentioning may be worth considering, but again, a detailed analyis as the one we have been doing for DAD is needed. Eric, do you have other msgs that you think would be worth considering? Regards, marcelo > > - Christian > > > From christian.vogt@ericsson.com Sun Jun 14 20:21:56 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B8AA3A6910 for ; Sun, 14 Jun 2009 20:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yb5XnFYJ2Cpb for ; Sun, 14 Jun 2009 20:21:55 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 625403A6900 for ; Sun, 14 Jun 2009 20:21:54 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n5F3M3LS030455 for ; Sun, 14 Jun 2009 22:22:03 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Jun 2009 22:22:03 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Jun 2009 22:22:02 -0500 Message-Id: <4BDE4243-4EAC-4D81-B827-7ED8A55787BE@ericsson.com> From: Christian Vogt To: SAVI Mailing List Content-Type: multipart/signed; boundary=Apple-Mail-20-440949782; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 14 Jun 2009 20:21:59 -0700 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 15 Jun 2009 03:22:02.0813 (UTC) FILETIME=[739276D0:01C9ED68] Subject: [savi] Your opinion on a different tradeoff for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 03:21:56 -0000 --Apple-Mail-20-440949782 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Folks - In order to make a decision on whether or not to move forward with the modified SAVI protocol that Marcelo has proposed [1], feedback from the working group is important. Several people have already provided their feedback. I would encourage also others to share their opinion. Please do so, on this mailing list, by Friday, June 19. Thank you. - Christian [1] http://www.ietf.org/mail-archive/web/savi/current/msg00654.html --Apple-Mail-20-440949782 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8DCCBDIw ggMaoAMCAQICEAfnb+QKJYbrlz+OaXsA6lEwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0wNzA5MTMxMTI5 MTRaFw0xMDA5MTMxMTI5MTBaMGoxETAPBgNVBAoMCEVyaWNzc29uMRcwFQYDVQQDDA5DaHJpc3Rp YW4gVm9ndDEQMA4GA1UEBRMHZWNocnZvZzEqMCgGCSqGSIb3DQEJARYbY2hyaXN0aWFuLnZvZ3RA ZXJpY3Nzb24uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCVGNN5yyhnvz5VWwGDcmey bI9H/DGF0LQmxS+L3gJ9gJIAQ2NPhF16dsWnlpCwS+VsKwMRfh3BsYGY88Hlx/Yvo6NfqE6evobv prxbgKiFP7j1c7Ntke/6SRamUVPFnWrFuaOuXTwU7GUAd/uOoCRNs/nq1hdQRC684gX/kAfBYwID AQABo4IBhzCCAYMwgcAGA1UdHwSBuDCBtTCBsqCBr6CBrIY3aHR0cDovL2NybC50cnVzdC50ZWxp YS5jb20vRXJpY3Nzb25OTEluZGl2aWR1YWxDQTAxLmNybIZxbGRhcDovL2xkYXAudHJ1c3QudGVs aWEuY29tL2NuPUVyaWNzc29uJTIwTkwlMjBJbmRpdmlkdWFsJTIwQ0EwMSxvPUVyaWNzc29uP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2UwJgYDVR0RBB8wHYEbY2hyaXN0aWFu LnZvZ3RAZXJpY3Nzb24uY29tMEYGA1UdIAQ/MD0wOwYGKoVwawEBMDEwLwYIKwYBBQUHAgEWI2h0 dHA6Ly93d3cuZXJpY3Nzb24uY29tL2xlZ2FsLnNodG1sMB0GA1UdDgQWBBQ2hgtYCoOVEiitjMNu mLE8wGuILzAfBgNVHSMEGDAWgBSWJ8O43qVfXUQ+OVLlRbF2X2MwmzAOBgNVHQ8BAf8EBAMCBaAw DQYJKoZIhvcNAQEFBQADggEBAKYJznyxAs6fzHgXDHa00mqyU/+ykFi9HvBv9MSmD2M1X+bifCd6 /jVVrGZWfMfPSV/AbqQjXVQfyHU1R0EqtgEFLyfNVmEGI9lXkkQb5cXNwaJYVj/+ozy+oSu1ZzZA j0GM6NVvhCwGapHoNDPDWe25UdvmOFxxVo6UMq3TWPcSUMq4s3vHLe5n7tgNCdcVUMeqTrAe9cKw TGy7+eJK48rbBcBtKxq2sTY/4H5H6prEKaVlwGW96PydY0IVu4QGVhUT/ONCVByl5xLImDa0tEaX npUj0Y0ys4DneQ3Bxf6DEMuB5+BiSkBk8FmEaSaj2xA/ShtYuaKIO6e9JjpvGb0wggRFMIIDLaAD AgECAhATyer/3iatqdykyiOBg0fjMA0GCSqGSIb3DQEBBQUAMEQxGjAYBgNVBAoMEVRlbGlhU29u ZXJhIEdyb3VwMSYwJAYDVQQDDB1UZWxpYVNvbmVyYSBQdWJsaWMgUm9vdCBDQSB2MTAeFw0wNjEw MDYxMDAwNTNaFw0xNjEwMDIwNTA0MTdaMDkxETAPBgNVBAoMCEVyaWNzc29uMSQwIgYDVQQDDBtF cmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC2EHfkNR7rh8Q8jRhZRD8wsbjzxTuVtscq/p6glZzSeEGBXtRwAqmr6jS8FBiKiBMh79ay537m /SwXO3UKUR45f3YIIp9DjThSd+p2xhG3x4yyc9gczlr8JfOEnPhcdPSKw1P0mUlhUn4ak7t009/Y e/W6x3UZHTwVIAWILIhSq4hyNE4z+RvOtvB9uwQ86lKcxi0mFoLev7acLjh+ZXHzXx1jHAmF0ZaG 79CpbvJcRuWplqgJ6qx+hAjsmCU0Wx07GkyGTh8vUMP9Hlz7oyk+7VOccUiNknXHias1GwM9qBUU Oj8e/xsnaTP0ZfqmKBj3Grh1C9WknlSWagxanCBdAgMBAAGjggE8MIIBODASBgNVHRMBAf8ECDAG AQH/AgEAMEYGA1UdIAQ/MD0wOwYHKoVwIwIBATAwMC4GCCsGAQUFBwIBFiJodHRwczovL3JlcG9z aXRvcnkudHJ1c3QudGVsaWEuY29tMIGJBgNVHR8EgYEwfzB9oHugeYZ3bGRhcDovL2xkYXAudHJ1 c3QudGVsaWEuY29tL2NuPVRlbGlhU29uZXJhJTIwUHVibGljJTIwUm9vdCUyMENBJTIwdjEsbz1U ZWxpYVNvbmVyYSUyMEdyb3VwP2F1dGhvcml0eXJldm9jYXRpb25saXN0P2Jhc2UwDgYDVR0PAQH/ BAQDAgEGMB0GA1UdDgQWBBSWJ8O43qVfXUQ+OVLlRbF2X2MwmzAfBgNVHSMEGDAWgBRF2/CPuBpi oagjG2OIOKPb4Bpi8TANBgkqhkiG9w0BAQUFAAOCAQEAdgBKKkM/jN0WvWpZKZ/2J8IVyL+rT44V L0rjbNNDYXdE/V4ZSFN2uuQmgf1Ckqp2shNLe0NEKt6/sfxit4p/5opPIvzytv6vB7rc2BUs8+ja c7aaNiRuwBCjiT1Wnnm454OOZurzQu0SH81PbBtiwUf4XsEvLOnRRZ+9MO/ecVMCQVmeuzsyCl6y FVbx0zmKW1gPjBEigF8BYZ1Tjazk1pVcKzFIuB24j1qTpPsUG4HoQhIu5rt3F7GlNV6t5DF7ojbg u1SqKG/JhTvaPUU/nZYqw9rkV8Dabwrt27reisobtPp78tolxio3ZcZVk7HQ8rpV2M/jmAjGfZRV kczCDzCCBG0wggNVoAMCAQICEQCcsIwEmsuXInhjYrYbhlo9MA0GCSqGSIb3DQEBBQUAMDoxGTAX BgNVBAoTEFJTQSBTZWN1cml0eSBJbmMxHTAbBgNVBAsTFFJTQSBTZWN1cml0eSAyMDQ4IFYzMB4X DTA2MTAzMTIwNDIyN1oXDTE2MTEwMTE1NDIyNVowRDEaMBgGA1UECgwRVGVsaWFTb25lcmEgR3Jv dXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyk8QA2qQgKt5qZV+EeIDbflmXuUChp2lREEsmO5SAiheQ7lXVjzC xw484cOSMw3fOtGWcf9Fa4Rgdw5j+EgyFgiqNj8b2OTXJHQVj1qf09rmkHTgMIKh6TdKXtV+/43p efVrFmFyhoP/NVrYe92Sv4HhOxs/T749S1OjeGISzIKKMSpwkvmYweYnFgIPkHdUKUIReOh9Ym6e i7AVg6eejD6YPBeV+suzBlXCmC3Zyzj7POLsUVvarNZAaKc0AY+rOUslYfAPo+ZYgwY4IV2KcP/q WhhHahz3khWMWSniWrZoxCi2JcXGVkSn+N+ir0APYwYTBJsrTDWxonEdZkR+rQIDAQABo4IBYjCC AV4wHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFEXb8I+4GmKhqCMb Y4g4o9vgGmLxMBIGA1UdEwEB/wQIMAYBAf8CAQQwgYUGA1UdIAR+MHwwPQYJKoZIhvcNBQYBMDAw LgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wOwYHKoVwIwIB ATAwMC4GCCsGAQUFBwIBFiJodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWEuY29tMHAGA1Ud HwRpMGcwZaBjoGGGX2h0dHA6Ly93d3cucnNhc2VjdXJpdHkuY29tL3Byb2R1Y3RzL2tlb24vcmVw b3NpdG9yeS9jZXJ0aWZpY2F0ZV9zdGF0dXMvUlNBX1NlY3VyaXR5XzIwNDhfdjMuQ1JMMA4GA1Ud DwEB/wQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEABF6aLNgpyJu//O9srUqxB1mYL4TlBJFJtuT1 n/15FpKONU2i/byEtUugHVgoTalpp2Ikuxn2iIgzPbNQ+iu4YnVgQzpuOmzXTN2cITMgwn5AyUoH idMPu2Jo7wobu4Fqg2QrG7WeYANYsQk3Q57mQeuyRkjxluq+93KK2gz/HYjqYkKLjLzOmyrkzwR/ 9aaC3HLFMbCoK0NtyQvS1gkW/HGB5GY1xR9SuOE7CJeS53tqE9CSN6cHQNr+ozuKfzix57T/p6Y8 D23nTD1GZA2ApHdy0sY/HNyU8bQPEpTwrSBxNYYeucYoYNSUSJYkqYa6q/ZG38B3XlcT3TiORrQ2 DzGCAhIwggIOAgEBME0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EwMQIQB+dv5AolhuuXP45pewDqUTAJBgUrDgMCGgUAoIIBGzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2MTUwMzIyMDJaMCMGCSqGSIb3 DQEJBDEWBBQhLfLuJUL+Lt4DMSX+LEgx2NIosjBcBgkrBgEEAYI3EAQxTzBNMDkxETAPBgNVBAoM CEVyaWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEAfnb+QKJYbr lz+OaXsA6lEwXgYLKoZIhvcNAQkQAgsxT6BNMDkxETAPBgNVBAoMCEVyaWNzc29uMSQwIgYDVQQD DBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEAfnb+QKJYbrlz+OaXsA6lEwDQYJKoZIhvcN AQEBBQAEgYCLH88mQKDp6M0TeBiEMgISGexnsL5BKCR1moKPTKndTfbc29nisyq09NVAbHBfmpyR X5IR/6EhNyaPEJnxQcT5dvn4R1LvpySg3GAGlbLS8aoyirA7XhNy3LrnZw6AgDka+/7hNli3Esmh YZILt0Jxe7uL8IwpUYmN0yNtzilJnAAAAAAAAA== --Apple-Mail-20-440949782-- From fred@cisco.com Sun Jun 14 21:42:47 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79E943A69F6 for ; Sun, 14 Jun 2009 21:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILF9EpYfCX7v for ; Sun, 14 Jun 2009 21:42:46 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id CEEEA3A6834 for ; Sun, 14 Jun 2009 21:42:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,220,1243814400"; d="scan'208";a="169853493" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 15 Jun 2009 04:42:56 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n5F4gun7002992; Sun, 14 Jun 2009 21:42:56 -0700 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n5F4gu7o026408; Mon, 15 Jun 2009 04:42:56 GMT Message-Id: From: Fred Baker To: Christian Vogt In-Reply-To: <4BDE4243-4EAC-4D81-B827-7ED8A55787BE@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 14 Jun 2009 21:42:53 -0700 References: <4BDE4243-4EAC-4D81-B827-7ED8A55787BE@ericsson.com> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=283; t=1245040976; x=1245904976; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[savi]=20Your=20opinion=20on=20a=20diff erent=20tradeoff=20for=20SAVI |Sender:=20; bh=jvK+C9X42Kx/QXhhPOZ9RexkUBtqX2GW2dIKYJtpqqM=; b=DbqOyzIOzmnFCXa7OZARd5izIxKQnDa9xOaxsm4Kb2q4NScd1Kt7RLZkC9 FNpuYxkX5OwlE++7Gnnrf9VlysVSbLA0EYk1kxDbPZNQNzDlbwicAgaeiMYo KnMbumRgBq; Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: SAVI Mailing List Subject: Re: [savi] Your opinion on a different tradeoff for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 04:42:47 -0000 On Jun 14, 2009, at 8:21 PM, Christian Vogt wrote: > In order to make a decision on whether or not to move forward with the > modified SAVI protocol that Marcelo has proposed [1], feedback from > the > working group is important. A change of charter is also important. From junbi@cernet.edu.cn Sun Jun 14 22:00:10 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A53EA3A6AE6 for ; Sun, 14 Jun 2009 22:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.297 X-Spam-Level: * X-Spam-Status: No, score=1.297 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696, J_CHICKENPOX_61=0.6, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDlXsNHj8ryZ for ; Sun, 14 Jun 2009 22:00:09 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 7952F3A6B09 for ; Sun, 14 Jun 2009 22:00:07 -0700 (PDT) Received: from userPC([59.66.24.35]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54a364092; Mon, 15 Jun 2009 13:00:12 +0800 Message-ID: <73C3E864932143928B3A8333ABAA1DA5@userPC> From: "Jun Bi" To: "marcelo bagnulo braun" , "Fred Baker" References: <59D15025-814F-4967-84EC-50FCA0225CC1@cisco.com> <4A2C110A.6090602@it.uc3m.es> In-Reply-To: <4A2C110A.6090602@it.uc3m.es> Date: Mon, 15 Jun 2009 12:59:14 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: gGmSEQWB Cc: SAVI Mailing List Subject: Re: [savi] forwarding datagrams without bindings X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 05:00:10 -0000 We carefully discussed the default forwarding, we have some considerations: 1 Default forwarding will make the attacker easy to use it to launch spoofing packets: 1) When the SAVI switch directly attached to the source host lost DAD (a very low possibility case, CPS need to be enhanced in this case), both legal user and attacker under the same SAVI switch could send packets. 2) Even the SAVI switch directly attached to the source host get the DAD (the most usual case, and CPS works perfectly in this case), other switches in the same link may still lost the DAD (due to the DAD multicasting mechanism, it's not a low possibility case. Another reason is the link distance increasing brings more possibility to lost packets). Which means, host under other switches in the same link may don't have the binding. Then becaue of the default forwarding rule, attackers under those switches could send spoofing packets out. So that's the shortcomings of default forwarding (decrease the security level),then it doesn't meet the goal of SAVI and I also don't think the users will like it. 2 I think SAVI device should bring more security, so the default action should be dropping packets before binding is set up. Today, every 802.1x device will drop packets without passing authentication,and we didn't see any problem. So the default dropping is OK for users. The requirement of default dropping is actually how to make the binding more accurate. The only problem of CPS is that some DAD packet may be lost in the directly attached SAVI switch (in a very low possibility). A easy way to fix it is to make DAD redundant (like what IPv4 did, requires sending 3 packets,which is easy to be implemented). Certainly, we could find other way to enhance DAD. Any idea is welcomed. Anyway, I think default dropping will be the right approach (to meet the goal of SAVI and anti-spoofing). thanks, Jun Bi ----- Original Message ----- From: "marcelo bagnulo braun" To: "Fred Baker" Cc: "SAVI Mailing List" Sent: Monday, June 08, 2009 3:12 AM Subject: Re: [savi] forwarding datagrams without bindings FWIW, i think it is very important to understand the security implications of this alternative approach. I am not sure i understnad the implications myself, so, this dicussion is useful for that purpose. Fred Baker escribió: > Marcelo will, when he gets a few minutes (he is traveling this week), > flesh out the idea that he discussed on the call this morning. While I'm > thinking about it, I would like to summarize the thought and the question > that was running through my head. > > The discussion related to whether we should set up SAVI bindings using > FCFS only on control datagrams or also on data exchanges. He suggested > that we only set up binding state on control packets but that we permit > data packets that correspond to no binding (eg, from is an address that > nobody in the LAN is known to be using) to pass. > > My question goes to the heart of what we are trying to do here. It seems > to me that SAVI is trying, ultimately, to guarantee that if one system > sends a datagram to another system, the second system's reply will make it > back to the first system barring system or network failure. Address > spoofing is the obvious attack that we have been trying to prevent - the > use of a source address such that A sends to B and B's reply is delivered > to some third party. I am not sure how this could happen with the proposed approach, since the attacker cannot use the address of a real host, since the real host would normally had perform DAD, so a binding would exist in the SAVI device, so packets coming from the attacker with that address would be drop. > But it seems to me that address anonymization is also an attack that the > technology is trying to prevent - if A sends to B, B might reply but the > network be systemically unable to deliver it and the original source of > the datagram is not determinable. not dropping the packet doesn't mean that the SAVI device cannot log the occurrence of such data packet,s which would allow to trace back to the lower anchor of those packets. > In short, I think SAVI is trying to do more than "prevent spoofing", it is > trying to ensure that datagrams in the wild are valid and useful as > opposed to being attack traffic. To do that, the point is not the negative > statement that "it doesn't spoof someone else's address", the point is the > positive statement that "it uses its own address". > > To make that positive statement, whether we set up bindings on control or > data packets, we can only allow datagrams to pass that originate from > addresses that are associated with the putative sender, apart from systems > that routinely originate datagrams at L2 from other L3 addresses, such as > routers do. > > > In case what I just said is not clear, let me put together an attack > example. We often see DDOS attacks in which some large number of systems > simultaneously send a datagram to some targeted address using a random > source address. To track these back, what operations folks try to do is > track the trajectory of those attacking datagrams. The effectiveness of > the attack is limited by BCP 38 filters (uRPF or whatever), which only > allow packets through for which the random number in fact selected the > right source prefix. But in IPv6, selecting the right /64 still means one > has 2^64 interface identifiers to choose from, and that the probability of > randomly selecting that of a neighbor is pretty low. So while preventing > address spoofing is an obvious goal, simply doing that doesn't prevent > attacks in which the source address is incorrect; one also has to prevent > address anonymization. I fail to see why these attacking hosts would simply do the DAD for the addresses they want to use and get access to the savi filters by doing so. I mean, if you have a solution that drops packets if there is no binding, then the attacker simply needs to perform the DAD , create the binding and then send the packets (which would be the easier thing to do, cause that is what OS do by default) > > > Which brings us back to the question of address binding. If what we are > doing is preventing systems from sending from addresses that are not their > own, So, there are 2 types of addresses in a link. the addresses that already belong to a host and the addresses that don't belong to anyone. The proposed approach of forwarding packets wihtout bindings prevents the attacker to use the address of other hosts. What the proposed approach doens't do is to prevent an attacker to use addresses that do not belong to any host. But, if they do not belong to nay host, the attacker can simply perform DAD and create the binding and own the address. So, what is that we are missing form the security perspective in this appraoch? Regards, marcelo > then there is no real question of interoperating with non-SAVI switches in > other parts of the network. SAVI switches somehow know which ports connect > to hosts (as opposed to routers, switch/switch trunks, and some kinds of > servers), and drop datagrams they send that are not from addresses bound > to them. If one wants to have a SAVI network, one doesn't try to be > backward compatible with non-SAVI equipment, one replaces non-SAVI > equipment with SAVI equipment, hopefully by an upgrade for large switches, > but for consumer grade equipment by replacing it. The one case where that > does not follow is a desktop switch, in which the larger switch may not be > able to distinguish between a virtual host and a set of hosts connected by > a 5 port potentially-non-SAVI switch and that to the wall; there, the big > switch might associate IPv6 addresses with MAC Addresses and those in turn > with a port. > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi From elevyabe@cisco.com Sun Jun 14 23:40:40 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CA673A695E for ; Sun, 14 Jun 2009 23:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.932 X-Spam-Level: X-Spam-Status: No, score=-9.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7jCfzD0iip9 for ; Sun, 14 Jun 2009 23:40:39 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9D6773A6941 for ; Sun, 14 Jun 2009 23:40:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,220,1243814400"; d="scan'208";a="42759982" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 15 Jun 2009 06:40:47 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5F6elGo011776; Mon, 15 Jun 2009 08:40:47 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5F6el3j003615; Mon, 15 Jun 2009 06:40:47 GMT Received: from xmb-ams-335.cisco.com ([144.254.231.80]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jun 2009 08:40:47 +0200 Received: from [144.254.53.107] ([144.254.53.107]) by xmb-ams-335.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jun 2009 08:40:47 +0200 Message-ID: <4A35ECEE.7060801@cisco.com> Date: Mon, 15 Jun 2009 08:40:46 +0200 From: Eric Levy-Abegnoli User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christian Vogt References: <4A2C0DFB.3040803@it.uc3m.es> <4A2D2221.4030503@cisco.com> <4A2D2739.1000206@it.uc3m.es> <4A2F9E29.5070704@cisco.com> <4A30D6CD.8060209@it.uc3m.es> <49417952-8570-467E-B312-B759DC3D88DD@ericsson.com> In-Reply-To: <49417952-8570-467E-B312-B759DC3D88DD@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Jun 2009 06:40:47.0286 (UTC) FILETIME=[371CA560:01C9ED84] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2714; t=1245048047; x=1245912047; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=elevyabe@cisco.com; z=From:=20Eric=20Levy-Abegnoli=20 |Subject:=20Re=3A=20[savi]=20A=20different=20trade=20off=20 for=20SAVI |Sender:=20; bh=XEbD7Vy02RRIpv27kCGYauj0zHBEJIih8U599r9aD28=; b=mQbY28K0I5SYK+5MRtIP+nbtkW+3yKZB0j6PXXgj0HOQnNpD2hobCXm0cx +Gq/s2RCh0ddudJn63mzoW8+tFKDfm65D9JFKU7DVxSRD33bD8oDfo8RIs4b ssn9OWmAn7; Authentication-Results: ams-dkim-1; header.From=elevyabe@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 06:40:40 -0000 Christian , Christian Vogt a écrit : > Eric and Marcelo - > > Reading the email exchange between you two, I am making the following > conclusions: Using control packets other than DAD to infer address > ownership could indeed help reducing the probability of false packet > drops. But what should be carefully evaluated is: > > - How much complexity would this add to the SAVI protocol? > > - Would this introduce new vulnerabilities? > > In particular the latter seems problematic to me. If we were to use > control packets other than DAD to infer address ownership, how would we > prevent spoofing of those control packets? Keep in mind that, unlike > many other control packets, DAD has the nice property that it gives > the victim of a spoofing attack a chance to speak up. This increases > the bar for spoofing DAD packets. I am a bit confused here, or maybe I lack some background of previous discussions. Look to me there is a tradeoff; almost an antagonism between prefering the first binding (hence the first packet carrying this binding) and allowing nodes to defend their address. It's pretty trivial for the attacker to listen to the DAD from his victim, and answer as soon as he sees it. And then take ownership of the binding if I read you correctly. Note that many switches won't do mld snooping and simply (hardware) broadcast messages to solicited node multcast addresses to all nodes. So did this group agree that the DAD responder should have his binding preferred over the DAD sender? If so, how can this be an anti-spoofing protection mechanism? And of course, if not, DAD is broken. Unless, we assume the switch should have seen the DAD responder own DAD message earlier on (to the exception where it could have been lost).But then its the swich dending the address, not the node. . It all come back to what I described in PLBT, that is a preference algorithm for managing collisions: sometimes collision are real one, sometime they are attacks, and it's true for DAD and any other NDP messages. When receiving a DAD response carrying a different binding that the DAD request, should the switch - prefer it, and expose itself to simple DAD attack - prefer the binding of the DAD request, and expose itself to break DAD, if it missed an hypothetical earlier DAD request from this DAD responder I would strongly prefer the latter, except that the DAD responder could be behind a second switch booted long time before. Hence my proposal to prefer binding carried by DAD sender when they are directly atachedn but binding carried by DAD responder when they are attached via a second switch. Eric > > - Christian > > > From marcelo@it.uc3m.es Mon Jun 15 00:31:50 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2CB43A6BE4 for ; Mon, 15 Jun 2009 00:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.433 X-Spam-Level: X-Spam-Status: No, score=-6.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPFZwYDjfmgP for ; Mon, 15 Jun 2009 00:31:49 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 995183A67D9 for ; Mon, 15 Jun 2009 00:31:49 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp01.uc3m.es (Postfix) with ESMTP id 288A4B9FCB6; Mon, 15 Jun 2009 09:31:58 +0200 (CEST) Message-ID: <4A35F8EE.3010903@it.uc3m.es> Date: Mon, 15 Jun 2009 09:31:58 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Eric Levy-Abegnoli References: <4A2C0DFB.3040803@it.uc3m.es> <4A2D2221.4030503@cisco.com> <4A2D2739.1000206@it.uc3m.es> <4A2F9E29.5070704@cisco.com> <4A30D6CD.8060209@it.uc3m.es> <49417952-8570-467E-B312-B759DC3D88DD@ericsson.com> <4A35ECEE.7060801@cisco.com> In-Reply-To: <4A35ECEE.7060801@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16704.005 Cc: SAVI Mailing List , Christian Vogt Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 07:31:50 -0000 Eric Levy-Abegnoli escribió: > Christian , > Christian Vogt a écrit : >> Eric and Marcelo - >> >> Reading the email exchange between you two, I am making the following >> conclusions: Using control packets other than DAD to infer address >> ownership could indeed help reducing the probability of false packet >> drops. But what should be carefully evaluated is: >> >> - How much complexity would this add to the SAVI protocol? >> >> - Would this introduce new vulnerabilities? >> >> In particular the latter seems problematic to me. If we were to use >> control packets other than DAD to infer address ownership, how would we >> prevent spoofing of those control packets? Keep in mind that, unlike >> many other control packets, DAD has the nice property that it gives >> the victim of a spoofing attack a chance to speak up. This increases >> the bar for spoofing DAD packets. > I am a bit confused here, or maybe I lack some background of previous > discussions. Look to me there is a tradeoff; almost an antagonism > between prefering the first binding (hence the first packet carrying > this binding) and allowing nodes to defend their address. It's pretty > trivial for the attacker to listen to the DAD from his victim, and > answer as soon as he sees it. And then take ownership of the binding > if I read you correctly. this is an attack against DAD and not against savi I mean, if the attacker replies, what will happen is that the node will try another address and perform DAD again. In that sense, the attacker is not stealing the node's addresses since the node has not configured the address yet. > Note that many switches won't do mld snooping and simply (hardware) > broadcast messages to solicited node multcast addresses to all nodes. right > So did this group agree that the DAD responder should have his binding > preferred over the DAD sender? If so, how can this be an anti-spoofing > protection mechanism? i guess this was agreed when DAD was defined. I mean, DAD states that if a node replies the NSOL during DAD, the node performing DAD will try a different address > > And of course, if not, DAD is broken. Unless, we assume the switch > should have seen the DAD responder own DAD message earlier on (to the > exception where it could have been lost).But then its the swich > dending the address, not the node. . > It all come back to what I described in PLBT, that is a preference > algorithm for managing collisions: sometimes collision are real one, > sometime they are attacks, and it's true for DAD and any other NDP > messages. > When receiving a DAD response carrying a different binding that the > DAD request, should the switch > - prefer it, and expose itself to simple DAD attack > - prefer the binding of the DAD request, and expose itself to break > DAD, if it missed an hypothetical earlier DAD request from this DAD > responder but that would imply that DAD does no longer work, right? I mean, if the SAVI always preffer the initial NSOL of the DAD, then, if there is a colision, we are not honoring the node that originally got the address Regards, marcelo > > I would strongly prefer the latter, except that the DAD responder > could be behind a second switch booted long time before. Hence my > proposal to prefer binding carried by DAD sender when they are > directly atachedn but binding carried by DAD responder when they are > attached via a second switch. > Eric >> >> - Christian >> >> >> > > From elevyabe@cisco.com Mon Jun 15 01:05:44 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 425BE28C10B for ; Mon, 15 Jun 2009 01:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4La-Jqq-08p for ; Mon, 15 Jun 2009 01:05:43 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A4D6A3A6B16 for ; Mon, 15 Jun 2009 01:05:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,221,1243814400"; d="scan'208";a="42771278" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 15 Jun 2009 08:05:51 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5F85pDL007283; Mon, 15 Jun 2009 10:05:51 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5F85pWs002980; Mon, 15 Jun 2009 08:05:51 GMT Received: from xmb-ams-335.cisco.com ([144.254.231.80]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jun 2009 10:05:51 +0200 Received: from [144.254.53.107] ([144.254.53.107]) by xmb-ams-335.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jun 2009 10:05:50 +0200 Message-ID: <4A3600DE.2020004@cisco.com> Date: Mon, 15 Jun 2009 10:05:50 +0200 From: Eric Levy-Abegnoli User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: marcelo bagnulo braun References: <4A2C0DFB.3040803@it.uc3m.es> <4A2D2221.4030503@cisco.com> <4A2D2739.1000206@it.uc3m.es> <4A2F9E29.5070704@cisco.com> <4A30D6CD.8060209@it.uc3m.es> <49417952-8570-467E-B312-B759DC3D88DD@ericsson.com> <4A35ECEE.7060801@cisco.com> <4A35F8EE.3010903@it.uc3m.es> In-Reply-To: <4A35F8EE.3010903@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Jun 2009 08:05:50.0894 (UTC) FILETIME=[19196CE0:01C9ED90] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4287; t=1245053151; x=1245917151; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=elevyabe@cisco.com; z=From:=20Eric=20Levy-Abegnoli=20 |Subject:=20Re=3A=20[savi]=20A=20different=20trade=20off=20 for=20SAVI |Sender:=20; bh=bP0veVEFXJWXS3MwA+S/Uc30jh0ldHvv7l66YN84n3Y=; b=vDj/pfOvkbCUXrhQy1yxcKGftSMzs1jE/FNS9ulphxL/i3fGLlpnCQiCYS 0C+m3/BYgL7tvb63S+DQrP1lC/2xMgYjThcJk+6rzQnt7myJi2+0wVg1WerN vNOcyJ0+J8; Authentication-Results: ams-dkim-1; header.From=elevyabe@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: SAVI Mailing List , Christian Vogt Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 08:05:44 -0000 marcelo bagnulo braun a écrit : > Eric Levy-Abegnoli escribió: >> Christian , >> Christian Vogt a écrit : >>> Eric and Marcelo - >>> >>> Reading the email exchange between you two, I am making the following >>> conclusions: Using control packets other than DAD to infer address >>> ownership could indeed help reducing the probability of false packet >>> drops. But what should be carefully evaluated is: >>> >>> - How much complexity would this add to the SAVI protocol? >>> >>> - Would this introduce new vulnerabilities? >>> >>> In particular the latter seems problematic to me. If we were to use >>> control packets other than DAD to infer address ownership, how would we >>> prevent spoofing of those control packets? Keep in mind that, unlike >>> many other control packets, DAD has the nice property that it gives >>> the victim of a spoofing attack a chance to speak up. This increases >>> the bar for spoofing DAD packets. >> I am a bit confused here, or maybe I lack some background of previous >> discussions. Look to me there is a tradeoff; almost an antagonism >> between prefering the first binding (hence the first packet carrying >> this binding) and allowing nodes to defend their address. It's pretty >> trivial for the attacker to listen to the DAD from his victim, and >> answer as soon as he sees it. And then take ownership of the binding >> if I read you correctly. > this is an attack against DAD and not against savi > I mean, if the attacker replies, what will happen is that the node > will try another address and perform DAD again. > In that sense, the attacker is not stealing the node's addresses since > the node has not configured the address yet. This is a fairly subtil distinction that attacker will certainly exploit. Most nodes will do DAD everytime the interface got down/up, even though that is not absolutely required by the protocol. And interface go down/up pretty commonly these days, with notebooks moving around. So the switch will blindly replace its "old" binding by the one of the DAD responder? Then it will endup with an illegitimate binding. So it is also a victim, not just the end-node. > >> Note that many switches won't do mld snooping and simply (hardware) >> broadcast messages to solicited node multcast addresses to all nodes. > right > >> So did this group agree that the DAD responder should have his >> binding preferred over the DAD sender? If so, how can this be an >> anti-spoofing protection mechanism? > i guess this was agreed when DAD was defined. I mean, DAD states that > if a node replies the NSOL during DAD, the node performing DAD will > try a different address > >> >> And of course, if not, DAD is broken. Unless, we assume the switch >> should have seen the DAD responder own DAD message earlier on (to the >> exception where it could have been lost).But then its the swich >> dending the address, not the node. . >> It all come back to what I described in PLBT, that is a preference >> algorithm for managing collisions: sometimes collision are real one, >> sometime they are attacks, and it's true for DAD and any other NDP >> messages. >> When receiving a DAD response carrying a different binding that the >> DAD request, should the switch >> - prefer it, and expose itself to simple DAD attack >> - prefer the binding of the DAD request, and expose itself to break >> DAD, if it missed an hypothetical earlier DAD request from this DAD >> responder > but that would imply that DAD does no longer work, right? I mean, if > the SAVI always preffer the initial NSOL of the DAD, then, if there is > a colision, we are not honoring the node that originally got the address If we don't drop, we haven't changed DAD. If we log, we log the attacker, not the original owner. Regards, Eric > > Regards, marcelo > >> >> I would strongly prefer the latter, except that the DAD responder >> could be behind a second switch booted long time before. Hence my >> proposal to prefer binding carried by DAD sender when they are >> directly atachedn but binding carried by DAD responder when they are >> attached via a second switch. >> Eric >>> >>> - Christian >>> >>> >>> >> >> > > From yaoa02@mails.tsinghua.edu.cn Mon Jun 15 01:05:59 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0472728C10D for ; Mon, 15 Jun 2009 01:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2xSTkNvsnII for ; Mon, 15 Jun 2009 01:05:58 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id 186F53A6894 for ; Mon, 15 Jun 2009 01:05:58 -0700 (PDT) Received: from th024139.ip.tsinghua.edu.cn ([59.66.24.139] helo=yaoguangPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1MG7Cb-0000xk-S2; Mon, 15 Jun 2009 16:06:01 +0800 From: "Guang Yao" To: "'Christian Vogt'" , "'SAVI Mailing List'" References: <4BDE4243-4EAC-4D81-B827-7ED8A55787BE@ericsson.com> In-Reply-To: <4BDE4243-4EAC-4D81-B827-7ED8A55787BE@ericsson.com> Date: Mon, 15 Jun 2009 16:07:09 +0800 Message-ID: <006901c9ed90$47b64190$d722c4b0$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcntaIWQImFibqsJQlCxlG5WM5xGBwABT2Ug Content-Language: zh-cn Subject: Re: [savi] Your opinion on a different tradeoff for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 08:05:59 -0000 Though [1] presents a novel idea, I'm not in favor of it because of its lower filter capacity. Attackers are free to send packets with addresses other than local bound ones. I'm not sure that the benefit is enough to encourage administrators to deploy, especially in a big network. Local bindings always are part of all the bindings in the network, because bindings are set up through DAD snooping, and DAD NS is a group cast message, not broad cast. Thus, attackers can still spoof the address of another host as long as it is not bound on the savi device along the packet path. However, I think it is a good step to find a final solution. Regards, Guang -----Original Message----- From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Christian Vogt Sent: Monday, June 15, 2009 11:22 AM To: SAVI Mailing List Subject: [savi] Your opinion on a different tradeoff for SAVI Folks - In order to make a decision on whether or not to move forward with the modified SAVI protocol that Marcelo has proposed [1], feedback from the working group is important. Several people have already provided their feedback. I would encourage also others to share their opinion. Please do so, on this mailing list, by Friday, June 19. Thank you. - Christian [1] http://www.ietf.org/mail-archive/web/savi/current/msg00654.html From marcelo@it.uc3m.es Mon Jun 15 07:40:45 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23B4E3A6CE6 for ; Mon, 15 Jun 2009 07:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.702 X-Spam-Level: X-Spam-Status: No, score=-6.702 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2FdDC14vLrE for ; Mon, 15 Jun 2009 07:40:44 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id CF27F3A6832 for ; Mon, 15 Jun 2009 07:40:43 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (57.pool85-53-143.dynamic.orange.es [85.53.143.57]) by smtp02.uc3m.es (Postfix) with ESMTP id C83256C140E; Mon, 15 Jun 2009 16:40:17 +0200 (CEST) Message-ID: <4A365D51.2040308@it.uc3m.es> Date: Mon, 15 Jun 2009 16:40:17 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Eric Levy-Abegnoli References: <4A2C0DFB.3040803@it.uc3m.es> <4A2D2221.4030503@cisco.com> <4A2D2739.1000206@it.uc3m.es> <4A2F9E29.5070704@cisco.com> <4A30D6CD.8060209@it.uc3m.es> <49417952-8570-467E-B312-B759DC3D88DD@ericsson.com> <4A35ECEE.7060801@cisco.com> <4A35F8EE.3010903@it.uc3m.es> <4A3600DE.2020004@cisco.com> In-Reply-To: <4A3600DE.2020004@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16704.007 Cc: SAVI Mailing List , Christian Vogt Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 14:40:45 -0000 Eric Levy-Abegnoli escribió: > marcelo bagnulo braun a écrit : >> Eric Levy-Abegnoli escribió: >>> Christian , >>> Christian Vogt a écrit : >>>> Eric and Marcelo - >>>> >>>> Reading the email exchange between you two, I am making the following >>>> conclusions: Using control packets other than DAD to infer address >>>> ownership could indeed help reducing the probability of false packet >>>> drops. But what should be carefully evaluated is: >>>> >>>> - How much complexity would this add to the SAVI protocol? >>>> >>>> - Would this introduce new vulnerabilities? >>>> >>>> In particular the latter seems problematic to me. If we were to use >>>> control packets other than DAD to infer address ownership, how >>>> would we >>>> prevent spoofing of those control packets? Keep in mind that, unlike >>>> many other control packets, DAD has the nice property that it gives >>>> the victim of a spoofing attack a chance to speak up. This increases >>>> the bar for spoofing DAD packets. >>> I am a bit confused here, or maybe I lack some background of >>> previous discussions. Look to me there is a tradeoff; almost an >>> antagonism between prefering the first binding (hence the first >>> packet carrying this binding) and allowing nodes to defend their >>> address. It's pretty trivial for the attacker to listen to the DAD >>> from his victim, and answer as soon as he sees it. And then take >>> ownership of the binding if I read you correctly. >> this is an attack against DAD and not against savi >> I mean, if the attacker replies, what will happen is that the node >> will try another address and perform DAD again. >> In that sense, the attacker is not stealing the node's addresses >> since the node has not configured the address yet. > This is a fairly subtil distinction that attacker will certainly > exploit. Most nodes will do DAD everytime the interface got down/up, > even though that is not absolutely required by the protocol. but again, this is not an attack against SAVI, but an attack against DAD itself. this is not introduced nor amplified by SAVI. So, one could ask the question whether SAVI could/should do something about it. I would say that this vulnerability is well know and documented and the solution to this already exists and it is SEND > And interface go down/up pretty commonly these days, with notebooks > moving around. So the switch will blindly replace its "old" binding by > the one of the DAD responder? Then it will endup with an illegitimate > binding. So it is also a victim, not just the end-node. So, first of all, would it make sense to keep the old binding? I mean, the host that is performing DAD will not keep on using the address, cause the DAD has failed, right? So why is it useful to keep the old binding? The SAVI device could have memroy and if the binding was initially created through DAD and if now DAD fails for the same lower layer anchor, it may be likely that an attacker is attacking DAD and SAVI could react to that, but i am not sure how useful would that, since the host will not configure the address cause DAD have failed. Regards, marcelo >> >>> Note that many switches won't do mld snooping and simply (hardware) >>> broadcast messages to solicited node multcast addresses to all nodes. >> right >> >>> So did this group agree that the DAD responder should have his >>> binding preferred over the DAD sender? If so, how can this be an >>> anti-spoofing protection mechanism? >> i guess this was agreed when DAD was defined. I mean, DAD states that >> if a node replies the NSOL during DAD, the node performing DAD will >> try a different address >> >>> >>> And of course, if not, DAD is broken. Unless, we assume the switch >>> should have seen the DAD responder own DAD message earlier on (to >>> the exception where it could have been lost).But then its the swich >>> dending the address, not the node. . >>> It all come back to what I described in PLBT, that is a preference >>> algorithm for managing collisions: sometimes collision are real one, >>> sometime they are attacks, and it's true for DAD and any other NDP >>> messages. >>> When receiving a DAD response carrying a different binding that the >>> DAD request, should the switch >>> - prefer it, and expose itself to simple DAD attack >>> - prefer the binding of the DAD request, and expose itself to break >>> DAD, if it missed an hypothetical earlier DAD request from this DAD >>> responder >> but that would imply that DAD does no longer work, right? I mean, if >> the SAVI always preffer the initial NSOL of the DAD, then, if there >> is a colision, we are not honoring the node that originally got the >> address > If we don't drop, we haven't changed DAD. If we log, we log the > attacker, not the original owner. > Regards, > Eric > >> >> Regards, marcelo >> >>> >>> I would strongly prefer the latter, except that the DAD responder >>> could be behind a second switch booted long time before. Hence my >>> proposal to prefer binding carried by DAD sender when they are >>> directly atachedn but binding carried by DAD responder when they are >>> attached via a second switch. >>> Eric >>>> >>>> - Christian >>>> >>>> >>>> >>> >>> >> >> > > From marcelo@it.uc3m.es Mon Jun 15 07:50:08 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3563A6CA7 for ; Mon, 15 Jun 2009 07:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.693 X-Spam-Level: X-Spam-Status: No, score=-6.693 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdKN+E3xHTE1 for ; Mon, 15 Jun 2009 07:50:06 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 95BE33A6CCA for ; Mon, 15 Jun 2009 07:50:06 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (57.pool85-53-143.dynamic.orange.es [85.53.143.57]) by smtp01.uc3m.es (Postfix) with ESMTP id CD946B9FD7F; Mon, 15 Jun 2009 16:49:34 +0200 (CEST) Message-ID: <4A365F7E.8010302@it.uc3m.es> Date: Mon, 15 Jun 2009 16:49:34 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Guang Yao References: <4BDE4243-4EAC-4D81-B827-7ED8A55787BE@ericsson.com> <006901c9ed90$47b64190$d722c4b0$@tsinghua.edu.cn> In-Reply-To: <006901c9ed90$47b64190$d722c4b0$@tsinghua.edu.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16706.000 Cc: 'SAVI Mailing List' , 'Christian Vogt' Subject: Re: [savi] Your opinion on a different tradeoff for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 14:50:09 -0000 Guang Yao escribió: > Though [1] presents a novel idea, I'm not in favor of it because of its > lower filter capacity. > > Attackers are free to send packets with addresses other than local bound > ones. I'm not sure that the benefit is enough to encourage administrators to > deploy, especially in a big network. > > but in other solutions, the attacker can send a packet with any source address for which there is no binding by simply sending a DAD packet first, right? So, what is the new vulnerability that is being introduced? > Local bindings always are part of all the bindings in the network, because > bindings are set up through DAD snooping, and DAD NS is a group cast > message, not broad cast. Thus, attackers can still spoof the address of > another host as long as it is not bound on the savi device along the packet > path. > right, but we can change that. I mean, we could simply require that SAVI devices snoop all MLD messages and that DAD packets are forwarded to all SAVI devices irrespectively whether there any host subscribed tot he particular solicited node mcast group on that particular SAVI device. That would essentially imply that all SAVI devices receive all DAD msgs. Would that solve the problem? Regards, marcelo > However, I think it is a good step to find a final solution. > > Regards, > Guang > -----Original Message----- > From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of > Christian Vogt > Sent: Monday, June 15, 2009 11:22 AM > To: SAVI Mailing List > Subject: [savi] Your opinion on a different tradeoff for SAVI > > Folks - > > In order to make a decision on whether or not to move forward with the > modified SAVI protocol that Marcelo has proposed [1], feedback from the > working group is important. Several people have already provided their > feedback. I would encourage also others to share their opinion. Please do > so, on this mailing list, by Friday, June 19. > > Thank you. > > - Christian > > [1] http://www.ietf.org/mail-archive/web/savi/current/msg00654.html > > > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > > From marcelo@it.uc3m.es Mon Jun 15 08:04:16 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AD5F3A67A1 for ; Mon, 15 Jun 2009 08:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.086 X-Spam-Level: X-Spam-Status: No, score=-6.086 tagged_above=-999 required=5 tests=[AWL=-0.687, BAYES_00=-2.599, J_CHICKENPOX_61=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+DmxO2vxEI3 for ; Mon, 15 Jun 2009 08:04:14 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 6445A28C0E2 for ; Mon, 15 Jun 2009 08:04:14 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (57.pool85-53-143.dynamic.orange.es [85.53.143.57]) by smtp02.uc3m.es (Postfix) with ESMTP id 2F82D6BA2C9; Mon, 15 Jun 2009 17:04:20 +0200 (CEST) Message-ID: <4A3662F3.3070105@it.uc3m.es> Date: Mon, 15 Jun 2009 17:04:19 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jun Bi References: <59D15025-814F-4967-84EC-50FCA0225CC1@cisco.com> <4A2C110A.6090602@it.uc3m.es> <73C3E864932143928B3A8333ABAA1DA5@userPC> In-Reply-To: <73C3E864932143928B3A8333ABAA1DA5@userPC> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16706.000 Cc: SAVI Mailing List Subject: Re: [savi] forwarding datagrams without bindings X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 15:04:16 -0000 Jun Bi escribió: > We carefully discussed the default forwarding, we have some > considerations: > > 1 > Default forwarding will make the attacker easy to use it to launch > spoofing packets: > 1) When the SAVI switch directly attached to the source host lost DAD > (a very low possibility case, CPS need to be enhanced in this case), > both legal user and attacker under the same SAVI switch could send > packets. sure, So the options here are either we log the occurence of these packets, or we create a binding with a data packet (the first data packet) It is perfectly ok to create a binding with the data packet. The question at this point is how do you deal with the usage fo this address in other switches. One option would be to introduce some form of SAVI protocol. None of us like this, but, maybe the only way out. The other option would be to keep this binding information only to this switch and we don't care if the address is used in other switch. That would allow the usage of the same soruce address in another switech, but not in the same switch. this woudl provide some additional level of protection without the complexity of a savi protocol. (not full protection though) > 2) Even the SAVI switch directly attached to the source host get the > DAD (the most usual case, and CPS works perfectly in this case), other > switches in the same link may still lost the DAD (due to the DAD > multicasting mechanism, it's not a low possibility case. I understnad you are referring to the case the SAVI device does not has any host subscribed to the the particular sol mcst group? It would be possible to require that all DAD msgs are forwarded to all the SAVI devices, even if there is no host subscribed to them > Another reason is the link distance increasing brings more possibility > to lost packets). Which means, host under other switches in the same > link may don't have the binding. Then becaue of the default forwarding > rule, attackers under those switches could send spoofing packets out. > > So that's the shortcomings of default forwarding (decrease the > security level),then it doesn't meet the goal of SAVI and I also don't > think the users will like it. > the problem with default discarding, unless DAD is received is that hosts are disconnected from the network if the DAD packet is lost. > 2 > I think SAVI device should bring more security, > so the default action should be dropping packets before binding is set > up. > Today, every 802.1x device will drop packets without passing > authentication,and we didn't see any problem. > So the default dropping is OK for users. > note that authentication exchanges are designed to be reliable and hosts retry until it works. this is not the case of DAD, it simply has not been designed that way > The requirement of default dropping is actually how to make the > binding more accurate. > The only problem of CPS is that some DAD packet may be lost in the > directly attached SAVI switch (in a very low possibility). > A easy way to fix it is to make DAD redundant (like what IPv4 did, > requires sending 3 packets,which is easy to be implemented). > Certainly, we could find other way to enhance DAD. Any idea is welcomed. you would need to change the hosts and this is clearly out of the scope for savi regards, marcelo > Anyway, I think default dropping will be the right approach (to meet > the goal of SAVI and anti-spoofing). > > thanks, > Jun Bi > > > ----- Original Message ----- From: "marcelo bagnulo braun" > > To: "Fred Baker" > Cc: "SAVI Mailing List" > Sent: Monday, June 08, 2009 3:12 AM > Subject: Re: [savi] forwarding datagrams without bindings > > > FWIW, i think it is very important to understand the security > implications of this alternative approach. I am not sure i understnad > the implications myself, so, this dicussion is useful for that purpose. > > Fred Baker escribió: >> Marcelo will, when he gets a few minutes (he is traveling this week), >> flesh out the idea that he discussed on the call this morning. While >> I'm thinking about it, I would like to summarize the thought and the >> question that was running through my head. >> >> The discussion related to whether we should set up SAVI bindings >> using FCFS only on control datagrams or also on data exchanges. He >> suggested that we only set up binding state on control packets but >> that we permit data packets that correspond to no binding (eg, from >> is an address that nobody in the LAN is known to be using) to pass. >> >> My question goes to the heart of what we are trying to do here. It >> seems to me that SAVI is trying, ultimately, to guarantee that if one >> system sends a datagram to another system, the second system's reply >> will make it back to the first system barring system or network >> failure. Address spoofing is the obvious attack that we have been >> trying to prevent - the use of a source address such that A sends to >> B and B's reply is delivered to some third party. > I am not sure how this could happen with the proposed approach, since > the attacker cannot use the address of a real host, since the real host > would normally had perform DAD, so a binding would exist in the SAVI > device, so packets coming from the attacker with that address would be > drop. >> But it seems to me that address anonymization is also an attack that >> the technology is trying to prevent - if A sends to B, B might reply >> but the network be systemically unable to deliver it and the original >> source of the datagram is not determinable. > not dropping the packet doesn't mean that the SAVI device cannot log the > occurrence of such data packet,s which would allow to trace back to the > lower anchor of those packets. > >> In short, I think SAVI is trying to do more than "prevent spoofing", >> it is trying to ensure that datagrams in the wild are valid and >> useful as opposed to being attack traffic. To do that, the point is >> not the negative statement that "it doesn't spoof someone else's >> address", the point is the positive statement that "it uses its own >> address". >> >> To make that positive statement, whether we set up bindings on >> control or data packets, we can only allow datagrams to pass that >> originate from addresses that are associated with the putative >> sender, apart from systems that routinely originate datagrams at L2 >> from other L3 addresses, such as routers do. >> >> >> In case what I just said is not clear, let me put together an attack >> example. We often see DDOS attacks in which some large number of >> systems simultaneously send a datagram to some targeted address using >> a random source address. To track these back, what operations folks >> try to do is track the trajectory of those attacking datagrams. The >> effectiveness of the attack is limited by BCP 38 filters (uRPF or >> whatever), which only allow packets through for which the random >> number in fact selected the right source prefix. But in IPv6, >> selecting the right /64 still means one has 2^64 interface >> identifiers to choose from, and that the probability of randomly >> selecting that of a neighbor is pretty low. So while preventing >> address spoofing is an obvious goal, simply doing that doesn't >> prevent attacks in which the source address is incorrect; one also >> has to prevent address anonymization. > I fail to see why these attacking hosts would simply do the DAD for the > addresses they want to use and get access to the savi filters by doing > so. > I mean, if you have a solution that drops packets if there is no > binding, then the attacker simply needs to perform the DAD , create the > binding and then send the packets (which would be the easier thing to > do, cause that is what OS do by default) > >> >> >> Which brings us back to the question of address binding. If what we >> are doing is preventing systems from sending from addresses that are >> not their own, > > So, there are 2 types of addresses in a link. the addresses that already > belong to a host and the addresses that don't belong to anyone. > The proposed approach of forwarding packets wihtout bindings prevents > the attacker to use the address of other hosts. > What the proposed approach doens't do is to prevent an attacker to use > addresses that do not belong to any host. But, if they do not belong to > nay host, the attacker can simply perform DAD and create the binding and > own the address. So, what is that we are missing form the security > perspective in this appraoch? > > Regards, marcelo > > >> then there is no real question of interoperating with non-SAVI >> switches in other parts of the network. SAVI switches somehow know >> which ports connect to hosts (as opposed to routers, switch/switch >> trunks, and some kinds of servers), and drop datagrams they send that >> are not from addresses bound to them. If one wants to have a SAVI >> network, one doesn't try to be backward compatible with non-SAVI >> equipment, one replaces non-SAVI equipment with SAVI equipment, >> hopefully by an upgrade for large switches, but for consumer grade >> equipment by replacing it. The one case where that does not follow is >> a desktop switch, in which the larger switch may not be able to >> distinguish between a virtual host and a set of hosts connected by a >> 5 port potentially-non-SAVI switch and that to the wall; there, the >> big switch might associate IPv6 addresses with MAC Addresses and >> those in turn with a port. >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > > > > From xiayangsong@huawei.com Mon Jun 15 08:41:35 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89B573A6A4D for ; Mon, 15 Jun 2009 08:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[AWL=0.719, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrgG0IrFSaQY for ; Mon, 15 Jun 2009 08:41:34 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2828F3A6A21 for ; Mon, 15 Jun 2009 08:41:34 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLA000IIE9I5U@szxga04-in.huawei.com> for savi@ietf.org; Mon, 15 Jun 2009 23:41:42 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLA009SKE9IY2@szxga04-in.huawei.com> for savi@ietf.org; Mon, 15 Jun 2009 23:41:42 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLA00D2CE9GP6@szxml06-in.huawei.com> for savi@ietf.org; Mon, 15 Jun 2009 23:41:42 +0800 (CST) Date: Mon, 15 Jun 2009 10:41:39 -0500 From: Frank Xia To: marcelo bagnulo braun , SAVI Mailing List Message-id: <00e301c9edcf$c7cc7bd0$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4A2C0DFB.3040803@it.uc3m.es> Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 15:41:35 -0000 Hi Marcelo Please check my inline comments. BR Frank ----- Original Message ----- From: "marcelo bagnulo braun" To: "SAVI Mailing List" Sent: Sunday, June 07, 2009 1:59 PM Subject: [savi] A different trade off for SAVI > Over the last few weeks, we have been discussing different approaches > for SAVI to be used in conjunction IPv6 stateless address > autconfiguration. > the different proposed approaches have different pros and cons, due to > different tradeoffs being made. > In this email, i describe an intermediate approach that may be worth > to be considered. > > So, i will first try to summarize the design questions that we have > been considering. > The first question is whether we create bindings using only DAD packets > or we also create bindings using data packet. > Creating bindings only with DAD packets, imposes the questions about > what can be done when a packets with a source address for which there > is no binding. > One option would be discard the packet. The problem with this approach > is that legitimate packets can be drop. In particular, DAD is not a > reliable protocol, so it is possible that DAD packets are lost and > do not reach the SAVI device. Similarly, it is also possible that a > SAVI device reboots, which would imply that the bindings are lost and > since the host may not perform the DAD again, legitimate packets would > be lost. > It is important to quantify this risk. In my personal opinion, the risk > is high enough that i am not comfortable designing a SAVI solution > that will discard legitimate packets. OTOH, it is likely that in an > important number of cases, the DAD messages are actually delivered and > the SAVI device creates the binding using them. Frank=>IMHO, DAD only is not feasible. DAD procedure in IPv6 operation is only a SHOULD, not a MUST. > > So, we return to the initial question about what do we do with data > packets containing a source address for which there is no binding. Frank=>I propose that SAVI devices manipulate ND protocol to establish a binding triggered by the data packets. > As i mentioned, the other option is to create a binding. The drawback of > that approach is that we need to distribute the binding information > to the other SAVI devices, so that the configure the binding. (I am > here assuming that the DAD messages are in general distributed to all > the SAVI devices in the link. In order to do so, we need to require > that the SAVI devices receive the packets for all solicited nodes > multicast groups, but i understand this is feasible). So, it seems > than that in order to distribute the bindings created by the corner case > that the DAD packet is lost, we need to require the usage of a SAVI > protocol to exchange binding data. Frank=>Distributing of SAVI states among switches seems to introduce extra complexity to switchs. However, if we try to do so, probably we can consider that rotuers distribute the information to switchs. I assume routers have authorative binding information. > > If we don't think that discarding them is acceptable and we > think that creating a SAVI protocol is an overkill for supporting the > case where the DAD packets were lost, we may want to consider a middle > ground option. > > An intermediate option would be to simply forward (and eventually log) > data packets with source address for which there is no binding. Frank=>This is not helpful. Operators are now in the middle of alarm sea. There are too many alarms to handle. We just offload our due work to our miserable maintenance colleagues :-) > > So, let me expand on this. The behaviour of this approach would be: > If DAD exchange is detected by the SAVI device, a binding is created. > > If a data packet containing a source address for which a binding exists > and the same lower layer anchor is received, then the packet is forwarded. > > If a data packet containing a source address for which a binding exists > and a different lower layer anchor is received, then the packet is drop. > > If a data packet containing a source address for which no binding exists > the data packet is forwarded and optionally logged. > > So what are the security properties of such a solution? Frank=>Logging flood could be exploited by malicious people for attacking. > > If a host starts using an address and performs the DAD procedure, then > no other host can use its address as a source address in data packets. > > An attacker can start using an address for which there is no binding. > In order for this address to be the address of another host, this > can only happen if the DAD packet was lost. I am not sure how concerned Frank=>Rogue hosts could deliberately ignor DAD procedure. > should we be about preventing this from attackers that have the > capability of disturbing DAD, I mean, if they are able to do that, > i guess they can launch worse attacks than spoof a source address. Frank=>I agree this philosophy. It is not necessary for us to have a perfect SAVI solution to deal with all the threats. At the same time, I prefer letting packet pass if we could not decide if it is a legitimate packet. > An attacker can use a given address from different lower layer anchors. > I am not sure why this would be an attack though. As i said earlier > it would be possible for the SAVI device to log the occurrence of these > packets and allow to trace back to the lower layer anchor. > > So, this option seems like a middle ground option with a somehow reduced > level of security but with a low level of complexity and without > the possibility of disturbing the network behaviour by discarding > legitimate packets. > > Comments? > > Regards, marcelo > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From marcelo@it.uc3m.es Mon Jun 15 09:02:09 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B032F28C179 for ; Mon, 15 Jun 2009 09:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.637 X-Spam-Level: X-Spam-Status: No, score=-6.637 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIJA03hoq9oX for ; Mon, 15 Jun 2009 09:02:08 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 1B61E28C0E2 for ; Mon, 15 Jun 2009 09:02:08 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (204.pool85-53-133.dynamic.orange.es [85.53.133.204]) by smtp01.uc3m.es (Postfix) with ESMTP id E7FFBBA528A; Mon, 15 Jun 2009 18:01:49 +0200 (CEST) Message-ID: <4A36706D.9050501@it.uc3m.es> Date: Mon, 15 Jun 2009 18:01:49 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Frank Xia References: <4A2C0DFB.3040803@it.uc3m.es> <00e301c9edcf$c7cc7bd0$3e0c7c0a@china.huawei.com> In-Reply-To: <00e301c9edcf$c7cc7bd0$3e0c7c0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16706.000 Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 16:02:09 -0000 Frank Xia escribió: > Hi Marcelo > > Please check my inline comments. > > BR > Frank > > ----- Original Message ----- From: "marcelo bagnulo braun" > > To: "SAVI Mailing List" > Sent: Sunday, June 07, 2009 1:59 PM > Subject: [savi] A different trade off for SAVI > > >> Over the last few weeks, we have been discussing different approaches >> for SAVI to be used in conjunction IPv6 stateless address >> autconfiguration. >> the different proposed approaches have different pros and cons, due to >> different tradeoffs being made. >> In this email, i describe an intermediate approach that may be worth >> to be considered. >> >> So, i will first try to summarize the design questions that we have >> been considering. >> The first question is whether we create bindings using only DAD packets >> or we also create bindings using data packet. >> Creating bindings only with DAD packets, imposes the questions about >> what can be done when a packets with a source address for which there >> is no binding. >> One option would be discard the packet. The problem with this approach >> is that legitimate packets can be drop. In particular, DAD is not a >> reliable protocol, so it is possible that DAD packets are lost and >> do not reach the SAVI device. Similarly, it is also possible that a >> SAVI device reboots, which would imply that the bindings are lost and >> since the host may not perform the DAD again, legitimate packets would >> be lost. >> It is important to quantify this risk. In my personal opinion, the risk >> is high enough that i am not comfortable designing a SAVI solution >> that will discard legitimate packets. OTOH, it is likely that in an >> important number of cases, the DAD messages are actually delivered and >> the SAVI device creates the binding using them. > > Frank=>IMHO, DAD only is not feasible. DAD procedure in IPv6 > operation is only a SHOULD, not a MUST. I am kind of confused here. DAD is a MUST for stateless address autoconf My problem is that DAD packet may get lost, are we talking about the same thing here or not? > > >> >> So, we return to the initial question about what do we do with data >> packets containing a source address for which there is no binding. > > > Frank=>I propose that SAVI devices manipulate ND protocol > to establish a binding triggered by the data packets. > you mean other ND msgs than DAD? which ones? >> As i mentioned, the other option is to create a binding. The drawback of >> that approach is that we need to distribute the binding information >> to the other SAVI devices, so that the configure the binding. (I am >> here assuming that the DAD messages are in general distributed to all >> the SAVI devices in the link. In order to do so, we need to require >> that the SAVI devices receive the packets for all solicited nodes >> multicast groups, but i understand this is feasible). So, it seems >> than that in order to distribute the bindings created by the corner case >> that the DAD packet is lost, we need to require the usage of a SAVI >> protocol to exchange binding data. > Frank=>Distributing of SAVI states among switches > seems to introduce extra complexity to switchs. However, if we try to > do so, probably we can consider that rotuers distribute > the information to switchs. I assume routers have authorative > binding information. how come the routers have the auhtoritative information? > >> >> If we don't think that discarding them is acceptable and we >> think that creating a SAVI protocol is an overkill for supporting the >> case where the DAD packets were lost, we may want to consider a middle >> ground option. >> >> An intermediate option would be to simply forward (and eventually log) >> data packets with source address for which there is no binding. > Frank=>This is not helpful. Operators are now in the middle of alarm > sea. > There are too many alarms to handle. the goal of this would not be to trigger an alram but to allow to trace back the lower layer anchor in case the packet was used in an attack. > We just offload our due work to our > miserable maintenance colleagues :-) > >> >> So, let me expand on this. The behaviour of this approach would be: >> If DAD exchange is detected by the SAVI device, a binding is created. >> >> If a data packet containing a source address for which a binding exists >> and the same lower layer anchor is received, then the packet is >> forwarded. >> >> If a data packet containing a source address for which a binding exists >> and a different lower layer anchor is received, then the packet is drop. >> >> If a data packet containing a source address for which no binding exists >> the data packet is forwarded and optionally logged. >> >> So what are the security properties of such a solution? > Frank=>Logging flood could be exploited by malicious people > for attacking. > sure, but i am not sure i see any other way to allow tracking back attacks... >> >> If a host starts using an address and performs the DAD procedure, then >> no other host can use its address as a source address in data packets. >> >> An attacker can start using an address for which there is no binding. >> In order for this address to be the address of another host, this >> can only happen if the DAD packet was lost. I am not sure how concerned > Frank=>Rogue hosts could deliberately ignor DAD procedure. > so? what woudl the impact of this? >> should we be about preventing this from attackers that have the >> capability of disturbing DAD, I mean, if they are able to do that, >> i guess they can launch worse attacks than spoof a source address. > Frank=>I agree this philosophy. It is not necessary for us to have a > perfect SAVI solution to deal with all the threats. At the same time, > I prefer letting packet pass if we could not decide if it is a legitimate > packet. > good regards, marcelo >> An attacker can use a given address from different lower layer anchors. >> I am not sure why this would be an attack though. As i said earlier >> it would be possible for the SAVI device to log the occurrence of these >> packets and allow to trace back to the lower layer anchor. >> >> So, this option seems like a middle ground option with a somehow reduced >> level of security but with a low level of complexity and without >> the possibility of disturbing the network behaviour by discarding >> legitimate packets. >> >> Comments? >> >> Regards, marcelo >> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi > > From elevyabe@cisco.com Mon Jun 15 09:32:27 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99EC53A6D02 for ; Mon, 15 Jun 2009 09:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWan94kTiYZL for ; Mon, 15 Jun 2009 09:32:26 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id F2A223A6D1B for ; Mon, 15 Jun 2009 09:32:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,223,1243814400"; d="scan'208";a="42846553" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 15 Jun 2009 16:32:35 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5FGWZWP031551; Mon, 15 Jun 2009 18:32:35 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5FGWZIH029672; Mon, 15 Jun 2009 16:32:35 GMT Received: from xmb-ams-335.cisco.com ([144.254.231.80]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jun 2009 18:32:34 +0200 Received: from [144.254.53.107] ([144.254.53.107]) by xmb-ams-335.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jun 2009 18:32:34 +0200 Message-ID: <4A3677A1.3070805@cisco.com> Date: Mon, 15 Jun 2009 18:32:33 +0200 From: Eric Levy-Abegnoli User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: marcelo bagnulo braun References: <4A2C0DFB.3040803@it.uc3m.es> <4A2D2221.4030503@cisco.com> <4A2D2739.1000206@it.uc3m.es> <4A2F9E29.5070704@cisco.com> <4A30D6CD.8060209@it.uc3m.es> <49417952-8570-467E-B312-B759DC3D88DD@ericsson.com> <4A35ECEE.7060801@cisco.com> <4A35F8EE.3010903@it.uc3m.es> <4A3600DE.2020004@cisco.com> <4A365D51.2040308@it.uc3m.es> In-Reply-To: <4A365D51.2040308@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Jun 2009 16:32:34.0683 (UTC) FILETIME=[E32B74B0:01C9EDD6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6337; t=1245083555; x=1245947555; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=elevyabe@cisco.com; z=From:=20Eric=20Levy-Abegnoli=20 |Subject:=20Re=3A=20[savi]=20A=20different=20trade=20off=20 for=20SAVI |Sender:=20; bh=89Y50NRrDwZNBa3+eTg+KSWneBw/zyfBVdRMfXwJtjU=; b=kOXqw2xNOFzadxxrh9uUs/OYzfKgsujj7L5AGJgbbdexzJQTtW1t195I6O 5Gdvh2+rsg3y7kTsnVg02EOXjkIzcYzGAkokRHLs0xb89kVC6al3FQ+n47Ee 2YPjMwxECt; Authentication-Results: ams-dkim-1; header.From=elevyabe@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: SAVI Mailing List , Christian Vogt Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 16:32:27 -0000 marcelo bagnulo braun a écrit : > Eric Levy-Abegnoli escribió: >> marcelo bagnulo braun a écrit : >>> Eric Levy-Abegnoli escribió: >>>> Christian , >>>> Christian Vogt a écrit : >>>>> Eric and Marcelo - >>>>> >>>>> Reading the email exchange between you two, I am making the following >>>>> conclusions: Using control packets other than DAD to infer address >>>>> ownership could indeed help reducing the probability of false packet >>>>> drops. But what should be carefully evaluated is: >>>>> >>>>> - How much complexity would this add to the SAVI protocol? >>>>> >>>>> - Would this introduce new vulnerabilities? >>>>> >>>>> In particular the latter seems problematic to me. If we were to use >>>>> control packets other than DAD to infer address ownership, how >>>>> would we >>>>> prevent spoofing of those control packets? Keep in mind that, unlike >>>>> many other control packets, DAD has the nice property that it gives >>>>> the victim of a spoofing attack a chance to speak up. This increases >>>>> the bar for spoofing DAD packets. >>>> I am a bit confused here, or maybe I lack some background of >>>> previous discussions. Look to me there is a tradeoff; almost an >>>> antagonism between prefering the first binding (hence the first >>>> packet carrying this binding) and allowing nodes to defend their >>>> address. It's pretty trivial for the attacker to listen to the DAD >>>> from his victim, and answer as soon as he sees it. And then take >>>> ownership of the binding if I read you correctly. >>> this is an attack against DAD and not against savi >>> I mean, if the attacker replies, what will happen is that the node >>> will try another address and perform DAD again. >>> In that sense, the attacker is not stealing the node's addresses >>> since the node has not configured the address yet. >> This is a fairly subtil distinction that attacker will certainly >> exploit. Most nodes will do DAD everytime the interface got down/up, >> even though that is not absolutely required by the protocol. > but again, this is not an attack against SAVI, but an attack against > DAD itself. this is not introduced nor amplified by SAVI. > So, one could ask the question whether SAVI could/should do something > about it. > I would say that this vulnerability is well know and documented and > the solution to this already exists and it is SEND I think SAVI has the opportunity to provide some benefits (SeND based whenever applicable) comparable to SeND, but protecting the entire community of nodes on the link at once. Including those with no SeND. > >> And interface go down/up pretty commonly these days, with notebooks >> moving around. So the switch will blindly replace its "old" binding >> by the one of the DAD responder? Then it will endup with an >> illegitimate binding. So it is also a victim, not just the end-node. > So, first of all, would it make sense to keep the old binding? > I mean, the host that is performing DAD will not keep on using the > address, cause the DAD has failed, right? So why is it useful to keep > the old binding? If an attacker can so easlily put its own binding into the table (for instance sending a DAD message every X seconds until one is installed because the original owner has gone), then the switch become no more than a registration chamber. With nothing to say about who is good and who is bad. I think we have a fundamental difference on the goals. I think that the switch should make decisions on what gets in (the binding table) and what does not, as well as how long it stays there, not fully coupled with end-nodes view. (I don't mean not_coupled). regards Eric > > The SAVI device could have memroy and if the binding was initially > created through DAD and if now DAD fails for the same lower layer > anchor, it may be likely that an attacker is attacking DAD and SAVI > could react to that, but i am not sure how useful would that, since > the host will not configure the address cause DAD have failed. > > Regards, marcelo > > >>> >>>> Note that many switches won't do mld snooping and simply (hardware) >>>> broadcast messages to solicited node multcast addresses to all nodes. >>> right >>> >>>> So did this group agree that the DAD responder should have his >>>> binding preferred over the DAD sender? If so, how can this be an >>>> anti-spoofing protection mechanism? >>> i guess this was agreed when DAD was defined. I mean, DAD states >>> that if a node replies the NSOL during DAD, the node performing DAD >>> will try a different address >>> >>>> >>>> And of course, if not, DAD is broken. Unless, we assume the switch >>>> should have seen the DAD responder own DAD message earlier on (to >>>> the exception where it could have been lost).But then its the swich >>>> dending the address, not the node. . >>>> It all come back to what I described in PLBT, that is a preference >>>> algorithm for managing collisions: sometimes collision are real >>>> one, sometime they are attacks, and it's true for DAD and any other >>>> NDP messages. >>>> When receiving a DAD response carrying a different binding that the >>>> DAD request, should the switch >>>> - prefer it, and expose itself to simple DAD attack >>>> - prefer the binding of the DAD request, and expose itself to break >>>> DAD, if it missed an hypothetical earlier DAD request from this >>>> DAD responder >>> but that would imply that DAD does no longer work, right? I mean, if >>> the SAVI always preffer the initial NSOL of the DAD, then, if there >>> is a colision, we are not honoring the node that originally got the >>> address >> If we don't drop, we haven't changed DAD. If we log, we log the >> attacker, not the original owner. >> Regards, >> Eric >> >>> >>> Regards, marcelo >>> >>>> >>>> I would strongly prefer the latter, except that the DAD responder >>>> could be behind a second switch booted long time before. Hence my >>>> proposal to prefer binding carried by DAD sender when they are >>>> directly atachedn but binding carried by DAD responder when they >>>> are attached via a second switch. >>>> Eric >>>>> >>>>> - Christian >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > From xiayangsong@huawei.com Mon Jun 15 10:02:12 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91F2E28C110 for ; Mon, 15 Jun 2009 10:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.008 X-Spam-Level: X-Spam-Status: No, score=-1.008 tagged_above=-999 required=5 tests=[AWL=-0.513, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaKd31GwlZuf for ; Mon, 15 Jun 2009 10:02:11 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 212C53A6784 for ; Mon, 15 Jun 2009 10:02:11 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLA007G4HZD3D@szxga01-in.huawei.com> for savi@ietf.org; Tue, 16 Jun 2009 01:02:01 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLA001B1HZCU8@szxga01-in.huawei.com> for savi@ietf.org; Tue, 16 Jun 2009 01:02:00 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLA002N3HZ6V1@szxml04-in.huawei.com> for savi@ietf.org; Tue, 16 Jun 2009 01:02:00 +0800 (CST) Date: Mon, 15 Jun 2009 12:01:54 -0500 From: Frank Xia To: marcelo bagnulo braun Message-id: <001901c9edda$ff5bceb0$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 8BIT X-Priority: 3 X-MSMail-priority: Normal References: <4A2C0DFB.3040803@it.uc3m.es> <00e301c9edcf$c7cc7bd0$3e0c7c0a@china.huawei.com> <4A36706D.9050501@it.uc3m.es> Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 17:02:12 -0000 Hi Marcelo Please check again... BR Frank ----- Original Message ----- From: "marcelo bagnulo braun" To: "Frank Xia" Cc: "SAVI Mailing List" Sent: Monday, June 15, 2009 11:01 AM Subject: Re: [savi] A different trade off for SAVI Frank Xia escribió: > Hi Marcelo > > Please check my inline comments. > > BR > Frank > > ----- Original Message ----- From: "marcelo bagnulo braun" > > To: "SAVI Mailing List" > Sent: Sunday, June 07, 2009 1:59 PM > Subject: [savi] A different trade off for SAVI > > >> Over the last few weeks, we have been discussing different approaches >> for SAVI to be used in conjunction IPv6 stateless address >> autconfiguration. >> the different proposed approaches have different pros and cons, due to >> different tradeoffs being made. >> In this email, i describe an intermediate approach that may be worth >> to be considered. >> >> So, i will first try to summarize the design questions that we have >> been considering. >> The first question is whether we create bindings using only DAD packets >> or we also create bindings using data packet. >> Creating bindings only with DAD packets, imposes the questions about >> what can be done when a packets with a source address for which there >> is no binding. >> One option would be discard the packet. The problem with this approach >> is that legitimate packets can be drop. In particular, DAD is not a >> reliable protocol, so it is possible that DAD packets are lost and >> do not reach the SAVI device. Similarly, it is also possible that a >> SAVI device reboots, which would imply that the bindings are lost and >> since the host may not perform the DAD again, legitimate packets would >> be lost. >> It is important to quantify this risk. In my personal opinion, the risk >> is high enough that i am not comfortable designing a SAVI solution >> that will discard legitimate packets. OTOH, it is likely that in an >> important number of cases, the DAD messages are actually delivered and >> the SAVI device creates the binding using them. > > Frank=>IMHO, DAD only is not feasible. DAD procedure in IPv6 > operation is only a SHOULD, not a MUST. I am kind of confused here. DAD is a MUST for stateless address autoconf My problem is that DAD packet may get lost, are we talking about the same thing here or not? Frank=>DAD is NOT a MUST for stateless address configuration. RFC 4862 reads " By default, all addresses should be tested for uniqueness prior to their assignment to an interface for safety. The test should individually be performed on all addresses obtained manually, via stateless address autoconfiguration, or via DHCPv6. To accommodate sites that believe the overhead of performing Duplicate Address Detection outweighs its benefits, the use of Duplicate Address Detection can be disabled through the administrative setting of a per-interface configuration flag." > > >> >> So, we return to the initial question about what do we do with data >> packets containing a source address for which there is no binding. > > > Frank=>I propose that SAVI devices manipulate ND protocol > to establish a binding triggered by the data packets. > you mean other ND msgs than DAD? which ones? Frank=>DAD is not a message but a procedure which includes NS and NA. SAVI device acting as a host initiates NS message for the target host to build or verify binding states which are built by FCFS. It seems to be complementary to FCFS. >> As i mentioned, the other option is to create a binding. The drawback of >> that approach is that we need to distribute the binding information >> to the other SAVI devices, so that the configure the binding. (I am >> here assuming that the DAD messages are in general distributed to all >> the SAVI devices in the link. In order to do so, we need to require >> that the SAVI devices receive the packets for all solicited nodes >> multicast groups, but i understand this is feasible). So, it seems >> than that in order to distribute the bindings created by the corner case >> that the DAD packet is lost, we need to require the usage of a SAVI >> protocol to exchange binding data. > Frank=>Distributing of SAVI states among switches > seems to introduce extra complexity to switchs. However, if we try to > do so, probably we can consider that rotuers distribute > the information to switchs. I assume routers have authorative > binding information. how come the routers have the auhtoritative information? Frank=>An access router is an edge between layer 2 network layer 3 network. Access router is responsible for address configuration of host, and relates the corresponding layer 2 information to the the host. IMHO, there is no any necessary work to do if we try to build SAVI state in an access router. ALL the DAD/DHCP snooping work is on switchs not routers. > >> >> If we don't think that discarding them is acceptable and we >> think that creating a SAVI protocol is an overkill for supporting the >> case where the DAD packets were lost, we may want to consider a middle >> ground option. >> >> An intermediate option would be to simply forward (and eventually log) >> data packets with source address for which there is no binding. > Frank=>This is not helpful. Operators are now in the middle of alarm sea. > There are too many alarms to handle. the goal of this would not be to trigger an alram but to allow to trace back the lower layer anchor in case the packet was used in an attack. > We just offload our due work to our > miserable maintenance colleagues :-) > >> >> So, let me expand on this. The behaviour of this approach would be: >> If DAD exchange is detected by the SAVI device, a binding is created. >> >> If a data packet containing a source address for which a binding exists >> and the same lower layer anchor is received, then the packet is >> forwarded. >> >> If a data packet containing a source address for which a binding exists >> and a different lower layer anchor is received, then the packet is drop. >> >> If a data packet containing a source address for which no binding exists >> the data packet is forwarded and optionally logged. >> >> So what are the security properties of such a solution? > Frank=>Logging flood could be exploited by malicious people > for attacking. > sure, but i am not sure i see any other way to allow tracking back attacks... >> >> If a host starts using an address and performs the DAD procedure, then >> no other host can use its address as a source address in data packets. >> >> An attacker can start using an address for which there is no binding. >> In order for this address to be the address of another host, this >> can only happen if the DAD packet was lost. I am not sure how concerned > Frank=>Rogue hosts could deliberately ignor DAD procedure. > so? what woudl the impact of this? Frank=>Just a deliberate attack. >> should we be about preventing this from attackers that have the >> capability of disturbing DAD, I mean, if they are able to do that, >> i guess they can launch worse attacks than spoof a source address. > Frank=>I agree this philosophy. It is not necessary for us to have a > perfect SAVI solution to deal with all the threats. At the same time, > I prefer letting packet pass if we could not decide if it is a legitimate > packet. > good regards, marcelo >> An attacker can use a given address from different lower layer anchors. >> I am not sure why this would be an attack though. As i said earlier >> it would be possible for the SAVI device to log the occurrence of these >> packets and allow to trace back to the lower layer anchor. >> >> So, this option seems like a middle ground option with a somehow reduced >> level of security but with a low level of complexity and without >> the possibility of disturbing the network behaviour by discarding >> legitimate packets. >> >> Comments? >> >> Regards, marcelo >> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi > > _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi From marcelo@it.uc3m.es Mon Jun 15 11:56:17 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CAC83A6D0E for ; Mon, 15 Jun 2009 11:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.634 X-Spam-Level: X-Spam-Status: No, score=-6.634 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhUcIB47Inoh for ; Mon, 15 Jun 2009 11:56:15 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 70DDE3A6A07 for ; Mon, 15 Jun 2009 11:56:15 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (204.pool85-53-133.dynamic.orange.es [85.53.133.204]) by smtp01.uc3m.es (Postfix) with ESMTP id 105ABB9FD81; Mon, 15 Jun 2009 20:55:39 +0200 (CEST) Message-ID: <4A36992A.9010904@it.uc3m.es> Date: Mon, 15 Jun 2009 20:55:38 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Frank Xia References: <4A2C0DFB.3040803@it.uc3m.es> <00e301c9edcf$c7cc7bd0$3e0c7c0a@china.huawei.com> <4A36706D.9050501@it.uc3m.es> <001901c9edda$ff5bceb0$3e0c7c0a@china.huawei.com> In-Reply-To: <001901c9edda$ff5bceb0$3e0c7c0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16706.001 Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 18:56:17 -0000 Frank Xia escribió: > Hi Marcelo > > Please check again... > > BR > Frank > ----- Original Message ----- From: "marcelo bagnulo braun" > > To: "Frank Xia" > Cc: "SAVI Mailing List" > Sent: Monday, June 15, 2009 11:01 AM > Subject: Re: [savi] A different trade off for SAVI > > > Frank Xia escribió: >> Hi Marcelo >> >> Please check my inline comments. >> >> BR >> Frank >> >> ----- Original Message ----- From: "marcelo bagnulo braun" >> >> To: "SAVI Mailing List" >> Sent: Sunday, June 07, 2009 1:59 PM >> Subject: [savi] A different trade off for SAVI >> >> >>> Over the last few weeks, we have been discussing different approaches >>> for SAVI to be used in conjunction IPv6 stateless address >>> autconfiguration. >>> the different proposed approaches have different pros and cons, due to >>> different tradeoffs being made. >>> In this email, i describe an intermediate approach that may be worth >>> to be considered. >>> >>> So, i will first try to summarize the design questions that we have >>> been considering. >>> The first question is whether we create bindings using only DAD packets >>> or we also create bindings using data packet. >>> Creating bindings only with DAD packets, imposes the questions about >>> what can be done when a packets with a source address for which there >>> is no binding. >>> One option would be discard the packet. The problem with this approach >>> is that legitimate packets can be drop. In particular, DAD is not a >>> reliable protocol, so it is possible that DAD packets are lost and >>> do not reach the SAVI device. Similarly, it is also possible that a >>> SAVI device reboots, which would imply that the bindings are lost and >>> since the host may not perform the DAD again, legitimate packets would >>> be lost. >>> It is important to quantify this risk. In my personal opinion, the risk >>> is high enough that i am not comfortable designing a SAVI solution >>> that will discard legitimate packets. OTOH, it is likely that in an >>> important number of cases, the DAD messages are actually delivered and >>> the SAVI device creates the binding using them. >> >> Frank=>IMHO, DAD only is not feasible. DAD procedure in IPv6 >> operation is only a SHOULD, not a MUST. > I am kind of confused here. > DAD is a MUST for stateless address autoconf > My problem is that DAD packet may get lost, are we talking about the > same thing here or not? > > Frank=>DAD is NOT a MUST for stateless address configuration. > RFC 4862 reads > " By default, all addresses should be tested for uniqueness prior to > their assignment to an interface for safety. The test should > individually be performed on all addresses obtained manually, via > stateless address autoconfiguration, or via DHCPv6. To accommodate > sites that believe the overhead of performing Duplicate Address > Detection outweighs its benefits, the use of Duplicate Address > Detection can be disabled through the administrative setting of a > per-interface configuration flag." so? I think it is safe to assume that if we define a SAVI solution that relies on DAD, sites using the SAVI solution will not disable the DAD procedure. I fail to see what is the problem here. > >> >> >>> >>> So, we return to the initial question about what do we do with data >>> packets containing a source address for which there is no binding. >> >> >> Frank=>I propose that SAVI devices manipulate ND protocol >> to establish a binding triggered by the data packets. >> > you mean other ND msgs than DAD? which ones? > > Frank=>DAD is not a message but a procedure which includes > NS and NA. SAVI device acting as a host initiates NS message for > the target host to build or verify binding states which are built > by FCFS. It seems to be complementary to FCFS. > FCFS as currently defined uses both DAD and data packets. I am not sure if you are proposing to use other ND msgs than the ones involved in the DAD procedure >>> As i mentioned, the other option is to create a binding. The >>> drawback of >>> that approach is that we need to distribute the binding information >>> to the other SAVI devices, so that the configure the binding. (I am >>> here assuming that the DAD messages are in general distributed to all >>> the SAVI devices in the link. In order to do so, we need to require >>> that the SAVI devices receive the packets for all solicited nodes >>> multicast groups, but i understand this is feasible). So, it seems >>> than that in order to distribute the bindings created by the corner >>> case >>> that the DAD packet is lost, we need to require the usage of a SAVI >>> protocol to exchange binding data. >> Frank=>Distributing of SAVI states among switches >> seems to introduce extra complexity to switchs. However, if we try to >> do so, probably we can consider that rotuers distribute >> the information to switchs. I assume routers have authorative >> binding information. > how come the routers have the auhtoritative information? > Frank=>An access router is an edge between layer 2 network layer 3 > network. > Access router is responsible for address configuration of host, how come? with stateless address autoconf, each host autoconfigures an address and the router is not aware of the addresses configured by each node > and > relates the corresponding layer 2 information to the the host. you mean when it forwards the first data packet? > IMHO, there is no any necessary work to do if we try to build > SAVI state in an access router. i am still not see what is the advatage of doing that OTOH, it is clear that the security level is lower, since the intra subnetwork traffic may not flow through the access router In any case, the proposed approach of relying on DAD packets works perfectly fine both wen SAVI is implemented in the router or in the switch > ALL the DAD/DHCP snooping > work is on switchs not routers. > not sure why this is an issue >> >>> >>> If we don't think that discarding them is acceptable and we >>> think that creating a SAVI protocol is an overkill for supporting the >>> case where the DAD packets were lost, we may want to consider a middle >>> ground option. >>> >>> An intermediate option would be to simply forward (and eventually log) >>> data packets with source address for which there is no binding. >> Frank=>This is not helpful. Operators are now in the middle of alarm >> sea. >> There are too many alarms to handle. > the goal of this would not be to trigger an alram but to allow to trace > back the lower layer anchor in case the packet was used in an attack. > >> We just offload our due work to our >> miserable maintenance colleagues :-) >> >>> >>> So, let me expand on this. The behaviour of this approach would be: >>> If DAD exchange is detected by the SAVI device, a binding is created. >>> >>> If a data packet containing a source address for which a binding exists >>> and the same lower layer anchor is received, then the packet is >>> forwarded. >>> >>> If a data packet containing a source address for which a binding exists >>> and a different lower layer anchor is received, then the packet is >>> drop. >>> >>> If a data packet containing a source address for which no binding >>> exists >>> the data packet is forwarded and optionally logged. >>> >>> So what are the security properties of such a solution? >> Frank=>Logging flood could be exploited by malicious people >> for attacking. >> > sure, but i am not sure i see any other way to allow tracking back > attacks... > >>> >>> If a host starts using an address and performs the DAD procedure, then >>> no other host can use its address as a source address in data packets. >>> >>> An attacker can start using an address for which there is no binding. >>> In order for this address to be the address of another host, this >>> can only happen if the DAD packet was lost. I am not sure how concerned >> Frank=>Rogue hosts could deliberately ignor DAD procedure. >> > so? what woudl the impact of this? > Frank=>Just a deliberate attack. > and the question is what is the impact of this attack? I fail to see any problem that is introduced by an attacker ignoring DAD packets Regards, marcelo >>> should we be about preventing this from attackers that have the >>> capability of disturbing DAD, I mean, if they are able to do that, >>> i guess they can launch worse attacks than spoof a source address. >> Frank=>I agree this philosophy. It is not necessary for us to have a >> perfect SAVI solution to deal with all the threats. At the same time, >> I prefer letting packet pass if we could not decide if it is a >> legitimate >> packet. >> > good > > regards, marcelo > >>> An attacker can use a given address from different lower layer anchors. >>> I am not sure why this would be an attack though. As i said earlier >>> it would be possible for the SAVI device to log the occurrence of these >>> packets and allow to trace back to the lower layer anchor. >>> >>> So, this option seems like a middle ground option with a somehow >>> reduced >>> level of security but with a low level of complexity and without >>> the possibility of disturbing the network behaviour by discarding >>> legitimate packets. >>> >>> Comments? >>> >>> Regards, marcelo >>> >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >> >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From marcelo@it.uc3m.es Mon Jun 15 12:12:31 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A1C13A6C58 for ; Mon, 15 Jun 2009 12:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.632 X-Spam-Level: X-Spam-Status: No, score=-6.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IfaYf-FL4zP for ; Mon, 15 Jun 2009 12:12:29 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 718E53A6A74 for ; Mon, 15 Jun 2009 12:12:28 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (204.pool85-53-133.dynamic.orange.es [85.53.133.204]) by smtp01.uc3m.es (Postfix) with ESMTP id CBD40B9FD81; Mon, 15 Jun 2009 20:47:44 +0200 (CEST) Message-ID: <4A369750.5070606@it.uc3m.es> Date: Mon, 15 Jun 2009 20:47:44 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Eric Levy-Abegnoli References: <4A2C0DFB.3040803@it.uc3m.es> <4A2D2221.4030503@cisco.com> <4A2D2739.1000206@it.uc3m.es> <4A2F9E29.5070704@cisco.com> <4A30D6CD.8060209@it.uc3m.es> <49417952-8570-467E-B312-B759DC3D88DD@ericsson.com> <4A35ECEE.7060801@cisco.com> <4A35F8EE.3010903@it.uc3m.es> <4A3600DE.2020004@cisco.com> <4A365D51.2040308@it.uc3m.es> <4A3677A1.3070805@cisco.com> In-Reply-To: <4A3677A1.3070805@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16706.001 Cc: SAVI Mailing List , Christian Vogt Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 19:12:31 -0000 Eric Levy-Abegnoli escribió: > marcelo bagnulo braun a écrit : >> Eric Levy-Abegnoli escribió: >>> marcelo bagnulo braun a écrit : >>>> Eric Levy-Abegnoli escribió: >>>>> Christian , >>>>> Christian Vogt a écrit : >>>>>> Eric and Marcelo - >>>>>> >>>>>> Reading the email exchange between you two, I am making the >>>>>> following >>>>>> conclusions: Using control packets other than DAD to infer address >>>>>> ownership could indeed help reducing the probability of false packet >>>>>> drops. But what should be carefully evaluated is: >>>>>> >>>>>> - How much complexity would this add to the SAVI protocol? >>>>>> >>>>>> - Would this introduce new vulnerabilities? >>>>>> >>>>>> In particular the latter seems problematic to me. If we were to use >>>>>> control packets other than DAD to infer address ownership, how >>>>>> would we >>>>>> prevent spoofing of those control packets? Keep in mind that, >>>>>> unlike >>>>>> many other control packets, DAD has the nice property that it gives >>>>>> the victim of a spoofing attack a chance to speak up. This >>>>>> increases >>>>>> the bar for spoofing DAD packets. >>>>> I am a bit confused here, or maybe I lack some background of >>>>> previous discussions. Look to me there is a tradeoff; almost an >>>>> antagonism between prefering the first binding (hence the first >>>>> packet carrying this binding) and allowing nodes to defend their >>>>> address. It's pretty trivial for the attacker to listen to the DAD >>>>> from his victim, and answer as soon as he sees it. And then take >>>>> ownership of the binding if I read you correctly. >>>> this is an attack against DAD and not against savi >>>> I mean, if the attacker replies, what will happen is that the node >>>> will try another address and perform DAD again. >>>> In that sense, the attacker is not stealing the node's addresses >>>> since the node has not configured the address yet. >>> This is a fairly subtil distinction that attacker will certainly >>> exploit. Most nodes will do DAD everytime the interface got down/up, >>> even though that is not absolutely required by the protocol. >> but again, this is not an attack against SAVI, but an attack against >> DAD itself. this is not introduced nor amplified by SAVI. >> So, one could ask the question whether SAVI could/should do something >> about it. >> I would say that this vulnerability is well know and documented and >> the solution to this already exists and it is SEND > I think SAVI has the opportunity to provide some benefits (SeND based > whenever applicable) comparable to SeND, but protecting the entire > community of nodes on the link at once. > Including those with no SeND. it really depends on the amount of complexity this implies. If a subproduct of SAVI is better ND protectiong, then great, but i wouldn't go for a more complex SAVI solution just to protect ND. there are other tools for that, SEND is one of them, but other means to protect from rogue RA are also been adopted > >> >>> And interface go down/up pretty commonly these days, with notebooks >>> moving around. So the switch will blindly replace its "old" binding >>> by the one of the DAD responder? Then it will endup with an >>> illegitimate binding. So it is also a victim, not just the end-node. >> So, first of all, would it make sense to keep the old binding? >> I mean, the host that is performing DAD will not keep on using the >> address, cause the DAD has failed, right? So why is it useful to keep >> the old binding? > If an attacker can so easlily put its own binding into the table (for > instance sending a DAD message every X seconds until one is installed > because the original owner has gone), what do you mean has gone? If the owner has really gone, i.e. it is no longer using the address, then i don't see how this is an attack. > then the switch become no more than a registration chamber. With > nothing to say about who is good and who is bad. I think we do have proposed some ways to define if a binding is preferred. The first node claiming an address, it is i the owner. If a new node come and the original is still reachable, the first one still keep the address If the initial node is no longer reachable, the new node gets the address (this is needed for mobility) Do you see a problem with this? > > I think we have a fundamental difference on the goals. I think that > the switch should make decisions on what gets in (the binding table) > and what does not, as well as how long it stays there, we certainly agree here, see the summary of the rules above > not fully coupled with end-nodes view. (I don't mean not_coupled). I am not sure i understnad this Regards, marcelo > regards > Eric >> >> The SAVI device could have memroy and if the binding was initially >> created through DAD and if now DAD fails for the same lower layer >> anchor, it may be likely that an attacker is attacking DAD and SAVI >> could react to that, but i am not sure how useful would that, since >> the host will not configure the address cause DAD have failed. >> >> Regards, marcelo >> >> >>>> >>>>> Note that many switches won't do mld snooping and simply >>>>> (hardware) broadcast messages to solicited node multcast addresses >>>>> to all nodes. >>>> right >>>> >>>>> So did this group agree that the DAD responder should have his >>>>> binding preferred over the DAD sender? If so, how can this be an >>>>> anti-spoofing protection mechanism? >>>> i guess this was agreed when DAD was defined. I mean, DAD states >>>> that if a node replies the NSOL during DAD, the node performing DAD >>>> will try a different address >>>> >>>>> >>>>> And of course, if not, DAD is broken. Unless, we assume the switch >>>>> should have seen the DAD responder own DAD message earlier on (to >>>>> the exception where it could have been lost).But then its the >>>>> swich dending the address, not the node. . >>>>> It all come back to what I described in PLBT, that is a preference >>>>> algorithm for managing collisions: sometimes collision are real >>>>> one, sometime they are attacks, and it's true for DAD and any >>>>> other NDP messages. >>>>> When receiving a DAD response carrying a different binding that >>>>> the DAD request, should the switch >>>>> - prefer it, and expose itself to simple DAD attack >>>>> - prefer the binding of the DAD request, and expose itself to >>>>> break DAD, if it missed an hypothetical earlier DAD request from >>>>> this DAD responder >>>> but that would imply that DAD does no longer work, right? I mean, >>>> if the SAVI always preffer the initial NSOL of the DAD, then, if >>>> there is a colision, we are not honoring the node that originally >>>> got the address >>> If we don't drop, we haven't changed DAD. If we log, we log the >>> attacker, not the original owner. >>> Regards, >>> Eric >>> >>>> >>>> Regards, marcelo >>>> >>>>> >>>>> I would strongly prefer the latter, except that the DAD responder >>>>> could be behind a second switch booted long time before. Hence my >>>>> proposal to prefer binding carried by DAD sender when they are >>>>> directly atachedn but binding carried by DAD responder when they >>>>> are attached via a second switch. >>>>> Eric >>>>>> >>>>>> - Christian >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > From xiayangsong@huawei.com Mon Jun 15 13:24:07 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2903E3A6833 for ; Mon, 15 Jun 2009 13:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.905 X-Spam-Level: X-Spam-Status: No, score=-0.905 tagged_above=-999 required=5 tests=[AWL=-0.410, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6GVuKu9ZVlc for ; Mon, 15 Jun 2009 13:24:05 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 613093A6858 for ; Mon, 15 Jun 2009 13:24:05 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLA003HHRAW04@szxga02-in.huawei.com> for savi@ietf.org; Tue, 16 Jun 2009 04:23:20 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLA005F5RAW3V@szxga02-in.huawei.com> for savi@ietf.org; Tue, 16 Jun 2009 04:23:20 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLA0045WRAT0Z@szxml06-in.huawei.com> for savi@ietf.org; Tue, 16 Jun 2009 04:23:20 +0800 (CST) Date: Mon, 15 Jun 2009 15:23:16 -0500 From: Frank Xia To: marcelo bagnulo braun Message-id: <005601c9edf7$1eb679b0$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 8BIT X-Priority: 3 X-MSMail-priority: Normal References: <4A2C0DFB.3040803@it.uc3m.es> <00e301c9edcf$c7cc7bd0$3e0c7c0a@china.huawei.com> <4A36706D.9050501@it.uc3m.es> <001901c9edda$ff5bceb0$3e0c7c0a@china.huawei.com> <4A36992A.9010904@it.uc3m.es> Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 20:24:07 -0000 Hi Marcelo please see inline.. BR Frank ----- Original Message ----- From: "marcelo bagnulo braun" To: "Frank Xia" Cc: "SAVI Mailing List" Sent: Monday, June 15, 2009 1:55 PM Subject: Re: [savi] A different trade off for SAVI Frank Xia escribió: > Hi Marcelo > > Please check again... > > BR > Frank > ----- Original Message ----- From: "marcelo bagnulo braun" > > To: "Frank Xia" > Cc: "SAVI Mailing List" > Sent: Monday, June 15, 2009 11:01 AM > Subject: Re: [savi] A different trade off for SAVI > > > Frank Xia escribió: >> Hi Marcelo >> >> Please check my inline comments. >> >> BR >> Frank >> >> ----- Original Message ----- From: "marcelo bagnulo braun" >> >> To: "SAVI Mailing List" >> Sent: Sunday, June 07, 2009 1:59 PM >> Subject: [savi] A different trade off for SAVI >> >> >>> Over the last few weeks, we have been discussing different approaches >>> for SAVI to be used in conjunction IPv6 stateless address >>> autconfiguration. >>> the different proposed approaches have different pros and cons, due to >>> different tradeoffs being made. >>> In this email, i describe an intermediate approach that may be worth >>> to be considered. >>> >>> So, i will first try to summarize the design questions that we have >>> been considering. >>> The first question is whether we create bindings using only DAD packets >>> or we also create bindings using data packet. >>> Creating bindings only with DAD packets, imposes the questions about >>> what can be done when a packets with a source address for which there >>> is no binding. >>> One option would be discard the packet. The problem with this approach >>> is that legitimate packets can be drop. In particular, DAD is not a >>> reliable protocol, so it is possible that DAD packets are lost and >>> do not reach the SAVI device. Similarly, it is also possible that a >>> SAVI device reboots, which would imply that the bindings are lost and >>> since the host may not perform the DAD again, legitimate packets would >>> be lost. >>> It is important to quantify this risk. In my personal opinion, the risk >>> is high enough that i am not comfortable designing a SAVI solution >>> that will discard legitimate packets. OTOH, it is likely that in an >>> important number of cases, the DAD messages are actually delivered and >>> the SAVI device creates the binding using them. >> >> Frank=>IMHO, DAD only is not feasible. DAD procedure in IPv6 >> operation is only a SHOULD, not a MUST. > I am kind of confused here. > DAD is a MUST for stateless address autoconf > My problem is that DAD packet may get lost, are we talking about the > same thing here or not? > > Frank=>DAD is NOT a MUST for stateless address configuration. > RFC 4862 reads > " By default, all addresses should be tested for uniqueness prior to > their assignment to an interface for safety. The test should > individually be performed on all addresses obtained manually, via > stateless address autoconfiguration, or via DHCPv6. To accommodate > sites that believe the overhead of performing Duplicate Address > Detection outweighs its benefits, the use of Duplicate Address > Detection can be disabled through the administrative setting of a > per-interface configuration flag." so? I think it is safe to assume that if we define a SAVI solution that relies on DAD, sites using the SAVI solution will not disable the DAD procedure. I fail to see what is the problem here. Frank=>You say "DAD is a MUST for stateless address autoconf" while I am saying "DAD is NOT a MUST ...". Change of this basic assumption should have some impact on the solution :-) "sites using the SAVI solution will not disable the DAD procedure" is not a good constraints which places extra burdens to network management. A maintenance engineer should be able to know which OS the host is using, and which command for enabling/disabling DAD. When he talks to a subscriber about DAD operation, the subscriber probably really takes that something is wrong with his Dad :-) > >> >> >>> >>> So, we return to the initial question about what do we do with data >>> packets containing a source address for which there is no binding. >> >> >> Frank=>I propose that SAVI devices manipulate ND protocol >> to establish a binding triggered by the data packets. >> > you mean other ND msgs than DAD? which ones? > > Frank=>DAD is not a message but a procedure which includes > NS and NA. SAVI device acting as a host initiates NS message for > the target host to build or verify binding states which are built > by FCFS. It seems to be complementary to FCFS. > FCFS as currently defined uses both DAD and data packets. I am not sure if you are proposing to use other ND msgs than the ones involved in the DAD procedure >>> As i mentioned, the other option is to create a binding. The drawback of >>> that approach is that we need to distribute the binding information >>> to the other SAVI devices, so that the configure the binding. (I am >>> here assuming that the DAD messages are in general distributed to all >>> the SAVI devices in the link. In order to do so, we need to require >>> that the SAVI devices receive the packets for all solicited nodes >>> multicast groups, but i understand this is feasible). So, it seems >>> than that in order to distribute the bindings created by the corner case >>> that the DAD packet is lost, we need to require the usage of a SAVI >>> protocol to exchange binding data. >> Frank=>Distributing of SAVI states among switches >> seems to introduce extra complexity to switchs. However, if we try to >> do so, probably we can consider that rotuers distribute >> the information to switchs. I assume routers have authorative >> binding information. > how come the routers have the auhtoritative information? > Frank=>An access router is an edge between layer 2 network layer 3 > network. > Access router is responsible for address configuration of host, how come? with stateless address autoconf, each host autoconfigures an address and the router is not aware of the addresses configured by each node Frank=>Router fowarding is based on complete addresses of the hosts whatever the address configuration mode the host is using. The router is aware of the addresses. ND protocol is run between the router and the hosts. In fact, the address legitimacy should be validated by the router. > and > relates the corresponding layer 2 information to the the host. you mean when it forwards the first data packet? > IMHO, there is no any necessary work to do if we try to build > SAVI state in an access router. i am still not see what is the advatage of doing that OTOH, it is clear that the security level is lower, since the intra subnetwork traffic may not flow through the access router In any case, the proposed approach of relying on DAD packets works perfectly fine both wen SAVI is implemented in the router or in the switch Frank=>I mean currently access routers have already been able to do binding check of a host regarding source address and layer 2. The access router get all the information without SAVI involvement. > ALL the DAD/DHCP snooping > work is on switchs not routers. > not sure why this is an issue Frank=>When we talk about snooping, it implies switch snooping. When we propose solution based on snooping, it is also implies the solution is for switch. IMHO, purpose of SAVI seems to offload source address validation work from an access router to a layer 2 device. >> >>> >>> If we don't think that discarding them is acceptable and we >>> think that creating a SAVI protocol is an overkill for supporting the >>> case where the DAD packets were lost, we may want to consider a middle >>> ground option. >>> >>> An intermediate option would be to simply forward (and eventually log) >>> data packets with source address for which there is no binding. >> Frank=>This is not helpful. Operators are now in the middle of alarm >> sea. >> There are too many alarms to handle. > the goal of this would not be to trigger an alram but to allow to trace > back the lower layer anchor in case the packet was used in an attack. > >> We just offload our due work to our >> miserable maintenance colleagues :-) >> >>> >>> So, let me expand on this. The behaviour of this approach would be: >>> If DAD exchange is detected by the SAVI device, a binding is created. >>> >>> If a data packet containing a source address for which a binding exists >>> and the same lower layer anchor is received, then the packet is >>> forwarded. >>> >>> If a data packet containing a source address for which a binding exists >>> and a different lower layer anchor is received, then the packet is drop. >>> >>> If a data packet containing a source address for which no binding exists >>> the data packet is forwarded and optionally logged. >>> >>> So what are the security properties of such a solution? >> Frank=>Logging flood could be exploited by malicious people >> for attacking. >> > sure, but i am not sure i see any other way to allow tracking back > attacks... > >>> >>> If a host starts using an address and performs the DAD procedure, then >>> no other host can use its address as a source address in data packets. >>> >>> An attacker can start using an address for which there is no binding. >>> In order for this address to be the address of another host, this >>> can only happen if the DAD packet was lost. I am not sure how concerned >> Frank=>Rogue hosts could deliberately ignor DAD procedure. >> > so? what woudl the impact of this? > Frank=>Just a deliberate attack. > and the question is what is the impact of this attack? I fail to see any problem that is introduced by an attacker ignoring DAD packets Regards, marcelo >>> should we be about preventing this from attackers that have the >>> capability of disturbing DAD, I mean, if they are able to do that, >>> i guess they can launch worse attacks than spoof a source address. >> Frank=>I agree this philosophy. It is not necessary for us to have a >> perfect SAVI solution to deal with all the threats. At the same time, >> I prefer letting packet pass if we could not decide if it is a legitimate >> packet. >> > good > > regards, marcelo > >>> An attacker can use a given address from different lower layer anchors. >>> I am not sure why this would be an attack though. As i said earlier >>> it would be possible for the SAVI device to log the occurrence of these >>> packets and allow to trace back to the lower layer anchor. >>> >>> So, this option seems like a middle ground option with a somehow reduced >>> level of security but with a low level of complexity and without >>> the possibility of disturbing the network behaviour by discarding >>> legitimate packets. >>> >>> Comments? >>> >>> Regards, marcelo >>> >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >> >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi From marcelo@it.uc3m.es Mon Jun 15 14:26:19 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7CAF3A6874 for ; Mon, 15 Jun 2009 14:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.63 X-Spam-Level: X-Spam-Status: No, score=-6.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8NFmzUz5ZHN for ; Mon, 15 Jun 2009 14:26:18 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id B5DDB3A697D for ; Mon, 15 Jun 2009 14:26:17 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (206.pool85-53-130.dynamic.orange.es [85.53.130.206]) by smtp01.uc3m.es (Postfix) with ESMTP id 5CF21BA4BBC; Mon, 15 Jun 2009 23:26:09 +0200 (CEST) Message-ID: <4A36BC71.90408@it.uc3m.es> Date: Mon, 15 Jun 2009 23:26:09 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Frank Xia References: <4A2C0DFB.3040803@it.uc3m.es> <00e301c9edcf$c7cc7bd0$3e0c7c0a@china.huawei.com> <4A36706D.9050501@it.uc3m.es> <001901c9edda$ff5bceb0$3e0c7c0a@china.huawei.com> <4A36992A.9010904@it.uc3m.es> <005601c9edf7$1eb679b0$3e0c7c0a@china.huawei.com> In-Reply-To: <005601c9edf7$1eb679b0$3e0c7c0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16706.002 Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 21:26:20 -0000 Frank Xia escribió: > Hi Marcelo > > please see inline.. > > BR > Frank > > ----- Original Message ----- From: "marcelo bagnulo braun" > > To: "Frank Xia" > Cc: "SAVI Mailing List" > Sent: Monday, June 15, 2009 1:55 PM > Subject: Re: [savi] A different trade off for SAVI > > > Frank Xia escribió: >> Hi Marcelo >> >> Please check again... >> >> BR >> Frank >> ----- Original Message ----- From: "marcelo bagnulo braun" >> >> To: "Frank Xia" >> Cc: "SAVI Mailing List" >> Sent: Monday, June 15, 2009 11:01 AM >> Subject: Re: [savi] A different trade off for SAVI >> >> >> Frank Xia escribió: >>> Hi Marcelo >>> >>> Please check my inline comments. >>> >>> BR >>> Frank >>> >>> ----- Original Message ----- From: "marcelo bagnulo braun" >>> >>> To: "SAVI Mailing List" >>> Sent: Sunday, June 07, 2009 1:59 PM >>> Subject: [savi] A different trade off for SAVI >>> >>> >>>> Over the last few weeks, we have been discussing different approaches >>>> for SAVI to be used in conjunction IPv6 stateless address >>>> autconfiguration. >>>> the different proposed approaches have different pros and cons, due to >>>> different tradeoffs being made. >>>> In this email, i describe an intermediate approach that may be worth >>>> to be considered. >>>> >>>> So, i will first try to summarize the design questions that we have >>>> been considering. >>>> The first question is whether we create bindings using only DAD >>>> packets >>>> or we also create bindings using data packet. >>>> Creating bindings only with DAD packets, imposes the questions about >>>> what can be done when a packets with a source address for which there >>>> is no binding. >>>> One option would be discard the packet. The problem with this approach >>>> is that legitimate packets can be drop. In particular, DAD is not a >>>> reliable protocol, so it is possible that DAD packets are lost and >>>> do not reach the SAVI device. Similarly, it is also possible that a >>>> SAVI device reboots, which would imply that the bindings are lost and >>>> since the host may not perform the DAD again, legitimate packets would >>>> be lost. >>>> It is important to quantify this risk. In my personal opinion, the >>>> risk >>>> is high enough that i am not comfortable designing a SAVI solution >>>> that will discard legitimate packets. OTOH, it is likely that in an >>>> important number of cases, the DAD messages are actually delivered and >>>> the SAVI device creates the binding using them. >>> >>> Frank=>IMHO, DAD only is not feasible. DAD procedure in IPv6 >>> operation is only a SHOULD, not a MUST. >> I am kind of confused here. >> DAD is a MUST for stateless address autoconf >> My problem is that DAD packet may get lost, are we talking about the >> same thing here or not? >> >> Frank=>DAD is NOT a MUST for stateless address configuration. >> RFC 4862 reads >> " By default, all addresses should be tested for uniqueness prior to >> their assignment to an interface for safety. The test should >> individually be performed on all addresses obtained manually, via >> stateless address autoconfiguration, or via DHCPv6. To accommodate >> sites that believe the overhead of performing Duplicate Address >> Detection outweighs its benefits, the use of Duplicate Address >> Detection can be disabled through the administrative setting of a >> per-interface configuration flag." > so? > I think it is safe to assume that if we define a SAVI solution that > relies on DAD, sites using the SAVI solution will not disable the DAD > procedure. > I fail to see what is the problem here. > > Frank=>You say "DAD is a MUST for stateless address autoconf" while > I am saying "DAD is NOT a MUST ...". Change of this basic assumption > should have some impact on the solution :-) > > "sites using the SAVI solution will not disable the DAD > procedure" is not a good constraints which places extra burdens > to network management. I don't see too much of a constraint to require that a site that wants to use SAVI for statelessly configured addresses needs to enable DAD > A maintenance engineer should be able > to know which OS the host is using, and which command > for enabling/disabling DAD. When he talks to a subscriber > about DAD operation, the subscriber probably really takes that > something is wrong with his Dad :-) that doesn't follow By default DAD MUST be performed i.e. accoridng to RFC4862 in normative lenguage it reads: Duplicate Address Detection MUST be performed on all unicast addresses prior to assigning them to an interface, regardless of whether they are obtained through stateless autoconfiguration, DHCPv6, or manual configuration, with the following exceptions: - An interface whose DupAddrDetectTransmits variable is set to zero does not perform Duplicate Address Detection. - Duplicate Address Detection MUST NOT be performed on anycast addresses (note that anycast addresses cannot syntactically be distinguished from unicast addresses). - Each individual unicast address SHOULD be tested for uniqueness. Note that there are implementations deployed that only perform Duplicate Address Detection for the link-local address and skip the test for the global address that uses the same interface identifier as that of the link-local address. Whereas this document does not invalidate such implementations, this kind of Thomson, et al. Standards Track [Page 12] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 "optimization" is NOT RECOMMENDED, and new implementations MUST NOT do that optimization. This optimization came from the assumption that all of an interface's addresses are generated from the same identifier. However, the assumption does actually not stand; new types of addresses have been introduced where the interface identifiers are not necessarily the same for all unicast addresses on a single interface [RFC4941] [RFC3972]. Requiring that Duplicate Address Detection be performed for all unicast addresses will make the algorithm robust for the current and future special interface identifiers. and the default value of the DupAddrDetectTransmits is one So, in a non managed network, the OS will perform DAD and a user will need to manually deactivate it. So if the user knows enough to deactivte DAD, he should understnad the impact and should understnad that SAVI will not work in that environment. In other words, a host that follows the specs will behave properly in a SAVi solution that uses DAD >> >>> >>> >>>> >>>> So, we return to the initial question about what do we do with data >>>> packets containing a source address for which there is no binding. >>> >>> >>> Frank=>I propose that SAVI devices manipulate ND protocol >>> to establish a binding triggered by the data packets. >>> >> you mean other ND msgs than DAD? which ones? >> >> Frank=>DAD is not a message but a procedure which includes >> NS and NA. SAVI device acting as a host initiates NS message for >> the target host to build or verify binding states which are built >> by FCFS. It seems to be complementary to FCFS. >> > FCFS as currently defined uses both DAD and data packets. > I am not sure if you are proposing to use other ND msgs than the ones > involved in the DAD procedure > >>>> As i mentioned, the other option is to create a binding. The >>>> drawback of >>>> that approach is that we need to distribute the binding information >>>> to the other SAVI devices, so that the configure the binding. (I am >>>> here assuming that the DAD messages are in general distributed to all >>>> the SAVI devices in the link. In order to do so, we need to require >>>> that the SAVI devices receive the packets for all solicited nodes >>>> multicast groups, but i understand this is feasible). So, it seems >>>> than that in order to distribute the bindings created by the corner >>>> case >>>> that the DAD packet is lost, we need to require the usage of a SAVI >>>> protocol to exchange binding data. >>> Frank=>Distributing of SAVI states among switches >>> seems to introduce extra complexity to switchs. However, if we try to >>> do so, probably we can consider that rotuers distribute >>> the information to switchs. I assume routers have authorative >>> binding information. >> how come the routers have the auhtoritative information? >> Frank=>An access router is an edge between layer 2 network layer 3 >> network. >> Access router is responsible for address configuration of host, > how come? with stateless address autoconf, each host autoconfigures an > address and the router is not aware of the addresses configured by > each node > Frank=>Router fowarding is based on complete addresses of the hosts > whatever the address configuration mode the host is using. The router > is aware of the addresses. but the router is aware of the address once it has forwarded a packet for that host, which may be later than the DAD procedure, this would open a vulnerabiluty window from the time DAD is perfromed and the first packet is forwarded, which the attacker canuse to create a fals binding in the router (by sending a data packet) > ND protocol is run between the router and the > hosts. In fact, the address legitimacy should be validated by the > router. > I certainly see SAVI enabled routers being one possible configuration, i fail to see why it should be the only one and i fail to see what is the benefitto move away from a DAD based scheme >> and >> relates the corresponding layer 2 information to the the host. > you mean when it forwards the first data packet? >> IMHO, there is no any necessary work to do if we try to build >> SAVI state in an access router. > i am still not see what is the advatage of doing that > OTOH, it is clear that the security level is lower, since the intra > subnetwork traffic may not flow through the access router > In any case, the proposed approach of relying on DAD packets works > perfectly fine both wen SAVI is implemented in the router or in the > switch > > Frank=>I mean currently access routers have already been able to > do binding check of a host regarding source address and layer 2. > The access router get all the information without SAVI involvement. > right and the problem is that currently routers forward packet with spoofed addresses and in order to solve that we need savi >> ALL the DAD/DHCP snooping >> work is on switchs not routers. >> > not sure why this is an issue > Frank=>When we talk about snooping, it implies switch snooping. no, the router can also snoop packets > When we propose solution based on snooping, it is also implies > the solution is for switch. i disagree the approach described in the origin of this threat can be equally be used in a switch or in a router > IMHO, purpose of SAVI seems to > offload source address validation work from an access router to > a layer 2 device. > no, imho, it should support both configurations (and it does afaict) regards, marcelo >>> >>>> >>>> If we don't think that discarding them is acceptable and we >>>> think that creating a SAVI protocol is an overkill for supporting the >>>> case where the DAD packets were lost, we may want to consider a middle >>>> ground option. >>>> >>>> An intermediate option would be to simply forward (and eventually log) >>>> data packets with source address for which there is no binding. >>> Frank=>This is not helpful. Operators are now in the middle of >>> alarm sea. >>> There are too many alarms to handle. >> the goal of this would not be to trigger an alram but to allow to trace >> back the lower layer anchor in case the packet was used in an attack. >> >>> We just offload our due work to our >>> miserable maintenance colleagues :-) >>> >>>> >>>> So, let me expand on this. The behaviour of this approach would be: >>>> If DAD exchange is detected by the SAVI device, a binding is created. >>>> >>>> If a data packet containing a source address for which a binding >>>> exists >>>> and the same lower layer anchor is received, then the packet is >>>> forwarded. >>>> >>>> If a data packet containing a source address for which a binding >>>> exists >>>> and a different lower layer anchor is received, then the packet is >>>> drop. >>>> >>>> If a data packet containing a source address for which no binding >>>> exists >>>> the data packet is forwarded and optionally logged. >>>> >>>> So what are the security properties of such a solution? >>> Frank=>Logging flood could be exploited by malicious people >>> for attacking. >>> >> sure, but i am not sure i see any other way to allow tracking back >> attacks... >> >>>> >>>> If a host starts using an address and performs the DAD procedure, then >>>> no other host can use its address as a source address in data packets. >>>> >>>> An attacker can start using an address for which there is no binding. >>>> In order for this address to be the address of another host, this >>>> can only happen if the DAD packet was lost. I am not sure how >>>> concerned >>> Frank=>Rogue hosts could deliberately ignor DAD procedure. >>> >> so? what woudl the impact of this? >> Frank=>Just a deliberate attack. >> > and the question is what is the impact of this attack? I fail to see any > problem that is introduced by an attacker ignoring DAD packets > > Regards, marcelo > > >>>> should we be about preventing this from attackers that have the >>>> capability of disturbing DAD, I mean, if they are able to do that, >>>> i guess they can launch worse attacks than spoof a source address. >>> Frank=>I agree this philosophy. It is not necessary for us to have a >>> perfect SAVI solution to deal with all the threats. At the same time, >>> I prefer letting packet pass if we could not decide if it is a >>> legitimate >>> packet. >>> >> good >> >> regards, marcelo >> >>>> An attacker can use a given address from different lower layer >>>> anchors. >>>> I am not sure why this would be an attack though. As i said earlier >>>> it would be possible for the SAVI device to log the occurrence of >>>> these >>>> packets and allow to trace back to the lower layer anchor. >>>> >>>> So, this option seems like a middle ground option with a somehow >>>> reduced >>>> level of security but with a low level of complexity and without >>>> the possibility of disturbing the network behaviour by discarding >>>> legitimate packets. >>>> >>>> Comments? >>>> >>>> Regards, marcelo >>>> >>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>> >>> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From xiayangsong@huawei.com Mon Jun 15 15:14:23 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3102728C0E5 for ; Mon, 15 Jun 2009 15:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.837 X-Spam-Level: X-Spam-Status: No, score=-0.837 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXTIjfanmEFU for ; Mon, 15 Jun 2009 15:14:21 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 1DA1B28C0FD for ; Mon, 15 Jun 2009 15:14:21 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLA00DYSWFXMT@szxga03-in.huawei.com> for savi@ietf.org; Tue, 16 Jun 2009 06:14:21 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLA006KQWFX4K@szxga03-in.huawei.com> for savi@ietf.org; Tue, 16 Jun 2009 06:14:21 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLA004QYWFU0Z@szxml06-in.huawei.com> for savi@ietf.org; Tue, 16 Jun 2009 06:14:21 +0800 (CST) Date: Mon, 15 Jun 2009 17:14:17 -0500 From: Frank Xia To: marcelo bagnulo braun Message-id: <003c01c9ee06$a1438120$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 8BIT X-Priority: 3 X-MSMail-priority: Normal References: <4A2C0DFB.3040803@it.uc3m.es> <00e301c9edcf$c7cc7bd0$3e0c7c0a@china.huawei.com> <4A36706D.9050501@it.uc3m.es> <001901c9edda$ff5bceb0$3e0c7c0a@china.huawei.com> <4A36992A.9010904@it.uc3m.es> <005601c9edf7$1eb679b0$3e0c7c0a@china.huawei.com> <4A36BC71.90408@it.uc3m.es> Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 22:14:23 -0000 Hi Marcelo Please check... BR Frank ----- Original Message ----- From: "marcelo bagnulo braun" To: "Frank Xia" Cc: "SAVI Mailing List" Sent: Monday, June 15, 2009 4:26 PM Subject: Re: [savi] A different trade off for SAVI > Frank Xia escribió: >> Hi Marcelo >> >> please see inline.. >> >> BR >> Frank >> >> ----- Original Message ----- From: "marcelo bagnulo braun" >> >> To: "Frank Xia" >> Cc: "SAVI Mailing List" >> Sent: Monday, June 15, 2009 1:55 PM >> Subject: Re: [savi] A different trade off for SAVI >> >> >> Frank Xia escribió: >>> Hi Marcelo >>> >>> Please check again... >>> >>> BR >>> Frank >>> ----- Original Message ----- From: "marcelo bagnulo braun" >>> >>> To: "Frank Xia" >>> Cc: "SAVI Mailing List" >>> Sent: Monday, June 15, 2009 11:01 AM >>> Subject: Re: [savi] A different trade off for SAVI >>> >>> >>> Frank Xia escribió: >>>> Hi Marcelo >>>> >>>> Please check my inline comments. >>>> >>>> BR >>>> Frank >>>> >>>> ----- Original Message ----- From: "marcelo bagnulo braun" >>>> >>>> To: "SAVI Mailing List" >>>> Sent: Sunday, June 07, 2009 1:59 PM >>>> Subject: [savi] A different trade off for SAVI >>>> >>>> >>>>> Over the last few weeks, we have been discussing different approaches >>>>> for SAVI to be used in conjunction IPv6 stateless address >>>>> autconfiguration. >>>>> the different proposed approaches have different pros and cons, due to >>>>> different tradeoffs being made. >>>>> In this email, i describe an intermediate approach that may be worth >>>>> to be considered. >>>>> >>>>> So, i will first try to summarize the design questions that we have >>>>> been considering. >>>>> The first question is whether we create bindings using only DAD >>>>> packets >>>>> or we also create bindings using data packet. >>>>> Creating bindings only with DAD packets, imposes the questions about >>>>> what can be done when a packets with a source address for which there >>>>> is no binding. >>>>> One option would be discard the packet. The problem with this approach >>>>> is that legitimate packets can be drop. In particular, DAD is not a >>>>> reliable protocol, so it is possible that DAD packets are lost and >>>>> do not reach the SAVI device. Similarly, it is also possible that a >>>>> SAVI device reboots, which would imply that the bindings are lost and >>>>> since the host may not perform the DAD again, legitimate packets would >>>>> be lost. >>>>> It is important to quantify this risk. In my personal opinion, the >>>>> risk >>>>> is high enough that i am not comfortable designing a SAVI solution >>>>> that will discard legitimate packets. OTOH, it is likely that in an >>>>> important number of cases, the DAD messages are actually delivered and >>>>> the SAVI device creates the binding using them. >>>> >>>> Frank=>IMHO, DAD only is not feasible. DAD procedure in IPv6 >>>> operation is only a SHOULD, not a MUST. >>> I am kind of confused here. >>> DAD is a MUST for stateless address autoconf >>> My problem is that DAD packet may get lost, are we talking about the >>> same thing here or not? >>> >>> Frank=>DAD is NOT a MUST for stateless address configuration. >>> RFC 4862 reads >>> " By default, all addresses should be tested for uniqueness prior to >>> their assignment to an interface for safety. The test should >>> individually be performed on all addresses obtained manually, via >>> stateless address autoconfiguration, or via DHCPv6. To accommodate >>> sites that believe the overhead of performing Duplicate Address >>> Detection outweighs its benefits, the use of Duplicate Address >>> Detection can be disabled through the administrative setting of a >>> per-interface configuration flag." >> so? >> I think it is safe to assume that if we define a SAVI solution that >> relies on DAD, sites using the SAVI solution will not disable the DAD >> procedure. >> I fail to see what is the problem here. >> >> Frank=>You say "DAD is a MUST for stateless address autoconf" while >> I am saying "DAD is NOT a MUST ...". Change of this basic assumption >> should have some impact on the solution :-) >> >> "sites using the SAVI solution will not disable the DAD >> procedure" is not a good constraints which places extra burdens >> to network management. > I don't see too much of a constraint to require that a site that wants to > use SAVI for statelessly configured addresses needs to enable DAD > >> A maintenance engineer should be able >> to know which OS the host is using, and which command >> for enabling/disabling DAD. When he talks to a subscriber >> about DAD operation, the subscriber probably really takes that >> something is wrong with his Dad :-) > that doesn't follow > By default DAD MUST be performed i.e. accoridng to RFC4862 in normative > lenguage it reads: > > Duplicate Address Detection MUST be performed on all unicast > addresses prior to assigning them to an interface, regardless of > whether they are obtained through stateless autoconfiguration, > DHCPv6, or manual configuration, with the following exceptions: > > - An interface whose DupAddrDetectTransmits variable is set to zero > does not perform Duplicate Address Detection. > > - Duplicate Address Detection MUST NOT be performed on anycast > addresses (note that anycast addresses cannot syntactically be > distinguished from unicast addresses). > > - Each individual unicast address SHOULD be tested for uniqueness. > Note that there are implementations deployed that only perform > Duplicate Address Detection for the link-local address and skip > the test for the global address that uses the same interface > identifier as that of the link-local address. Whereas this > document does not invalidate such implementations, this kind of > > > > Thomson, et al. Standards Track [Page 12] > > RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 > > > "optimization" is NOT RECOMMENDED, and new implementations MUST > NOT do that optimization. This optimization came from the > assumption that all of an interface's addresses are generated from > the same identifier. However, the assumption does actually not > stand; new types of addresses have been introduced where the > interface identifiers are not necessarily the same for all unicast > addresses on a single interface [RFC4941] [RFC3972]. Requiring > that Duplicate Address Detection be performed for all unicast > addresses will make the algorithm robust for the current and > future special interface identifiers. > > and the default value of the DupAddrDetectTransmits is one Frank=>The above means DAD is a conditional MUST. > > So, in a non managed network, the OS will perform DAD and a user will need > to manually deactivate it. So if the user knows enough to deactivte DAD, > he should understnad the impact and should understnad that SAVI will not > work in that environment. Frank=>What if the device is deactive in DAD by default, and the user has no idea of how to activate it. is it better to have a solution without user involvment? > In other words, a host that follows the specs will behave properly in a > SAVi solution that uses DAD > > >>> >>>> >>>> >>>>> >>>>> So, we return to the initial question about what do we do with data >>>>> packets containing a source address for which there is no binding. >>>> >>>> >>>> Frank=>I propose that SAVI devices manipulate ND protocol >>>> to establish a binding triggered by the data packets. >>>> >>> you mean other ND msgs than DAD? which ones? >>> >>> Frank=>DAD is not a message but a procedure which includes >>> NS and NA. SAVI device acting as a host initiates NS message for >>> the target host to build or verify binding states which are built >>> by FCFS. It seems to be complementary to FCFS. >>> >> FCFS as currently defined uses both DAD and data packets. >> I am not sure if you are proposing to use other ND msgs than the ones >> involved in the DAD procedure >> >>>>> As i mentioned, the other option is to create a binding. The drawback >>>>> of >>>>> that approach is that we need to distribute the binding information >>>>> to the other SAVI devices, so that the configure the binding. (I am >>>>> here assuming that the DAD messages are in general distributed to all >>>>> the SAVI devices in the link. In order to do so, we need to require >>>>> that the SAVI devices receive the packets for all solicited nodes >>>>> multicast groups, but i understand this is feasible). So, it seems >>>>> than that in order to distribute the bindings created by the corner >>>>> case >>>>> that the DAD packet is lost, we need to require the usage of a SAVI >>>>> protocol to exchange binding data. >>>> Frank=>Distributing of SAVI states among switches >>>> seems to introduce extra complexity to switchs. However, if we try to >>>> do so, probably we can consider that rotuers distribute >>>> the information to switchs. I assume routers have authorative >>>> binding information. >>> how come the routers have the auhtoritative information? >>> Frank=>An access router is an edge between layer 2 network layer 3 >>> network. >>> Access router is responsible for address configuration of host, >> how come? with stateless address autoconf, each host autoconfigures an >> address and the router is not aware of the addresses configured by each >> node >> Frank=>Router fowarding is based on complete addresses of the hosts >> whatever the address configuration mode the host is using. The router >> is aware of the addresses. > but the router is aware of the address once it has forwarded a packet for > that host, which may be later than the DAD procedure, this would open a > vulnerabiluty window from the time DAD is perfromed and the first packet > is forwarded, which the attacker canuse to create a fals binding in the > router (by sending a data packet) Frank=>When a host implements RFC4429 Optimistic DAD, this window is unavoidable. > >> ND protocol is run between the router and the >> hosts. In fact, the address legitimacy should be validated by the >> router. >> > I certainly see SAVI enabled routers being one possible configuration, i > fail to see why it should be the only one and i fail to see what is the > benefitto move away from a DAD based scheme Frank=>AFAIK, BRAS as an access router for a host to access to internet has built-in binding check funtion. I just want to say that existing routers enforce source address validation without our SAVI which certainly benefit switch to implement the function. > >>> and >>> relates the corresponding layer 2 information to the the host. >> you mean when it forwards the first data packet? >>> IMHO, there is no any necessary work to do if we try to build >>> SAVI state in an access router. >> i am still not see what is the advatage of doing that >> OTOH, it is clear that the security level is lower, since the intra >> subnetwork traffic may not flow through the access router >> In any case, the proposed approach of relying on DAD packets works >> perfectly fine both wen SAVI is implemented in the router or in the >> switch >> >> Frank=>I mean currently access routers have already been able to >> do binding check of a host regarding source address and layer 2. >> The access router get all the information without SAVI involvement. >> > right and the problem is that currently routers forward packet with > spoofed addresses and in order to solve that we need savi > >>> ALL the DAD/DHCP snooping >>> work is on switchs not routers. >>> >> not sure why this is an issue >> Frank=>When we talk about snooping, it implies switch snooping. > no, the router can also snoop packets > >> When we propose solution based on snooping, it is also implies >> the solution is for switch. > i disagree > the approach described in the origin of this threat can be equally be used > in a switch or in a router Frank=>Access routers as ND/DHCP message terminators don't need to SNOOP message. > >> IMHO, purpose of SAVI seems to >> offload source address validation work from an access router to >> a layer 2 device. >> > no, imho, it should support both configurations (and it does afaict) > > regards, marcelo > > >>>> >>>>> >>>>> If we don't think that discarding them is acceptable and we >>>>> think that creating a SAVI protocol is an overkill for supporting the >>>>> case where the DAD packets were lost, we may want to consider a middle >>>>> ground option. >>>>> >>>>> An intermediate option would be to simply forward (and eventually log) >>>>> data packets with source address for which there is no binding. >>>> Frank=>This is not helpful. Operators are now in the middle of alarm >>>> sea. >>>> There are too many alarms to handle. >>> the goal of this would not be to trigger an alram but to allow to trace >>> back the lower layer anchor in case the packet was used in an attack. >>> >>>> We just offload our due work to our >>>> miserable maintenance colleagues :-) >>>> >>>>> >>>>> So, let me expand on this. The behaviour of this approach would be: >>>>> If DAD exchange is detected by the SAVI device, a binding is created. >>>>> >>>>> If a data packet containing a source address for which a binding >>>>> exists >>>>> and the same lower layer anchor is received, then the packet is >>>>> forwarded. >>>>> >>>>> If a data packet containing a source address for which a binding >>>>> exists >>>>> and a different lower layer anchor is received, then the packet is >>>>> drop. >>>>> >>>>> If a data packet containing a source address for which no binding >>>>> exists >>>>> the data packet is forwarded and optionally logged. >>>>> >>>>> So what are the security properties of such a solution? >>>> Frank=>Logging flood could be exploited by malicious people >>>> for attacking. >>>> >>> sure, but i am not sure i see any other way to allow tracking back >>> attacks... >>> >>>>> >>>>> If a host starts using an address and performs the DAD procedure, then >>>>> no other host can use its address as a source address in data packets. >>>>> >>>>> An attacker can start using an address for which there is no binding. >>>>> In order for this address to be the address of another host, this >>>>> can only happen if the DAD packet was lost. I am not sure how >>>>> concerned >>>> Frank=>Rogue hosts could deliberately ignor DAD procedure. >>>> >>> so? what woudl the impact of this? >>> Frank=>Just a deliberate attack. >>> >> and the question is what is the impact of this attack? I fail to see any >> problem that is introduced by an attacker ignoring DAD packets >> >> Regards, marcelo >> >> >>>>> should we be about preventing this from attackers that have the >>>>> capability of disturbing DAD, I mean, if they are able to do that, >>>>> i guess they can launch worse attacks than spoof a source address. >>>> Frank=>I agree this philosophy. It is not necessary for us to have a >>>> perfect SAVI solution to deal with all the threats. At the same time, >>>> I prefer letting packet pass if we could not decide if it is a >>>> legitimate >>>> packet. >>>> >>> good >>> >>> regards, marcelo >>> >>>>> An attacker can use a given address from different lower layer >>>>> anchors. >>>>> I am not sure why this would be an attack though. As i said earlier >>>>> it would be possible for the SAVI device to log the occurrence of >>>>> these >>>>> packets and allow to trace back to the lower layer anchor. >>>>> >>>>> So, this option seems like a middle ground option with a somehow >>>>> reduced >>>>> level of security but with a low level of complexity and without >>>>> the possibility of disturbing the network behaviour by discarding >>>>> legitimate packets. >>>>> >>>>> Comments? >>>>> >>>>> Regards, marcelo >>>>> >>>>> >>>>> _______________________________________________ >>>>> savi mailing list >>>>> savi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/savi >>>> >>>> >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > From yaoa02@mails.tsinghua.edu.cn Mon Jun 15 23:39:18 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8B6E3A6916 for ; Mon, 15 Jun 2009 23:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oElUZn0sE0j1 for ; Mon, 15 Jun 2009 23:39:17 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id A5B523A679C for ; Mon, 15 Jun 2009 23:39:17 -0700 (PDT) Received: from th024139.ip.tsinghua.edu.cn ([59.66.24.139] helo=yaoguangPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1MGSK0-0003SD-8Z; Tue, 16 Jun 2009 14:39:04 +0800 From: "Guang Yao" To: "'marcelo bagnulo braun'" References: <4BDE4243-4EAC-4D81-B827-7ED8A55787BE@ericsson.com> <006901c9ed90$47b64190$d722c4b0$@tsinghua.edu.cn> <4A365F7E.8010302@it.uc3m.es> In-Reply-To: <4A365F7E.8010302@it.uc3m.es> Date: Tue, 16 Jun 2009 14:40:09 +0800 Message-ID: <002e01c9ee4d$4b4279b0$e1c76d10$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcntyID72NLrfmLPQzituAywgZNbFgAhDw7A Content-Language: zh-cn Cc: 'SAVI Mailing List' , 'Christian Vogt' Subject: Re: [savi] Your opinion on a different tradeoff for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 06:39:18 -0000 > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Sent: Monday, June 15, 2009 10:50 PM > To: Guang Yao > Cc: 'Christian Vogt'; 'SAVI Mailing List' > Subject: Re: [savi] Your opinion on a different tradeoff for SAVI >=20 > Guang Yao escribi=F3: > > Though [1] presents a novel idea, I'm not in favor of it because of = its > > lower filter capacity. > > >=20 > > Attackers are free to send packets with addresses other than local = bound > > ones. I'm not sure that the benefit is enough to encourage administrators to > > deploy, especially in a big network. > > > > > but in other solutions, the attacker can send a packet with any source > address for which there is no binding by simply sending a DAD packet > first, right? > So, what is the new vulnerability that is being introduced? >=20 > > Local bindings always are part of all the bindings in the network, because > > bindings are set up through DAD snooping, and DAD NS is a group cast > > message, not broad cast. Thus, attackers can still spoof the address = of > > another host as long as it is not bound on the savi device along the packet > > path. > > > right, but we can change that. I mean, we could simply require that = SAVI > devices snoop all MLD messages and that DAD packets are forwarded to = all > SAVI devices irrespectively whether there any host subscribed tot he > particular solicited node mcast group on that particular SAVI device. > That would essentially imply that all SAVI devices receive all DAD = msgs. > Would that solve the problem? [Guang Yao]=20 1 You have changed DAD, which violates the charter. 2 Problem is returned to that a savi device must have all the bindings = in the network. Then should we discuss the memory cost again? >=20 > Regards, marcelo >=20 >=20 > > However, I think it is a good step to find a final solution. > > > > Regards, > > Guang > > -----Original Message----- > > From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf = Of > > Christian Vogt > > Sent: Monday, June 15, 2009 11:22 AM > > To: SAVI Mailing List > > Subject: [savi] Your opinion on a different tradeoff for SAVI > > > > Folks - > > > > In order to make a decision on whether or not to move forward with = the > > modified SAVI protocol that Marcelo has proposed [1], feedback from = the > > working group is important. Several people have already provided = their > > feedback. I would encourage also others to share their opinion. = Please do > > so, on this mailing list, by Friday, June 19. > > > > Thank you. > > > > - Christian > > > > [1] http://www.ietf.org/mail-archive/web/savi/current/msg00654.html > > > > > > > > > > _______________________________________________ > > savi mailing list > > savi@ietf.org > > https://www.ietf.org/mailman/listinfo/savi > > > > From marcelo@it.uc3m.es Wed Jun 17 00:52:31 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F8283A6BCC for ; Wed, 17 Jun 2009 00:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.623 X-Spam-Level: X-Spam-Status: No, score=-6.623 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtEAeBlW-SB1 for ; Wed, 17 Jun 2009 00:52:30 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id D5DA43A6C6B for ; Wed, 17 Jun 2009 00:52:29 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (206.pool85-53-130.dynamic.orange.es [85.53.130.206]) by smtp02.uc3m.es (Postfix) with ESMTP id CAB466BA4CA; Wed, 17 Jun 2009 09:52:39 +0200 (CEST) Message-ID: <4A38A0C7.6010600@it.uc3m.es> Date: Wed, 17 Jun 2009 09:52:39 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Guang Yao References: <4BDE4243-4EAC-4D81-B827-7ED8A55787BE@ericsson.com> <006901c9ed90$47b64190$d722c4b0$@tsinghua.edu.cn> <4A365F7E.8010302@it.uc3m.es> <002e01c9ee4d$4b4279b0$e1c76d10$@tsinghua.edu.cn> In-Reply-To: <002e01c9ee4d$4b4279b0$e1c76d10$@tsinghua.edu.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16708.005 Cc: 'SAVI Mailing List' , 'Christian Vogt' Subject: Re: [savi] Your opinion on a different tradeoff for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 07:52:31 -0000 Guang Yao escribió: > >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: Monday, June 15, 2009 10:50 PM >> To: Guang Yao >> Cc: 'Christian Vogt'; 'SAVI Mailing List' >> Subject: Re: [savi] Your opinion on a different tradeoff for SAVI >> >> Guang Yao escribió: >> >>> Though [1] presents a novel idea, I'm not in favor of it because of its >>> lower filter capacity. >>> >>> >>> Attackers are free to send packets with addresses other than local bound >>> ones. I'm not sure that the benefit is enough to encourage >>> > administrators to > >>> deploy, especially in a big network. >>> >>> >>> >> but in other solutions, the attacker can send a packet with any source >> address for which there is no binding by simply sending a DAD packet >> first, right? >> So, what is the new vulnerability that is being introduced? >> >> >>> Local bindings always are part of all the bindings in the network, >>> > because > >>> bindings are set up through DAD snooping, and DAD NS is a group cast >>> message, not broad cast. Thus, attackers can still spoof the address of >>> another host as long as it is not bound on the savi device along the >>> > packet > >>> path. >>> >>> >> right, but we can change that. I mean, we could simply require that SAVI >> devices snoop all MLD messages and that DAD packets are forwarded to all >> SAVI devices irrespectively whether there any host subscribed tot he >> particular solicited node mcast group on that particular SAVI device. >> That would essentially imply that all SAVI devices receive all DAD msgs. >> Would that solve the problem? >> > [Guang Yao] > 1 You have changed DAD, which violates the charter. > how comes this changes DAD? this would change how MDL snooping siwtches handle DAD but not the DAD protocol How come this violates the charter? This would not requre any host change > 2 Problem is returned to that a savi device must have all the bindings in > the network. Then should we discuss the memory cost again? > i guess we should. Current switches contain a table with the list of MAC addresses they have learnt using reverse learning. The table required by SAVI would be in the same order of magnitude. If the MAC address table is not a problem for switches, why would this SAVI table be a problem for switches? Regards, marcelo >> Regards, marcelo >> >> >> >>> However, I think it is a good step to find a final solution. >>> >>> Regards, >>> Guang >>> -----Original Message----- >>> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of >>> Christian Vogt >>> Sent: Monday, June 15, 2009 11:22 AM >>> To: SAVI Mailing List >>> Subject: [savi] Your opinion on a different tradeoff for SAVI >>> >>> Folks - >>> >>> In order to make a decision on whether or not to move forward with the >>> modified SAVI protocol that Marcelo has proposed [1], feedback from the >>> working group is important. Several people have already provided their >>> feedback. I would encourage also others to share their opinion. Please >>> > do > >>> so, on this mailing list, by Friday, June 19. >>> >>> Thank you. >>> >>> - Christian >>> >>> [1] http://www.ietf.org/mail-archive/web/savi/current/msg00654.html >>> >>> >>> >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> >>> >>> > > > > From yaoa02@mails.tsinghua.edu.cn Wed Jun 17 01:21:01 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FF653A6DDB for ; Wed, 17 Jun 2009 01:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IT0ijTqYOrro for ; Wed, 17 Jun 2009 01:21:00 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id 63AE03A6DC3 for ; Wed, 17 Jun 2009 01:21:00 -0700 (PDT) Received: from th024139.ip.tsinghua.edu.cn ([59.66.24.139] helo=yaoguangPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1MGqO1-0004xW-8n; Wed, 17 Jun 2009 16:20:49 +0800 From: "Guang Yao" To: "'marcelo bagnulo braun'" References: <4BDE4243-4EAC-4D81-B827-7ED8A55787BE@ericsson.com> <006901c9ed90$47b64190$d722c4b0$@tsinghua.edu.cn> <4A365F7E.8010302@it.uc3m.es> <002e01c9ee4d$4b4279b0$e1c76d10$@tsinghua.edu.cn> <4A38A0C7.6010600@it.uc3m.es> In-Reply-To: <4A38A0C7.6010600@it.uc3m.es> Date: Wed, 17 Jun 2009 16:20:47 +0800 Message-ID: <001801c9ef24$842295d0$8c67c170$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Content-language: zh-cn Thread-Index: AcnvIJe11A6cDa5sQLe7MS95HAcsRgAAf0kw Cc: 'SAVI Mailing List' , 'Christian Vogt' Subject: Re: [savi] Your opinion on a different tradeoff for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 08:21:01 -0000 > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Sent: Wednesday, June 17, 2009 3:53 PM > To: Guang Yao > Cc: 'Christian Vogt'; 'SAVI Mailing List' > Subject: Re: [savi] Your opinion on a different tradeoff for SAVI >=20 > Guang Yao escribi=F3: > > > >> -----Original Message----- > >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > >> Sent: Monday, June 15, 2009 10:50 PM > >> To: Guang Yao > >> Cc: 'Christian Vogt'; 'SAVI Mailing List' > >> Subject: Re: [savi] Your opinion on a different tradeoff for SAVI > >> > >> Guang Yao escribi=F3: > >> > >>> Though [1] presents a novel idea, I'm not in favor of it because = of its > >>> lower filter capacity. > >>> > >>> > >>> Attackers are free to send packets with addresses other than local bound > >>> ones. I'm not sure that the benefit is enough to encourage > >>> > > administrators to > > > >>> deploy, especially in a big network. > >>> > >>> > >>> > >> but in other solutions, the attacker can send a packet with any = source > >> address for which there is no binding by simply sending a DAD = packet > >> first, right? > >> So, what is the new vulnerability that is being introduced? > >> > >> > >>> Local bindings always are part of all the bindings in the network, > >>> > > because > > > >>> bindings are set up through DAD snooping, and DAD NS is a group = cast > >>> message, not broad cast. Thus, attackers can still spoof the = address of > >>> another host as long as it is not bound on the savi device along = the > >>> > > packet > > > >>> path. > >>> > >>> > >> right, but we can change that. I mean, we could simply require that SAVI > >> devices snoop all MLD messages and that DAD packets are forwarded = to all > >> SAVI devices irrespectively whether there any host subscribed tot = he > >> particular solicited node mcast group on that particular SAVI = device. > >> That would essentially imply that all SAVI devices receive all DAD msgs. > >> Would that solve the problem? > >> > > [Guang Yao] > > 1 You have changed DAD, which violates the charter. > > > how comes this changes DAD? this would change how MDL snooping = siwtches > handle DAD but not the DAD protocol > How come this violates the charter? This would not requre any host = change [Guang Yao]=20 " DAD packets are forwarded to all SAVI devices irrespectively whether there any host subscribed tot he particular solicited node mcast group on that particular SAVI device." I think this is a big change. Charter also prohibit protocol change. >=20 > > 2 Problem is returned to that a savi device must have all the = bindings in > > the network. Then should we discuss the memory cost again? > > > i guess we should. Current switches contain a table with the list of = MAC > addresses they have learnt using reverse learning. The table required = by > SAVI would be in the same order of magnitude. If the MAC address table > is not a problem for switches, why would this SAVI table be a problem > for switches? [Guang Yao] Even with same order of magnitude, MAC addresses are far less than = possible IPv6 addresses for a interface is potentially to have multiple = addresses. And MAC address always has a more static number, but IP address has a = large range of number. This problem is even serious in an IP flooding attack. Another problem is current switch doesn't ensure it has all the MAC addresses. Sometimes the table may be full and it has to drop some = entry. It can handle the no-matching case by flooding. As to savi, can you drop any binding entry if the table is full? I don't think so. >=20 > Regards, marcelo >=20 >=20 > >> Regards, marcelo > >> > >> > >> > >>> However, I think it is a good step to find a final solution. > >>> > >>> Regards, > >>> Guang > >>> -----Original Message----- > >>> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On = Behalf Of > >>> Christian Vogt > >>> Sent: Monday, June 15, 2009 11:22 AM > >>> To: SAVI Mailing List > >>> Subject: [savi] Your opinion on a different tradeoff for SAVI > >>> > >>> Folks - > >>> > >>> In order to make a decision on whether or not to move forward with = the > >>> modified SAVI protocol that Marcelo has proposed [1], feedback = from the > >>> working group is important. Several people have already provided their > >>> feedback. I would encourage also others to share their opinion. Please > >>> > > do > > > >>> so, on this mailing list, by Friday, June 19. > >>> > >>> Thank you. > >>> > >>> - Christian > >>> > >>> [1] = http://www.ietf.org/mail-archive/web/savi/current/msg00654.html > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> savi mailing list > >>> savi@ietf.org > >>> https://www.ietf.org/mailman/listinfo/savi > >>> > >>> > >>> > > > > > > > > From marcelo@it.uc3m.es Wed Jun 17 07:13:14 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D569A28C25C for ; Wed, 17 Jun 2009 07:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIljN8OLSBAc for ; Wed, 17 Jun 2009 07:13:13 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 807873A6C93 for ; Wed, 17 Jun 2009 07:13:13 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap002.it.uc3m.es [163.117.139.44]) by smtp02.uc3m.es (Postfix) with ESMTP id 8D244656D5F; Wed, 17 Jun 2009 15:44:28 +0200 (CEST) Message-ID: <4A38F33D.7030109@it.uc3m.es> Date: Wed, 17 Jun 2009 15:44:29 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Guang Yao References: <4BDE4243-4EAC-4D81-B827-7ED8A55787BE@ericsson.com> <006901c9ed90$47b64190$d722c4b0$@tsinghua.edu.cn> <4A365F7E.8010302@it.uc3m.es> <002e01c9ee4d$4b4279b0$e1c76d10$@tsinghua.edu.cn> <4A38A0C7.6010600@it.uc3m.es> <001801c9ef24$842295d0$8c67c170$@tsinghua.edu.cn> In-Reply-To: <001801c9ef24$842295d0$8c67c170$@tsinghua.edu.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16710.000 Cc: 'SAVI Mailing List' , 'Christian Vogt' Subject: Re: [savi] Your opinion on a different tradeoff for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 14:13:14 -0000 Guang Yao escribió: > >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: Wednesday, June 17, 2009 3:53 PM >> To: Guang Yao >> Cc: 'Christian Vogt'; 'SAVI Mailing List' >> Subject: Re: [savi] Your opinion on a different tradeoff for SAVI >> >> Guang Yao escribió: >> >>>> -----Original Message----- >>>> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >>>> Sent: Monday, June 15, 2009 10:50 PM >>>> To: Guang Yao >>>> Cc: 'Christian Vogt'; 'SAVI Mailing List' >>>> Subject: Re: [savi] Your opinion on a different tradeoff for SAVI >>>> >>>> Guang Yao escribió: >>>> >>>> >>>>> Though [1] presents a novel idea, I'm not in favor of it because of >>>>> > its > >>>>> lower filter capacity. >>>>> >>>>> >>>>> Attackers are free to send packets with addresses other than local >>>>> > bound > >>>>> ones. I'm not sure that the benefit is enough to encourage >>>>> >>>>> >>> administrators to >>> >>> >>>>> deploy, especially in a big network. >>>>> >>>>> >>>>> >>>>> >>>> but in other solutions, the attacker can send a packet with any source >>>> address for which there is no binding by simply sending a DAD packet >>>> first, right? >>>> So, what is the new vulnerability that is being introduced? >>>> >>>> >>>> >>>>> Local bindings always are part of all the bindings in the network, >>>>> >>>>> >>> because >>> >>> >>>>> bindings are set up through DAD snooping, and DAD NS is a group cast >>>>> message, not broad cast. Thus, attackers can still spoof the address >>>>> > of > >>>>> another host as long as it is not bound on the savi device along the >>>>> >>>>> >>> packet >>> >>> >>>>> path. >>>>> >>>>> >>>>> >>>> right, but we can change that. I mean, we could simply require that >>>> > SAVI > >>>> devices snoop all MLD messages and that DAD packets are forwarded to >>>> > all > >>>> SAVI devices irrespectively whether there any host subscribed tot he >>>> particular solicited node mcast group on that particular SAVI device. >>>> That would essentially imply that all SAVI devices receive all DAD >>>> > msgs. > >>>> Would that solve the problem? >>>> >>>> >>> [Guang Yao] >>> 1 You have changed DAD, which violates the charter. >>> >>> >> how comes this changes DAD? this would change how MDL snooping siwtches >> handle DAD but not the DAD protocol >> How come this violates the charter? This would not requre any host change >> > [Guang Yao] > " DAD packets are forwarded to all > SAVI devices irrespectively whether there any host subscribed tot he > particular solicited node mcast group on that particular SAVI device." > > I think this is a big change. Charter also prohibit protocol change. > > this is not a protocol change, it is a change in the way mld snooping switches handle MLD packets, but i guess we won't agree on this >>> 2 Problem is returned to that a savi device must have all the bindings >>> > in > >>> the network. Then should we discuss the memory cost again? >>> >>> >> i guess we should. Current switches contain a table with the list of MAC >> addresses they have learnt using reverse learning. The table required by >> SAVI would be in the same order of magnitude. If the MAC address table >> is not a problem for switches, why would this SAVI table be a problem >> for switches? >> > [Guang Yao] > Even with same order of magnitude, MAC addresses are far less than possible > IPv6 addresses for a interface is potentially to have multiple addresses. > in the sense that the maximum number of MAC address is 2^48 while the max number of IPv6 addresses in a link is 2^64? I am not sure this really matters since they are both really big numbers and no table is expected to have all these entries > And MAC address always has a more static number, but IP address has a large > range of number. > I am not sure what do you mean and why does this matter > This problem is even serious in an IP flooding attack. > > Another problem is current switch doesn't ensure it has all the MAC > addresses. Sometimes the table may be full and it has to drop some entry. It > can > handle the no-matching case by flooding. > As to savi, can you drop any binding entry if the table is full? I don't > think so. > Well, it really depends on whether you are discarding if no entry is available or if you forward if no entry is available. Of course, if you discard, you cannot drop a binding entry If you forward, well, you are not blocking a legitimate user, so it is less harmfull if you drop and entry. In particular, i think that if the savi device is under attack, it is clear that the table will be full. So what can be done in that case? If you forward by defualt, you can drop the newer entries, so the attakc only affect the new entries and still you don't disconnect a legitimate from the netwrok,, while you don't protect them at least you don't block them. regards, marcelo >> Regards, marcelo >> >> >> >>>> Regards, marcelo >>>> >>>> >>>> >>>> >>>>> However, I think it is a good step to find a final solution. >>>>> >>>>> Regards, >>>>> Guang >>>>> -----Original Message----- >>>>> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf >>>>> > Of > >>>>> Christian Vogt >>>>> Sent: Monday, June 15, 2009 11:22 AM >>>>> To: SAVI Mailing List >>>>> Subject: [savi] Your opinion on a different tradeoff for SAVI >>>>> >>>>> Folks - >>>>> >>>>> In order to make a decision on whether or not to move forward with the >>>>> modified SAVI protocol that Marcelo has proposed [1], feedback from >>>>> > the > >>>>> working group is important. Several people have already provided >>>>> > their > >>>>> feedback. I would encourage also others to share their opinion. >>>>> > Please > >>> do >>> >>> >>>>> so, on this mailing list, by Friday, June 19. >>>>> >>>>> Thank you. >>>>> >>>>> - Christian >>>>> >>>>> [1] http://www.ietf.org/mail-archive/web/savi/current/msg00654.html >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> savi mailing list >>>>> savi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/savi >>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > > > From yaoa02@mails.tsinghua.edu.cn Wed Jun 17 21:45:46 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4DCC3A6F13 for ; Wed, 17 Jun 2009 21:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGiIrtWXmfkv for ; Wed, 17 Jun 2009 21:45:43 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id 584473A6EF2 for ; Wed, 17 Jun 2009 21:45:42 -0700 (PDT) Received: from th024139.ip.tsinghua.edu.cn ([59.66.24.139] helo=yaoguangPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1MH9VJ-0003Lc-S2; Thu, 18 Jun 2009 12:45:38 +0800 From: "Guang Yao" To: "'marcelo bagnulo braun'" References: <4BDE4243-4EAC-4D81-B827-7ED8A55787BE@ericsson.com> <006901c9ed90$47b64190$d722c4b0$@tsinghua.edu.cn> <4A365F7E.8010302@it.uc3m.es> <002e01c9ee4d$4b4279b0$e1c76d10$@tsinghua.edu.cn> <4A38A0C7.6010600@it.uc3m.es> <001801c9ef24$842295d0$8c67c170$@tsinghua.edu.cn> <4A38F33D.7030109@it.uc3m.es> In-Reply-To: <4A38F33D.7030109@it.uc3m.es> Date: Thu, 18 Jun 2009 12:45:35 +0800 Message-ID: <001701c9efcf$9e6fde10$db4f9a30$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnvUb2nWwxUiNfWTlerQKNPM5Sf/QAc4Cpw Content-Language: zh-cn Cc: 'SAVI Mailing List' , 'Christian Vogt' Subject: Re: [savi] Your opinion on a different tradeoff for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 04:45:46 -0000 > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Sent: Wednesday, June 17, 2009 9:44 PM > To: Guang Yao > Cc: 'Christian Vogt'; 'SAVI Mailing List' > Subject: Re: [savi] Your opinion on a different tradeoff for SAVI >=20 > Guang Yao escribi=F3: > > > >> -----Original Message----- > >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > >> Sent: Wednesday, June 17, 2009 3:53 PM > >> To: Guang Yao > >> Cc: 'Christian Vogt'; 'SAVI Mailing List' > >> Subject: Re: [savi] Your opinion on a different tradeoff for SAVI > >> > >> Guang Yao escribi=F3: > >> > >>>> -----Original Message----- > >>>> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > >>>> Sent: Monday, June 15, 2009 10:50 PM > >>>> To: Guang Yao > >>>> Cc: 'Christian Vogt'; 'SAVI Mailing List' > >>>> Subject: Re: [savi] Your opinion on a different tradeoff for SAVI > >>>> > >>>> Guang Yao escribi=F3: > >>>> > >>>> > >>>>> Though [1] presents a novel idea, I'm not in favor of it because = of > >>>>> > > its > > > >>>>> lower filter capacity. > >>>>> > >>>>> > >>>>> Attackers are free to send packets with addresses other than = local > >>>>> > > bound > > > >>>>> ones. I'm not sure that the benefit is enough to encourage > >>>>> > >>>>> > >>> administrators to > >>> > >>> > >>>>> deploy, especially in a big network. > >>>>> > >>>>> > >>>>> > >>>>> > >>>> but in other solutions, the attacker can send a packet with any source > >>>> address for which there is no binding by simply sending a DAD = packet > >>>> first, right? > >>>> So, what is the new vulnerability that is being introduced? > >>>> > >>>> > >>>> > >>>>> Local bindings always are part of all the bindings in the = network, > >>>>> > >>>>> > >>> because > >>> > >>> > >>>>> bindings are set up through DAD snooping, and DAD NS is a group = cast > >>>>> message, not broad cast. Thus, attackers can still spoof the = address > >>>>> > > of > > > >>>>> another host as long as it is not bound on the savi device along = the > >>>>> > >>>>> > >>> packet > >>> > >>> > >>>>> path. > >>>>> > >>>>> > >>>>> > >>>> right, but we can change that. I mean, we could simply require = that > >>>> > > SAVI > > > >>>> devices snoop all MLD messages and that DAD packets are forwarded = to > >>>> > > all > > > >>>> SAVI devices irrespectively whether there any host subscribed tot = he > >>>> particular solicited node mcast group on that particular SAVI = device. > >>>> That would essentially imply that all SAVI devices receive all = DAD > >>>> > > msgs. > > > >>>> Would that solve the problem? > >>>> > >>>> > >>> [Guang Yao] > >>> 1 You have changed DAD, which violates the charter. > >>> > >>> > >> how comes this changes DAD? this would change how MDL snooping > siwtches > >> handle DAD but not the DAD protocol > >> How come this violates the charter? This would not requre any host change > >> > > [Guang Yao] > > " DAD packets are forwarded to all > > SAVI devices irrespectively whether there any host subscribed tot he > > particular solicited node mcast group on that particular SAVI = device." > > > > I think this is a big change. Charter also prohibit protocol change. > > > > >=20 > this is not a protocol change, it is a change in the way mld snooping > switches handle MLD packets, but i guess we won't agree on this > >>> 2 Problem is returned to that a savi device must have all the = bindings > >>> > > in > > > >>> the network. Then should we discuss the memory cost again? > >>> > >>> > >> i guess we should. Current switches contain a table with the list = of MAC > >> addresses they have learnt using reverse learning. The table = required by > >> SAVI would be in the same order of magnitude. If the MAC address = table > >> is not a problem for switches, why would this SAVI table be a = problem > >> for switches? > >> > > [Guang Yao] > > Even with same order of magnitude, MAC addresses are far less than > possible > > IPv6 addresses for a interface is potentially to have multiple addresses. > > >=20 > in the sense that the maximum number of MAC address is 2^48 while the > max number of IPv6 addresses in a link is 2^64? >=20 > I am not sure this really matters since they are both really big = numbers > and no table is expected to have all these entries [Guang Yao]=20 If there are 100 hosts(single interface) in the network, the total = number of MAC address is around 100. However, the total number of IPv6 address is 100*N. N is the average = value of the address number per interface. Generally, N>=3D2, and has a huge upper bound.=20 I have checked my host and it has 6 IPv6 addresses. I think the value of = N will be larger when IPv6 get used more widely. I don't think it is reasonable to declare N will be less than 10 in the future. In case N is larger than 10 in a network, the situation will be very different. >=20 > > And MAC address always has a more static number, but IP address has = a > large > > range of number. > > >=20 > I am not sure what do you mean and why does this matter >=20 > > This problem is even serious in an IP flooding attack. > > > > Another problem is current switch doesn't ensure it has all the MAC > > addresses. Sometimes the table may be full and it has to drop some entry. It > > can > > handle the no-matching case by flooding. > > As to savi, can you drop any binding entry if the table is full? I = don't > > think so. > > > Well, it really depends on whether you are discarding if no entry is > available or if you forward if no entry is available. > Of course, if you discard, you cannot drop a binding entry > If you forward, well, you are not blocking a legitimate user, so it is > less harmfull if you drop and entry. [Guang Yao]=20 Well, I agree to drop bindings in forwarding model will not block = legitimate user. Actually, if there are no bindings, legitimate user will never be = blocked. Because any binding, which is set up on unreliable DAD, is potentially = to discard legitimate packet, it is better that there are no bindings. Then, if SAVI is intent to let legitimate packets never be discarded, current network is working well. So why we need SAVI? I think there are two targets in SAVI: False positive: To which ratio the legitimate packets are discarded. False negative: To which ratio the illegal packets are discarded. If a "NULL" method is designed, it has a perfect false positive. But it = has no sense. On the other hand, if a "DROP ALL" method is designed, it has a perfect false negative, still it has no sense. Although we have a clear target that false positive must be 0, we don't = have a clear target on the false negative. So, I think it is important to set a clear false negative target. 100%? = Or 10%? Or not specified? > In particular, i think that if the savi device is under attack, it is > clear that the table will be full. So what can be done in that case? = If > you forward by defualt, you can drop the newer entries, so the attakc > only affect the new entries and still you don't disconnect a = legitimate > from the netwrok,, while you don't protect them at least you don't = block > them. >=20 [Guang Yao]=20 I think, if a switch port is attached by a host, the upper bound of the address number can be set to a reasonable value to avoid DoS. Then there will be no dropping problem. The problem is that = when the bindings are also set up for other kinds of port, the switch is not clear how many hosts are there and can not set the = upper bound for that port. Thus I suggest not set up bindings for other kinds of port, but just use local bindings to drop collision packets from these ports. > regards, marcelo >=20 > >> Regards, marcelo > >> > >> > >> > >>>> Regards, marcelo > >>>> > >>>> > >>>> > >>>> > >>>>> However, I think it is a good step to find a final solution. > >>>>> > >>>>> Regards, > >>>>> Guang > >>>>> -----Original Message----- > >>>>> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On = Behalf > >>>>> > > Of > > > >>>>> Christian Vogt > >>>>> Sent: Monday, June 15, 2009 11:22 AM > >>>>> To: SAVI Mailing List > >>>>> Subject: [savi] Your opinion on a different tradeoff for SAVI > >>>>> > >>>>> Folks - > >>>>> > >>>>> In order to make a decision on whether or not to move forward = with the > >>>>> modified SAVI protocol that Marcelo has proposed [1], feedback = from > >>>>> > > the > > > >>>>> working group is important. Several people have already = provided > >>>>> > > their > > > >>>>> feedback. I would encourage also others to share their opinion. > >>>>> > > Please > > > >>> do > >>> > >>> > >>>>> so, on this mailing list, by Friday, June 19. > >>>>> > >>>>> Thank you. > >>>>> > >>>>> - Christian > >>>>> > >>>>> [1] = http://www.ietf.org/mail-archive/web/savi/current/msg00654.html > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> savi mailing list > >>>>> savi@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/savi > >>>>> > >>>>> > >>>>> > >>>>> > >>> > >>> > >>> > > > > > > > > From christian.vogt@ericsson.com Tue Jun 23 15:57:58 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E7BC3A6996 for ; Tue, 23 Jun 2009 15:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.439 X-Spam-Level: X-Spam-Status: No, score=-6.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcdiQBYoxuKQ for ; Tue, 23 Jun 2009 15:57:57 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 8F06B3A6936 for ; Tue, 23 Jun 2009 15:57:57 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n5NMwBeH001658; Tue, 23 Jun 2009 17:58:12 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jun 2009 17:58:11 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jun 2009 17:58:10 -0500 Message-Id: <86861CC6-385A-4CBA-9B9C-5D7E56EF119B@ericsson.com> From: Christian Vogt To: Eric Levy-Abegnoli In-Reply-To: <4A35ECEE.7060801@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 23 Jun 2009 15:58:11 -0700 References: <4A2C0DFB.3040803@it.uc3m.es> <4A2D2221.4030503@cisco.com> <4A2D2739.1000206@it.uc3m.es> <4A2F9E29.5070704@cisco.com> <4A30D6CD.8060209@it.uc3m.es> <49417952-8570-467E-B312-B759DC3D88DD@ericsson.com> <4A35ECEE.7060801@cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 23 Jun 2009 22:58:10.0879 (UTC) FILETIME=[14B8CCF0:01C9F456] Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 22:57:58 -0000 On June 14, 2009, Eric Levy-Abegnoli wrote: > I am a bit confused here, or maybe I lack some background of previous > discussions. Look to me there is a tradeoff; almost an antagonism > between prefering the first binding (hence the first packet carrying > this binding) and allowing nodes to defend their address. It's pretty > trivial for the attacker to listen to the DAD from his victim, and > answer as soon as he sees it. And then take ownership of the binding > if > I read you correctly. Eric - Are you still talking about an attack that SAVI is trying to prevent? You are talking about an attack that keeps a host from configuring a particular IP address, not an attack in which this IP address is spoofed. This attack is inherent in DAD, as Marcelo mentioned. But it is not an attack that SAVI was chartered to prevent. Now, I understand that your intention is to augment SAVI to also protect DAD. Can you clarify how your proposed mechanism would work? And what would be the cost in terms of extra implementation or administration complexity? (I think you should start a new discussion thread for this, since it seems to be independent of the adoption of Marcelo's proposed FCFS variant.) > So did this group agree that the DAD responder should have his binding > preferred over the DAD sender? If so, how can this be an anti-spoofing > protection mechanism? I am unsure if I understand you. DAD responses do not create SAVI bindings. They can only prevent another binding from being created, and this only if they correspond to an existing binding themselves. If they do not correspond to an existing binding themselves, they are dropped by a SAVI device. The only way to create a SAVI binding is by sending a DAD solicitation or by a DHCP address assignment. - Christian From christian.vogt@ericsson.com Tue Jun 23 16:07:13 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509343A6BBE for ; Tue, 23 Jun 2009 16:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKWxR3wML7v6 for ; Tue, 23 Jun 2009 16:07:12 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 930493A6857 for ; Tue, 23 Jun 2009 16:07:12 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n5NN6nDX005409; Tue, 23 Jun 2009 18:06:49 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jun 2009 18:06:49 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jun 2009 18:06:49 -0500 Message-Id: From: Christian Vogt To: Fred Baker In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 23 Jun 2009 16:06:50 -0700 References: <4BDE4243-4EAC-4D81-B827-7ED8A55787BE@ericsson.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 23 Jun 2009 23:06:49.0247 (UTC) FILETIME=[49B17AF0:01C9F457] Cc: SAVI Mailing List Subject: Re: [savi] Your opinion on a different tradeoff for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 23:07:13 -0000 On Jun 14, 2009, Fred Baker wrote: > A change of charter is also important. Fred - Why do you think the current charter is insufficient? Are you referring to the following charter statement? The purpose of the proposed "Source Address Validation Improvements" working group is to standardize mechanisms that prevent nodes attached to the same IP link from spoofing each other's IP addresses. If so, note that Marcelo's proposed FCFS variant does comply with this charter statement because it only changes the bahavior of a SAVI device for unused IP addresses. Above charter statement, in turn, is about IP addresses being used by a link neighbor. If you are referring to a different charter statement, which one? - Christian From fred@cisco.com Tue Jun 23 16:39:09 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE1253A6D1D for ; Tue, 23 Jun 2009 16:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.503 X-Spam-Level: X-Spam-Status: No, score=-106.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WO235VdMF7rr for ; Tue, 23 Jun 2009 16:39:09 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0DE7D3A6A7C for ; Tue, 23 Jun 2009 16:39:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,278,1243814400"; d="scan'208";a="330453216" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 23 Jun 2009 23:39:25 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5NNdPLM031707; Tue, 23 Jun 2009 16:39:25 -0700 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5NNdPCD006371; Tue, 23 Jun 2009 23:39:25 GMT Message-Id: <01868972-72D9-4B00-99FA-9ED543BE3703@cisco.com> From: Fred Baker To: Christian Vogt In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 23 Jun 2009 16:39:22 -0700 References: <4BDE4243-4EAC-4D81-B827-7ED8A55787BE@ericsson.com> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1552; t=1245800365; x=1246664365; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[savi]=20Your=20opinion=20on=20a=20diff erent=20tradeoff=20for=20SAVI |Sender:=20; bh=+ATkwgG3SgFxHho+KeQo8cDkDjt5BUYBZYcivHVr9OQ=; b=1jscLuwm7/kMyD9gr8zX7AFt5qCyZovfliQw2fnKrqXHa+tJzXpYI5qU3o bj05iBwrCpKMCRjxFLeISkCDn8W/3vLJ0ovqA1tB7JkpilPS8oaazzaGNWra nEcoFV5qCC; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: SAVI Mailing List Subject: Re: [savi] Your opinion on a different tradeoff for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 23:39:09 -0000 I think you are talking about writing a protocol for address binding, and the charter says > - The WG is prohibited from creating its own protocols or extensions/ > modifications of current protocols. I don't consider the current charter insufficient. I consider that before the working group even met the working group started considering something that it was told in its charter to not do, spent at least one entire interim meeting on the subject, and included it in the agenda of its first formal meeting. If you want that badly to work on something you agreed in writing your charter to not do, I think you need to change your charter. On Jun 23, 2009, at 4:06 PM, Christian Vogt wrote: > > On Jun 14, 2009, Fred Baker wrote: > >> A change of charter is also important. > > > > Fred - > > Why do you think the current charter is insufficient? Are you > referring > to the following charter statement? > > The purpose of the proposed "Source Address Validation Improvements" > working group is to standardize mechanisms that prevent nodes > attached > to the same IP link from spoofing each other's IP addresses. > > If so, note that Marcelo's proposed FCFS variant does comply with this > charter statement because it only changes the bahavior of a SAVI > device > for unused IP addresses. Above charter statement, in turn, is about > IP > addresses being used by a link neighbor. If you are referring to a > different charter statement, which one? > > - Christian > > From christian.vogt@ericsson.com Tue Jun 23 16:40:59 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DC463A6D4D for ; Tue, 23 Jun 2009 16:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFoPGStJKskm for ; Tue, 23 Jun 2009 16:40:58 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 9641A3A6D1D for ; Tue, 23 Jun 2009 16:40:58 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n5NNfDpv018857; Tue, 23 Jun 2009 18:41:13 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jun 2009 18:41:13 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jun 2009 18:41:12 -0500 Message-Id: <3973B2C2-CEFA-48D1-A0FE-B27FB0B0C1CD@ericsson.com> From: Christian Vogt To: Guang Yao In-Reply-To: <006901c9ed90$47b64190$d722c4b0$@tsinghua.edu.cn> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 23 Jun 2009 16:41:13 -0700 References: <4BDE4243-4EAC-4D81-B827-7ED8A55787BE@ericsson.com> <006901c9ed90$47b64190$d722c4b0$@tsinghua.edu.cn> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 23 Jun 2009 23:41:13.0034 (UTC) FILETIME=[17CE62A0:01C9F45C] Cc: SAVI Mailing List Subject: Re: [savi] Your opinion on a different tradeoff for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 23:40:59 -0000 Guang - > Attackers are free to send packets with addresses other than local > bound > ones. I'm not sure that the benefit is enough to encourage > administrators to deploy, especially in a big network. It is true that Marcelo's proposed FCFS variant does not protect unused addresses. It only protects addresses being used by a link neighbor. But don't you think this alone is attractive? I personally claim that it is, in particular since, in IPv6, there is not much point in protecting unused addresses: It is trivial for an attacker to turn an unused addresses into its own address. All is needed is a DAD solicitation. - Christian From christian.vogt@ericsson.com Tue Jun 23 16:44:07 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 174413A681C for ; Tue, 23 Jun 2009 16:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.476 X-Spam-Level: X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGwl-x6GxAbc for ; Tue, 23 Jun 2009 16:44:06 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id BAAE128C2D1 for ; Tue, 23 Jun 2009 16:43:57 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n5NNiDiw016139; Tue, 23 Jun 2009 18:44:13 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jun 2009 18:44:12 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jun 2009 18:44:12 -0500 Message-Id: <9129FB66-4564-4EC2-891F-B03EB01A1156@ericsson.com> From: Christian Vogt To: Marcelo Bagnulo Braun , Guang Yao In-Reply-To: <4A365F7E.8010302@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 23 Jun 2009 16:44:13 -0700 References: <4BDE4243-4EAC-4D81-B827-7ED8A55787BE@ericsson.com> <006901c9ed90$47b64190$d722c4b0$@tsinghua.edu.cn> <4A365F7E.8010302@it.uc3m.es> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 23 Jun 2009 23:44:12.0594 (UTC) FILETIME=[82D51120:01C9F45C] Cc: SAVI Mailing List Subject: Re: [savi] Your opinion on a different tradeoff for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 23:44:07 -0000 On Jun 15, 2009, Guang and Marcelo wrote: >> Local bindings always are part of all the bindings in the network, >> because bindings are set up through DAD snooping, and DAD NS is a >> group >> cast message, not broad cast. Thus, attackers can still spoof the >> address of another host as long as it is not bound on the savi device >> along the packet path. > > right, but we can change that. I mean, we could simply require that > SAVI > devices snoop all MLD messages and that DAD packets are forwarded to > all > SAVI devices irrespectively whether there any host subscribed tot he > particular solicited node mcast group on that particular SAVI device. > That would essentially imply that all SAVI devices receive all DAD > msgs. > Would that solve the problem? Do we really have to forward all DAD solicitations to solve the problem? Is there a problem to begin with? I don't see why lack of a binding in a SAVI device would help an attacker hijacking an address. After all, a SAVI binding can only be created with a DAD solicitation that receives no response. So even if a SAVI device did not see the DAD solicitation of the legitimate address owner, it will see the DAD response of the legitimate address owner in case an attacker is trying to hijack that owner's address. - Christian From christian.vogt@ericsson.com Tue Jun 23 16:46:52 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F13CE28C39F for ; Tue, 23 Jun 2009 16:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-sAreQt4jBm for ; Tue, 23 Jun 2009 16:46:52 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 427D328C351 for ; Tue, 23 Jun 2009 16:46:52 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n5NNkgti021273; Tue, 23 Jun 2009 18:46:42 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jun 2009 18:46:42 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jun 2009 18:46:42 -0500 Message-Id: <1D122CC0-76E3-4F72-B995-B1378B52461C@ericsson.com> From: Christian Vogt To: Fred Baker In-Reply-To: <01868972-72D9-4B00-99FA-9ED543BE3703@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 23 Jun 2009 16:46:43 -0700 References: <4BDE4243-4EAC-4D81-B827-7ED8A55787BE@ericsson.com> <01868972-72D9-4B00-99FA-9ED543BE3703@cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 23 Jun 2009 23:46:42.0186 (UTC) FILETIME=[DBFEFEA0:01C9F45C] Cc: SAVI Mailing List Subject: Re: [savi] Your opinion on a different tradeoff for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 23:46:53 -0000 On Jun 23, 2009, Fred Baker wrote: > I think you are talking about writing a protocol for address > binding... No we are not. On the contrary: The proposed FCFS variant we are talking about has the potential to avoid the need for any extra binding distribution/verification protocol. - Christian From fred@cisco.com Tue Jun 23 16:48:31 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7993928C3BD for ; Tue, 23 Jun 2009 16:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.507 X-Spam-Level: X-Spam-Status: No, score=-106.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYaPkXqngqMX for ; Tue, 23 Jun 2009 16:48:30 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6D79528C33E for ; Tue, 23 Jun 2009 16:48:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,278,1243814400"; d="scan'208";a="204665719" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 23 Jun 2009 23:48:45 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5NNmkT7010938; Tue, 23 Jun 2009 16:48:46 -0700 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5NNmk3O012115; Tue, 23 Jun 2009 23:48:46 GMT Message-Id: <2EC11997-A958-4639-A661-79FFA977ABC1@cisco.com> From: Fred Baker To: Christian Vogt In-Reply-To: <9129FB66-4564-4EC2-891F-B03EB01A1156@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 23 Jun 2009 16:48:46 -0700 References: <4BDE4243-4EAC-4D81-B827-7ED8A55787BE@ericsson.com> <006901c9ed90$47b64190$d722c4b0$@tsinghua.edu.cn> <4A365F7E.8010302@it.uc3m.es> <9129FB66-4564-4EC2-891F-B03EB01A1156@ericsson.com> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2264; t=1245800926; x=1246664926; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[savi]=20Your=20opinion=20on=20a=20diff erent=20tradeoff=20for=20SAVI |Sender:=20; bh=Vr7YVex0KIBKFvOIL84Mhxo0WbNLjJXiekHvzHa3kIY=; b=IGrcqgTMdUNuLk2+xlJyeWwvNKEN0x/q1Yynsj8imYhgtW5ikvrbK1muWC tU1+bdimKaJKUlSQJjc/E4FixJef763IBwr0Y6Zjyy/iOpq0+nvPzW2qadmX Hk55Yzffbp; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: SAVI Mailing List , Guang Yao Subject: Re: [savi] Your opinion on a different tradeoff for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 23:48:31 -0000 I remain of the opinion that a switch is able to prevent its own clients from using addresses they have not been assigned, and that this is sufficient for a network of SAVI devices. The costs of a switch escalate if it has to have memory for devices that are not its clients, meaning that SAVI is unlikely to get market traction in this very cost-sensitive market if we force the switches to have large memories. the primary argument for a binding protocol is that there might be some non-savi devices in the network. I think the simpler solution is to tell people that they don't get the benefits of SAVI in that environment. On Jun 23, 2009, at 4:44 PM, Christian Vogt wrote: > On Jun 15, 2009, Guang and Marcelo wrote: > >>> Local bindings always are part of all the bindings in the network, >>> because bindings are set up through DAD snooping, and DAD NS is a >>> group >>> cast message, not broad cast. Thus, attackers can still spoof the >>> address of another host as long as it is not bound on the savi >>> device >>> along the packet path. >> >> right, but we can change that. I mean, we could simply require that >> SAVI >> devices snoop all MLD messages and that DAD packets are forwarded >> to all >> SAVI devices irrespectively whether there any host subscribed tot he >> particular solicited node mcast group on that particular SAVI device. >> That would essentially imply that all SAVI devices receive all DAD >> msgs. >> Would that solve the problem? > > > Do we really have to forward all DAD solicitations to solve the > problem? > Is there a problem to begin with? I don't see why lack of a binding > in > a SAVI device would help an attacker hijacking an address. > > After all, a SAVI binding can only be created with a DAD solicitation > that receives no response. So even if a SAVI device did not see the > DAD > solicitation of the legitimate address owner, it will see the DAD > response of the legitimate address owner in case an attacker is > trying to > hijack that owner's address. > > - Christian > > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From fred@cisco.com Tue Jun 23 16:51:08 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C876E28C3A2 for ; Tue, 23 Jun 2009 16:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.511 X-Spam-Level: X-Spam-Status: No, score=-106.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vo7Ps0C00WoT for ; Tue, 23 Jun 2009 16:51:08 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id F120728C33E for ; Tue, 23 Jun 2009 16:51:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,278,1243814400"; d="scan'208";a="82528104" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 23 Jun 2009 23:51:24 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n5NNpOUN019625; Tue, 23 Jun 2009 16:51:24 -0700 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n5NNpOPo029390; Tue, 23 Jun 2009 23:51:24 GMT Message-Id: From: Fred Baker To: Christian Vogt In-Reply-To: <3973B2C2-CEFA-48D1-A0FE-B27FB0B0C1CD@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 23 Jun 2009 16:51:23 -0700 References: <4BDE4243-4EAC-4D81-B827-7ED8A55787BE@ericsson.com> <006901c9ed90$47b64190$d722c4b0$@tsinghua.edu.cn> <3973B2C2-CEFA-48D1-A0FE-B27FB0B0C1CD@ericsson.com> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=682; t=1245801084; x=1246665084; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[savi]=20Your=20opinion=20on=20a=20diff erent=20tradeoff=20for=20SAVI |Sender:=20; bh=c8rq+pKIotUOqMG3z0d8DuZGnWgU1jFYnxhwV01e5Sk=; b=PeVo6dLKy7egE/Qq6qt0P0db5jAl6v8RX+26myU0izfytE1MzfmPzw+2LC 3DndrKUNUpHXuq2G9i80vNTKl9wIxcicOHz+m0IOUWnDIpLptlqWduipl7eF z0m2msXccq; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: SAVI Mailing List , Guang Yao Subject: Re: [savi] Your opinion on a different tradeoff for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 23:51:08 -0000 On Jun 23, 2009, at 4:41 PM, Christian Vogt wrote: > It is true that Marcelo's proposed FCFS variant does not protect > unused > addresses. It only protects addresses being used by a link neighbor. > But don't you think this alone is attractive? no, not at all. On a given /64 LAN, there are O(2^64) potential addresses that are not being used. The 5 or 8 or 24 or maybe 4096 that are being used are nil by comparison. The objective is not only to prevent hosts from spoofing each other, but to provide a BCP 38 solution that forces them to in fact use addresses they are supposed to be using. SAVI without protecting unused addresses is pointless. From christian.vogt@ericsson.com Tue Jun 23 17:28:13 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E8DF28C431 for ; Tue, 23 Jun 2009 17:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3+0xKE0ngvD for ; Tue, 23 Jun 2009 17:28:11 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 20B5828C435 for ; Tue, 23 Jun 2009 17:28:04 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n5O0SIaZ008387; Tue, 23 Jun 2009 19:28:18 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jun 2009 19:28:17 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jun 2009 19:28:17 -0500 Message-Id: <6026EA38-2F5B-4C51-9B9D-6139EBE10F71@ericsson.com> From: Christian Vogt To: Fred Baker In-Reply-To: <2EC11997-A958-4639-A661-79FFA977ABC1@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 23 Jun 2009 17:28:18 -0700 References: <4BDE4243-4EAC-4D81-B827-7ED8A55787BE@ericsson.com> <006901c9ed90$47b64190$d722c4b0$@tsinghua.edu.cn> <4A365F7E.8010302@it.uc3m.es> <9129FB66-4564-4EC2-891F-B03EB01A1156@ericsson.com> <2EC11997-A958-4639-A661-79FFA977ABC1@cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 24 Jun 2009 00:28:17.0169 (UTC) FILETIME=[AB1F3010:01C9F462] Cc: Guang Yao , SAVI Mailing List Subject: Re: [savi] Your opinion on a different tradeoff for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 00:28:13 -0000 On Jun 23, 2009, Fred Baker wrote: > I remain of the opinion that a switch is able to prevent its own > clients > from using addresses they have not been assigned, and that this is > sufficient for a network of SAVI devices. The costs of a switch > escalate > if it has to have memory for devices that are not its clients, meaning > that SAVI is unlikely to get market traction in this very cost- > sensitive > market if we force the switches to have large memories. Fred - The FCFS variant we are considering exactly addresses your concern: Since lack of a binding cannot lead to false packet drops, bindings do not have to be explicitly copied across SAVI devices. This reduces memory requirements. In particular, bindings for a given address are only created in SAVI devices on the path of the corresponding DAD solicitation or DHCP address assignment. The number of bindings for a given address can be reduced further by manually disabling SAVI protection on large port trunks. > the primary argument for a binding protocol is that there might be > some > non-savi devices in the network. I think the simpler solution is to > tell > people that they don't get the benefits of SAVI in that environment. FWIW: The main argument is actually the prevention of false packet drops. This affects SAVI solutions that drop packets in the absence of a binding. A dedicated binding protocol can then ensure that the necessary bindings are in place, hence avoiding false packet drops. Since Marcelo's proposed FCFS variant does NOT drop packets in the absence of a binding, I don't see the need for a dedicated binding protocol. This is what I am explaining in my message below. - Christian On Jun 23, 2009, Christian Vogt wrote: >>> Local bindings always are part of all the bindings in the network, >>> because bindings are set up through DAD snooping, and DAD NS is a >>> group >>> cast message, not broad cast. Thus, attackers can still spoof the >>> address of another host as long as it is not bound on the savi >>> device >>> along the packet path. >>> >>> right, but we can change that. I mean, we could simply require >>> that SAVI >>> devices snoop all MLD messages and that DAD packets are forwarded >>> to all >>> SAVI devices irrespectively whether there any host subscribed tot he >>> particular solicited node mcast group on that particular SAVI >>> device. >>> That would essentially imply that all SAVI devices receive all DAD >>> msgs. >>> Would that solve the problem? >> >> >> Do we really have to forward all DAD solicitations to solve the >> problem? >> Is there a problem to begin with? I don't see why lack of a >> binding in >> a SAVI device would help an attacker hijacking an address. >> >> After all, a SAVI binding can only be created with a DAD solicitation >> that receives no response. So even if a SAVI device did not see >> the DAD >> solicitation of the legitimate address owner, it will see the DAD >> response of the legitimate address owner in case an attacker is >> trying >> to hijack that owner's address. >> >> - Christian From christian.vogt@ericsson.com Tue Jun 23 19:05:34 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2001C3A6F07 for ; Tue, 23 Jun 2009 19:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8Yg-fEveJ6C for ; Tue, 23 Jun 2009 19:05:33 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 5CAC93A6EEE for ; Tue, 23 Jun 2009 19:05:33 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n5O25aeD027742; Tue, 23 Jun 2009 21:05:37 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jun 2009 21:05:36 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jun 2009 21:05:35 -0500 From: Christian Vogt To: Frank Xia In-Reply-To: <001901c9edda$ff5bceb0$3e0c7c0a@china.huawei.com> X-Priority: 3 References: <4A2C0DFB.3040803@it.uc3m.es> <00e301c9edcf$c7cc7bd0$3e0c7c0a@china.huawei.com> <4A36706D.9050501@it.uc3m.es> <001901c9edda$ff5bceb0$3e0c7c0a@china.huawei.com> Message-Id: <4ECD61DE-172E-486D-A9DC-948DB322D565@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 23 Jun 2009 19:05:36 -0700 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 24 Jun 2009 02:05:35.0807 (UTC) FILETIME=[4338A4F0:01C9F470] Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 02:05:34 -0000 On Jun 15, 2009, Frank Xia wrote: > DAD is NOT a MUST for stateless address configuration. RFC 4862 reads > > "By default, all addresses should be tested for uniqueness prior to > their assignment to an interface for safety. The test should > individually be performed on all addresses obtained manually, via > stateless address autoconfiguration, or via DHCPv6. To accommodate > sites that believe the overhead of performing Duplicate Address > Detection outweighs its benefits, the use of Duplicate Address > Detection can be disabled through the administrative setting of a > per-interface configuration flag." Isn't this just another reason to forward packets in the absence of a binding, rather than discarding them? I see this in support of the proposed FCFS variant. - Christian From xiayangsong@huawei.com Tue Jun 23 19:55:18 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E78E3A6A1A for ; Tue, 23 Jun 2009 19:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.775 X-Spam-Level: X-Spam-Status: No, score=-1.775 tagged_above=-999 required=5 tests=[AWL=0.824, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oty0X2K0ontx for ; Tue, 23 Jun 2009 19:55:17 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 8D6EB3A68A7 for ; Tue, 23 Jun 2009 19:55:17 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLQ00IW42SKDU@szxga03-in.huawei.com> for savi@ietf.org; Wed, 24 Jun 2009 10:55:32 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLQ00M3O2SK78@szxga03-in.huawei.com> for savi@ietf.org; Wed, 24 Jun 2009 10:55:32 +0800 (CST) Received: from X24512z ([10.51.0.162]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLQ00FYO2RUJH@szxml04-in.huawei.com> for savi@ietf.org; Wed, 24 Jun 2009 10:55:32 +0800 (CST) Date: Tue, 23 Jun 2009 21:55:03 -0500 From: Frank Xia To: Christian Vogt Message-id: <00c401c9f477$360829c0$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4A2C0DFB.3040803@it.uc3m.es> <00e301c9edcf$c7cc7bd0$3e0c7c0a@china.huawei.com> <4A36706D.9050501@it.uc3m.es> <001901c9edda$ff5bceb0$3e0c7c0a@china.huawei.com> <4ECD61DE-172E-486D-A9DC-948DB322D565@ericsson.com> Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 02:55:18 -0000 Hi Christian Yes. My another observation is that people only talk about DAD defined in RFC4862 while ignoring Optimistic DAD defined in RFC4429 which let go data traffic preceding control message BR Frank ----- Original Message ----- From: "Christian Vogt" To: "Frank Xia" Cc: "SAVI Mailing List" Sent: Tuesday, June 23, 2009 9:05 PM Subject: Re: [savi] A different trade off for SAVI > > On Jun 15, 2009, Frank Xia wrote: > >> DAD is NOT a MUST for stateless address configuration. RFC 4862 reads >> >> "By default, all addresses should be tested for uniqueness prior to >> their assignment to an interface for safety. The test should >> individually be performed on all addresses obtained manually, via >> stateless address autoconfiguration, or via DHCPv6. To accommodate >> sites that believe the overhead of performing Duplicate Address >> Detection outweighs its benefits, the use of Duplicate Address >> Detection can be disabled through the administrative setting of a >> per-interface configuration flag." > > Isn't this just another reason to forward packets in the absence of a > binding, rather than discarding them? I see this in support of the > proposed FCFS variant. > > - Christian > > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From fred@cisco.com Tue Jun 23 20:01:00 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59E5728C2F6 for ; Tue, 23 Jun 2009 20:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.515 X-Spam-Level: X-Spam-Status: No, score=-106.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfrnZo-fLu-x for ; Tue, 23 Jun 2009 20:00:59 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id AD6C53A6A1A for ; Tue, 23 Jun 2009 20:00:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,279,1243814400"; d="scan'208";a="330539171" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 24 Jun 2009 03:01:15 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n5O31FgV024872; Tue, 23 Jun 2009 20:01:15 -0700 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n5O31FYA001749; Wed, 24 Jun 2009 03:01:15 GMT From: Fred Baker To: Frank Xia In-Reply-To: <00c401c9f477$360829c0$3e0c7c0a@china.huawei.com> X-Priority: 3 References: <4A2C0DFB.3040803@it.uc3m.es> <00e301c9edcf$c7cc7bd0$3e0c7c0a@china.huawei.com> <4A36706D.9050501@it.uc3m.es> <001901c9edda$ff5bceb0$3e0c7c0a@china.huawei.com> <4ECD61DE-172E-486D-A9DC-948DB322D565@ericsson.com> <00c401c9f477$360829c0$3e0c7c0a@china.huawei.com> Message-Id: <37141A82-4193-4142-ACCD-BB857C8DCAB3@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 23 Jun 2009 20:01:14 -0700 X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2177; t=1245812475; x=1246676475; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[savi]=20A=20different=20trade=20off=20 for=20SAVI |Sender:=20; bh=1QdCfDwVsr0zvY5SRWhO3RMkUe3/A0W/GbIB9oAy4NE=; b=X8TwXYc9wubN4kjYVSeinsgq/x0v837AzhR0XZvArvb2FqdbE1okYrtlVl 7Glmlv2nJfFumZyuqWhNaPjzrB3kcPigEc3Lo3QRj5HOZzbW95DzhY1+WDEw LGb53SySeQ; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: SAVI Mailing List , Christian Vogt Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 03:01:00 -0000 but letting traffic prior to DAD go means that an attack that is spoofing an address and sends it only once doesn't have to do DAD at all, and SAVI is ineffective in preventing it.. What part of "the purpose of SAVI is to prevent systems from sending datagrams from addresses that are not their own, and if under any circumstance they succeed in sending a datagram from such an address SAVI has failed" are we having trouble with here? On Jun 23, 2009, at 7:55 PM, Frank Xia wrote: > Hi Christian > > Yes. > > My another observation is that people only talk about > DAD defined in RFC4862 while ignoring Optimistic DAD defined in > RFC4429 which > let go data traffic preceding control message > > BR > Frank > > ----- Original Message ----- From: "Christian Vogt" > > To: "Frank Xia" > Cc: "SAVI Mailing List" > Sent: Tuesday, June 23, 2009 9:05 PM > Subject: Re: [savi] A different trade off for SAVI > > >> On Jun 15, 2009, Frank Xia wrote: >>> DAD is NOT a MUST for stateless address configuration. RFC 4862 >>> reads >>> >>> "By default, all addresses should be tested for uniqueness prior >>> to >>> their assignment to an interface for safety. The test should >>> individually be performed on all addresses obtained manually, via >>> stateless address autoconfiguration, or via DHCPv6. To >>> accommodate >>> sites that believe the overhead of performing Duplicate Address >>> Detection outweighs its benefits, the use of Duplicate Address >>> Detection can be disabled through the administrative setting of a >>> per-interface configuration flag." >> Isn't this just another reason to forward packets in the absence of a >> binding, rather than discarding them? I see this in support of the >> proposed FCFS variant. >> - Christian >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From elevyabe@cisco.com Wed Jun 24 09:50:36 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714953A6BCE for ; Wed, 24 Jun 2009 09:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.966 X-Spam-Level: X-Spam-Status: No, score=-9.966 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHvkaUb7xP4V for ; Wed, 24 Jun 2009 09:50:35 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A8E4D3A6CBB for ; Wed, 24 Jun 2009 09:50:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,284,1243814400"; d="scan'208";a="43586928" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 24 Jun 2009 16:49:32 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5OGnVUa026624; Wed, 24 Jun 2009 18:49:31 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5OGnVVf012734; Wed, 24 Jun 2009 16:49:31 GMT Received: from xmb-ams-335.cisco.com ([144.254.231.80]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jun 2009 18:49:31 +0200 Received: from [144.254.53.107] ([144.254.53.107]) by xmb-ams-335.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jun 2009 18:49:31 +0200 Message-ID: <4A42591A.5060408@cisco.com> Date: Wed, 24 Jun 2009 18:49:30 +0200 From: Eric Levy-Abegnoli User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christian Vogt References: <4A2C0DFB.3040803@it.uc3m.es> <4A2D2221.4030503@cisco.com> <4A2D2739.1000206@it.uc3m.es> <4A2F9E29.5070704@cisco.com> <4A30D6CD.8060209@it.uc3m.es> <49417952-8570-467E-B312-B759DC3D88DD@ericsson.com> <4A35ECEE.7060801@cisco.com> <86861CC6-385A-4CBA-9B9C-5D7E56EF119B@ericsson.com> In-Reply-To: <86861CC6-385A-4CBA-9B9C-5D7E56EF119B@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 24 Jun 2009 16:49:31.0491 (UTC) FILETIME=[BEF3CB30:01C9F4EB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4417; t=1245862171; x=1246726171; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=elevyabe@cisco.com; z=From:=20Eric=20Levy-Abegnoli=20 |Subject:=20Re=3A=20[savi]=20A=20different=20trade=20off=20 for=20SAVI |Sender:=20; bh=nrjh55045A6e1+xQUSzfZ9VwBEGwUZiiQ61vNsQKN0Q=; b=i5MxeHiFUMN8aWMKf2MdRoJZ/uBYTx4SHBriSCU/xHp5huUqptAbmmtJMz xG0iVbvVWOscr3uHnNIfszgEzdki0lV93vJQdBPpRM6T5Xno77Cge2sEBZ5t Uf3FJ71Vud; Authentication-Results: ams-dkim-2; header.From=elevyabe@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 16:50:36 -0000 Christian, Christian Vogt a écrit : > On June 14, 2009, Eric Levy-Abegnoli wrote: > >> I am a bit confused here, or maybe I lack some background of previous >> discussions. Look to me there is a tradeoff; almost an antagonism >> between prefering the first binding (hence the first packet carrying >> this binding) and allowing nodes to defend their address. It's pretty >> trivial for the attacker to listen to the DAD from his victim, and >> answer as soon as he sees it. And then take ownership of the binding if >> I read you correctly. > > Eric - > > Are you still talking about an attack that SAVI is trying to prevent? > You are talking about an attack that keeps a host from configuring a > particular IP address, not an attack in which this IP address is > spoofed. This attack is inherent in DAD, as Marcelo mentioned. But it > is not an attack that SAVI was chartered to prevent. > > Now, I understand that your intention is to augment SAVI to also protect > DAD. Can you clarify how your proposed mechanism would work? And what > would be the cost in terms of extra implementation or administration > complexity? (I think you should start a new discussion thread for this, > since it seems to be independent of the adoption of Marcelo's proposed > FCFS variant.) I am not trying to protect DAD per say. I am arguing that there are many caveats in fcfs, that would lead the switch to install attackers binding in its table instead of legitimate owners bindings. I certainly acknowledge that the switch binding table will indeed reflect the state of the network (attackers being over-represented in the binding table). But it defeats the purpose (if not the charter) of building a binding table that provides better security than no table.at all One example:victim comes up, address is installed, victim goes away, address is removed, attackers do DAD for the same address, gets his address in the table, victim comes back and is rejected. So the binding table reflect the state of the network. And the victim is out. I have a number of scenarios in mind on how the switch can make a better decision than the end-nodes, and others where fcfs will not lead to the best decision. However, as long as we have not agreed that the switch is a greater authority than end-nodes with regard to prefering a binding, then I don't think it's useful. As far as the fcfs variant (is this the logging instead of droping proposal?) I think it's a bad idea. If the switch does not drop, it will endup with binding inconsistent with end-nodes (4861/4862 are not first-come first-serve based). This incosisyency will lead to a lot more logging than desirable. And on top of that, logging is often harmful and useless. > >> So did this group agree that the DAD responder should have his binding >> preferred over the DAD sender? If so, how can this be an anti-spoofing >> protection mechanism? > > I am unsure if I understand you. DAD responses do not create SAVI > bindings. They can only prevent another binding from being created, and > this only if they correspond to an existing binding themselves. If they > do not correspond to an existing binding themselves, they are dropped by > a SAVI device. The only way to create a SAVI binding is by sending a > DAD solicitation or by a DHCP address assignment. Then this is me who mis-understood what you said: [DAD] it gives the victim of a spoofing attack a chance to speak up. The attacker would obviously not do DAD on the address he plans to spoof. So I took that you meant victim = DAD sender. Then I see two cases: 1) There was initially no owner for the address in the binding table, one is created on the NS DAD, and the NA (response), carrying a different binding should be rejected by the switch (or a least not change the binding entry). If not blocked, the DAD sender end up with no address. Binding table with bogus binding. 2) There was initially a owner, the DAD NS should be sent to him (and nobody else in my opinion); response sent back to him, binding table not changed. This is not a spoofing scenario. So in that case, what DAD gives you over the other NDP messages? In my opinion, just an opportunity for the attacker to prevent the DAD sender to use an address. So it's rather a caveat than a chance. Eric > > - Christian > > > > From gdaley@netstarnetworks.com Wed Jun 24 15:16:01 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 425E83A6A8D for ; Wed, 24 Jun 2009 15:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUFazrO0TyEz for ; Wed, 24 Jun 2009 15:16:00 -0700 (PDT) Received: from mail.syd.netstarnetworks.com (mail.syd.netstarnetworks.com [203.8.7.220]) by core3.amsl.com (Postfix) with ESMTP id 2BB3A3A6F26 for ; Wed, 24 Jun 2009 15:15:59 -0700 (PDT) Received: from sydmail.netstarnetworks.com ([10.18.193.13]) by mail.syd.netstarnetworks.com (8.12.8/8.12.8) with ESMTP id n5OMFURs008178; Thu, 25 Jun 2009 08:15:43 +1000 Received: from melmail.netstarnetworks.com ([10.20.193.13]) by sydmail.netstarnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 08:15:27 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jun 2009 08:15:26 +1000 Message-ID: <6983BF97BFC24D4EA551F14071232918010FFEE7@melmail.netstarnetworks.com> In-Reply-To: <4ECD61DE-172E-486D-A9DC-948DB322D565@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [savi] A different trade off for SAVI Thread-Index: Acn0cFL3D2g1tzw2Sq+OKSblnpr0rAABUYQA References: <4A2C0DFB.3040803@it.uc3m.es><00e301c9edcf$c7cc7bd0$3e0c7c0a@china.huawei.com><4A36706D.9050501@it.uc3m.es><001901c9edda$ff5bceb0$3e0c7c0a@china.huawei.com> <4ECD61DE-172E-486D-A9DC-948DB322D565@ericsson.com> From: "Greg Daley" To: "Christian Vogt" , "Frank Xia" X-OriginalArrivalTime: 24 Jun 2009 22:15:27.0472 (UTC) FILETIME=[4739AF00:01C9F519] Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 22:16:01 -0000 Hi Frank and Christian,=20 Actually, I see this rather as a case where the applicability of SAVI operations increases the usefulness of DAD. In environments where manual, administrative settings to disable DAD are in use, a policy decision is being made. It could be argued that this policy decision is incompatible with SAVI (and turning on SAVI is also likely to be a policy setting). An up-front compatibility statement would cover the situations where DAD is not to be done. In reference to Frank's discussion of RFC 4429, there is indeed a race condition between packet transmission and DAD operation in Optimistic DAD. There are already explicit assumptions in that document which outline that packet transmission from optimistic addresses may be lost before DAD is completed. This is also the case for mobile devices which are not required to always perform full DAD when reattaching to the same LAN from a different switch port (for example through a different WLAN AP). Packets transmitted at that time would be lost until the binding is updated. Greg Daley Security Consultant NetStar Australia Pty Ltd E-mail: gdaley@netstarnetworks.com Mobile: +61 401 772 770 Direct: +61 3 8532 4042 Fax: +61 3 8532 4032 -----Original Message----- From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Christian Vogt Sent: Wednesday, 24 June 2009 12:06 PM To: Frank Xia Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI On Jun 15, 2009, Frank Xia wrote: > DAD is NOT a MUST for stateless address configuration. RFC 4862 reads > > "By default, all addresses should be tested for uniqueness prior to > their assignment to an interface for safety. The test should > individually be performed on all addresses obtained manually, via > stateless address autoconfiguration, or via DHCPv6. To accommodate > sites that believe the overhead of performing Duplicate Address > Detection outweighs its benefits, the use of Duplicate Address > Detection can be disabled through the administrative setting of a > per-interface configuration flag." Isn't this just another reason to forward packets in the absence of a binding, rather than discarding them? I see this in support of the proposed FCFS variant. - Christian _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi From xiayangsong@huawei.com Wed Jun 24 15:56:27 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2F528C4F7 for ; Wed, 24 Jun 2009 15:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.777 X-Spam-Level: X-Spam-Status: No, score=-0.777 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9DEPYMBvP4S for ; Wed, 24 Jun 2009 15:56:26 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 6FC7D28C4FB for ; Wed, 24 Jun 2009 15:56:26 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLR00GWSLYHC9@szxga03-in.huawei.com> for savi@ietf.org; Thu, 25 Jun 2009 06:47:05 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLR00B0PLYHCO@szxga03-in.huawei.com> for savi@ietf.org; Thu, 25 Jun 2009 06:47:05 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLR005POLYAQ6@szxml04-in.huawei.com> for savi@ietf.org; Thu, 25 Jun 2009 06:47:05 +0800 (CST) Date: Wed, 24 Jun 2009 17:46:57 -0500 From: Frank Xia To: Greg Daley , Christian Vogt Message-id: <011701c9f51d$b225fae0$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4A2C0DFB.3040803@it.uc3m.es> <00e301c9edcf$c7cc7bd0$3e0c7c0a@china.huawei.com> <4A36706D.9050501@it.uc3m.es> <001901c9edda$ff5bceb0$3e0c7c0a@china.huawei.com> <4ECD61DE-172E-486D-A9DC-948DB322D565@ericsson.com> <6983BF97BFC24D4EA551F14071232918010FFEE7@melmail.netstarnetworks.com> Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 22:56:27 -0000 Hi Greg Just as the title say "the trade off for SAVI", I prefer letting a packet go even we are not sure if it is legitimate. Please see my other inline comments... BR Frank ----- Original Message ----- From: "Greg Daley" To: "Christian Vogt" ; "Frank Xia" Cc: "SAVI Mailing List" Sent: Wednesday, June 24, 2009 5:15 PM Subject: Re: [savi] A different trade off for SAVI > Hi Frank and Christian, > > Actually, I see this rather as a case where the applicability of SAVI > operations > increases the usefulness of DAD. In environments where manual, > administrative > settings to disable DAD are in use, a policy decision is being made. > > It could be argued that this policy decision is incompatible with SAVI > (and turning on > SAVI is also likely to be a policy setting). > > An up-front compatibility statement would cover the situations where DAD > is not to be done. > > In reference to Frank's discussion of RFC 4429, there is indeed a race > condition between > packet transmission and DAD operation in Optimistic DAD. There are > already explicit assumptions > in that document which outline that packet transmission from optimistic > addresses may be lost > before DAD is completed. Frank=>That means Optimistic DAD is not allowed. > > This is also the case for mobile devices which are not required to > always perform full DAD when > reattaching to the same LAN from a different switch port (for example > through a different WLAN AP). > Packets transmitted at that time would be lost until the binding is > updated. Frank=>IMHO, packet loss due to handover seem to be irrelevent to packet filtering because of false soure address. > > > > Greg Daley > Security Consultant > NetStar Australia Pty Ltd > > E-mail: gdaley@netstarnetworks.com > Mobile: +61 401 772 770 > Direct: +61 3 8532 4042 > Fax: +61 3 8532 4032 > -----Original Message----- > From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of > Christian Vogt > Sent: Wednesday, 24 June 2009 12:06 PM > To: Frank Xia > Cc: SAVI Mailing List > Subject: Re: [savi] A different trade off for SAVI > > > On Jun 15, 2009, Frank Xia wrote: > >> DAD is NOT a MUST for stateless address configuration. RFC 4862 reads >> >> "By default, all addresses should be tested for uniqueness prior to >> their assignment to an interface for safety. The test should >> individually be performed on all addresses obtained manually, via >> stateless address autoconfiguration, or via DHCPv6. To accommodate >> sites that believe the overhead of performing Duplicate Address >> Detection outweighs its benefits, the use of Duplicate Address >> Detection can be disabled through the administrative setting of a >> per-interface configuration flag." > > Isn't this just another reason to forward packets in the absence of a > binding, rather than discarding them? I see this in support of the > proposed FCFS variant. > > - Christian > > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From christian.vogt@ericsson.com Wed Jun 24 16:06:08 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B24CF3A6D91 for ; Wed, 24 Jun 2009 16:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+kGqy3bOuJE for ; Wed, 24 Jun 2009 16:06:08 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 069F13A6D8A for ; Wed, 24 Jun 2009 16:06:07 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n5OH26vt032017; Wed, 24 Jun 2009 12:02:06 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jun 2009 12:02:06 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jun 2009 12:02:06 -0500 From: Christian Vogt To: Frank Xia In-Reply-To: <00c401c9f477$360829c0$3e0c7c0a@china.huawei.com> X-Priority: 3 References: <4A2C0DFB.3040803@it.uc3m.es> <00e301c9edcf$c7cc7bd0$3e0c7c0a@china.huawei.com> <4A36706D.9050501@it.uc3m.es> <001901c9edda$ff5bceb0$3e0c7c0a@china.huawei.com> <4ECD61DE-172E-486D-A9DC-948DB322D565@ericsson.com> <00c401c9f477$360829c0$3e0c7c0a@china.huawei.com> Message-Id: <8854F528-ABFB-4739-B42D-BA7716921859@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 24 Jun 2009 10:02:06 -0700 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 24 Jun 2009 17:02:06.0263 (UTC) FILETIME=[80D4DC70:01C9F4ED] Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 23:06:08 -0000 On Jun 23, 2009, Frank Xia wrote: > Yes. > > My another observation is that people only talk about DAD defined in > RFC4862 while ignoring Optimistic DAD defined in RFC4429 which let go > data traffic preceding control message Right, Optimistic DAD must be considered. And this again is a reason to forward packets in the absence of a binding, rather than discarding them. - Christian From christian.vogt@ericsson.com Wed Jun 24 19:06:24 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3F2F3A6D1E for ; Wed, 24 Jun 2009 19:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXpjYQ+lQoGD for ; Wed, 24 Jun 2009 19:06:24 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id DD99E3A6978 for ; Wed, 24 Jun 2009 19:06:23 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n5P24oPl022066; Wed, 24 Jun 2009 21:04:50 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jun 2009 21:04:50 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jun 2009 21:04:49 -0500 Message-Id: <81955095-4CA3-41E8-8435-99B2AF644621@ericsson.com> From: Christian Vogt To: Fred Baker , SAVI Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 24 Jun 2009 19:04:49 -0700 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 25 Jun 2009 02:04:49.0920 (UTC) FILETIME=[52489800:01C9F539] Subject: [savi] On the Protection of Unused Addresses X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 02:06:25 -0000 On Jun 23, 2009, Fred Baker wrote on thread "Your opinion on a different tradeoff for SAVI": > SAVI without protecting unused addresses is pointless. Fred and all - Protection of unused addresses would, of course, be a useful feature. But before making this mandatory, we should do a benefit-cost analysis. Here is one, along with a proposal of how to move forward: The benefit of protecting unused addresses is that it prevents an attacker from hiding its identity or location. An attacker who wants to do this can use any source address as long as it is not its own address. Protecting unused addresses is especially useful in networks where DHCP is the only permitted method for address configuration, since those networks are in control of which addresses are used. On the other hand, in networks where Stateless Address Autoconfiguration is permitted, it is up to the (potentially malicious) hosts which addresses are used. Protecting unused addresses then has little benefit: All it achieves is requiring an attacker to formally turn an unused address into a used address by sending a DAD solicitation. The cost of protecting unused addresses is a need to coordinate multiple SAVI devices on the same link. If this coordination does not exist, or is insufficient, legitimate packets may get dropped, because one SAVI device may consider unused an address that is in fact in use at another SAVI device. Coordination between SAVI devices, in turn, can be accomplished in one of two ways: - By partitioning the scope of SAVI protection into one area per SAVI device. This requires manual configuration of SAVI devices, since switch ports that connect to other SAVI devices must be labeled as such. Link partitioning is the approach of the CPS solution. - By synchronizing binding state across SAVI devices so that each SAVI device can validate addresses from anywhere else on the link. This requires an extra binding distribution protocol, plus extra memory for binding state copied from other SAVI devices. Synchronization was proposed as an add-on to the original FCFS solution. Either form of coordination implies an undesired cost for protecting unused addresses. Given this cost, and given that the main benefit is in networks where DHCP is the only permitted address configuration method, a potential way to move forward may be to make the protection of unused addresses optional and limited to those DHCP-only networks. More specifically, we could add an optional "DHCP-only mode" to SAVI, in which SAVI devices would permit only those addresses that have been explicitly assigned via DHCP. In DHCP-only mode, SAVI devices would: - Create bindings only based on DHCP address assignments, but not based on DAD solicitations. - Drop packets with unused source addresses. As a method for inter-SAVI-device coordination, I suggest partitioning the scope of SAVI protection. Thus, network administrators who enable DHCP-only mode may also have to manually designate switch ports that connect to other SAVI devices. This extra manual configuration should be acceptable given that the DHCP-only mode already needs to be turned on manually. At the same time, link partitioning avoids the extra complexity and manufacturing cost that synchronization would entail. What do folks think? Would this be a reasonable approach? - Christian From fred@cisco.com Wed Jun 24 20:13:13 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 163563A69DF for ; Wed, 24 Jun 2009 20:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YBOWG1RGtKt for ; Wed, 24 Jun 2009 20:13:12 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 37B793A6818 for ; Wed, 24 Jun 2009 20:13:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,287,1243814400"; d="scan'208";a="331305658" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 25 Jun 2009 03:12:58 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n5P3Cwww030640; Wed, 24 Jun 2009 20:12:58 -0700 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n5P3CvCk027902; Thu, 25 Jun 2009 03:12:57 GMT Message-Id: <9E06E8D3-EED1-42FC-8D78-90626E341CD8@cisco.com> From: Fred Baker To: Christian Vogt In-Reply-To: <81955095-4CA3-41E8-8435-99B2AF644621@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 24 Jun 2009 20:12:55 -0700 References: <81955095-4CA3-41E8-8435-99B2AF644621@ericsson.com> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=612; t=1245899578; x=1246763578; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20On=20the=20Protection=20of=20Unused=20A ddresses |Sender:=20; bh=srf0IwLXMxKyafWxjN2aqarRfCA+x9J+9DLwd2uEbCY=; b=jgrS7td6dbFZUhntvCFpzRf3tVBjw+TgifByI+PxD6ryM9GkGNTw1DmyXO jy1MrX9pTXu2cHenvhJJTmey10RuGCbQQlECmo1/9OP2rTVzE9bhrA4esu/u Krwzrk21v+; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: SAVI Mailing List Subject: Re: [savi] On the Protection of Unused Addresses X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 03:13:13 -0000 On Jun 24, 2009, at 7:04 PM, Christian Vogt wrote: > Protection of unused addresses would, of course, be a useful feature. > But before making this mandatory, we should do a benefit-cost > analysis. we should also consider the problem statement, which was that folks wanted to prevent viruses etc from using addresses not assigned to them. Speaking as someone who has a product in the field that does this, and therefore has a handle on both the costs and the customer statements made when buying equipment with that feature, I think this is a very straightforward value proposition. From xiayangsong@huawei.com Thu Jun 25 08:39:48 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD1933A6906 for ; Thu, 25 Jun 2009 08:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[AWL=-1.004, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Krh94dyW39f0 for ; Thu, 25 Jun 2009 08:39:48 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 1ABF83A68C8 for ; Thu, 25 Jun 2009 08:39:48 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLS002JXWS7MV@szxga04-in.huawei.com> for savi@ietf.org; Thu, 25 Jun 2009 23:38:32 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLS00B3FWS7P3@szxga04-in.huawei.com> for savi@ietf.org; Thu, 25 Jun 2009 23:38:31 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLS004W0WS5IP@szxml06-in.huawei.com> for savi@ietf.org; Thu, 25 Jun 2009 23:38:31 +0800 (CST) Date: Thu, 25 Jun 2009 10:38:29 -0500 From: Frank Xia To: SAVI Mailing List Message-id: <000801c9f5aa$fe34fa20$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_g3mOQGpOiDUk25g8KLnNkA)" X-Priority: 3 X-MSMail-priority: Normal Subject: [savi] feasibility of impmentation SAVI in a switch X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 15:39:49 -0000 This is a multi-part message in MIME format. --Boundary_(ID_g3mOQGpOiDUk25g8KLnNkA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi Guys This question has been obsessing me for a while. Aside from high end switches (such as layer 3 switches), most switches use commercial chips which only inspect layer 2 information(mac, vlan,etc). At the same time, SAVI requires switches to parse layer 3 information of each packet. Apparantly, current switch chips can not handle this. That means switch vendors should in turn require chip vendors to support this feature. IMHO, the impact of chip design probably will impede the adoption of SAVI in switch. BR Frank --Boundary_(ID_g3mOQGpOiDUk25g8KLnNkA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi Guys
 
This question has been obsessing me for a while.
 
Aside from high end switches (such as layer 3 switches),
most switches use commercial chips which only inspect
layer 2 information(mac, vlan,etc).  At the same time,
SAVI requires switches to parse layer 3 information of
each packet. 
 
Apparantly, current switch chips can not handle this. 
That means switch vendors should in turn require
chip vendors to support this feature.
 
IMHO, the impact of chip design probably will impede
the adoption of SAVI in switch.
 
BR
Frank
 
--Boundary_(ID_g3mOQGpOiDUk25g8KLnNkA)-- From christian.vogt@ericsson.com Thu Jun 25 15:45:16 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3BBC3A696B for ; Thu, 25 Jun 2009 15:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8K83huTWQDr9 for ; Thu, 25 Jun 2009 15:45:16 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 1421B3A6976 for ; Thu, 25 Jun 2009 15:45:16 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n5PMi4xG020024; Thu, 25 Jun 2009 17:44:04 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jun 2009 17:44:04 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jun 2009 17:44:03 -0500 Message-Id: From: Christian Vogt To: Fred Baker In-Reply-To: <9E06E8D3-EED1-42FC-8D78-90626E341CD8@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 25 Jun 2009 15:44:03 -0700 References: <81955095-4CA3-41E8-8435-99B2AF644621@ericsson.com> <9E06E8D3-EED1-42FC-8D78-90626E341CD8@cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 25 Jun 2009 22:44:03.0833 (UTC) FILETIME=[70AB5690:01C9F5E6] Cc: SAVI Mailing List Subject: Re: [savi] On the Protection of Unused Addresses X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 22:45:17 -0000 On Jun 24, 2009, Fred Baker wrote: > we should also consider the problem statement, which was that folks > wanted to prevent viruses etc from using addresses not assigned to > them. > > Speaking as someone who has a product in the field that does this, and > therefore has a handle on both the costs and the customer statements > made when buying equipment with that feature, I think this is a very > straightforward value proposition. Fred - I understand your arguments. Yet, as I explained in my previous email, I think it is hard, perhaps impossible, to build a non-disruptive and cost-efficient SAVI solution that protects unused addresses in networks where Stateless Address Autoconfiguration is permitted. What do you think of the proposal to limit the protection of unused addresses to networks that use only DHCP for address assignment? - Christian From gdaley@netstarnetworks.com Thu Jun 25 15:48:32 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CF373A69EF for ; Thu, 25 Jun 2009 15:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcFYJ9I+dTux for ; Thu, 25 Jun 2009 15:48:31 -0700 (PDT) Received: from mail.syd.netstarnetworks.com (mail.syd.netstarnetworks.com [203.8.7.220]) by core3.amsl.com (Postfix) with ESMTP id 97ED93A690C for ; Thu, 25 Jun 2009 15:48:30 -0700 (PDT) Received: from sydmail.netstarnetworks.com ([10.18.193.13]) by mail.syd.netstarnetworks.com (8.12.8/8.12.8) with ESMTP id n5PMlbRs028404; Fri, 26 Jun 2009 08:47:50 +1000 Received: from melmail.netstarnetworks.com ([10.20.193.13]) by sydmail.netstarnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Jun 2009 08:47:33 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9F5E6.ED6562B0" Date: Fri, 26 Jun 2009 08:47:32 +1000 Message-ID: <6983BF97BFC24D4EA551F1407123291801100069@melmail.netstarnetworks.com> In-Reply-To: <011701c9f51d$b225fae0$3e0c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [savi] A different trade off for SAVI Thread-Index: Acn1HbcwO6HZyIqKSbagYpjm+f+ooAAAV/Ng References: <4A2C0DFB.3040803@it.uc3m.es> <00e301c9edcf$c7cc7bd0$3e0c7c0a@china.huawei.com> <4A36706D.9050501@it.uc3m.es> <001901c9edda$ff5bceb0$3e0c7c0a@china.huawei.com> <4ECD61DE-172E-486D-A9DC-948DB322D565@ericsson.com> <6983BF97BFC24D4EA551F14071232918010FFEE7@melmail.netstarnetworks.com> <011701c9f51d$b225fae0$3e0c7c0a@china.huawei.com> From: "Greg Daley" To: "Frank Xia" , "Christian Vogt" X-OriginalArrivalTime: 25 Jun 2009 22:47:33.0807 (UTC) FILETIME=[EDD2D3F0:01C9F5E6] Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 22:48:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9F5E6.ED6562B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Frank,=20 I have highlighted my points below, which are salient, even though the title has not changed on the thread. -----Original Message----- From: Frank Xia [mailto:xiayangsong@huawei.com] Sent: Thursday, 25 June 2009 8:47 AM To: Greg Daley; Christian Vogt Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI Hi Greg Just as the title say "the trade off for SAVI", I prefer letting a packet go even we are not sure if it is legitimate. Please see my other inline comments... BR Frank > > In reference to Frank's discussion of RFC 4429, there is indeed a race condition between > packet transmission and DAD operation in Optimistic DAD. There are already explicit assumptions > in that document which outline that packet transmission from optimistic addresses may be lost > before DAD is completed. Frank=3D>That means Optimistic DAD is not allowed. Actually, I'd like to clarify the behaviour of Optimistic DAD (RFC4429) in this case: There is no implied delay for the DAD NS delivery in Optimistic DAD: =20 (Section 3.3) * (modifies section 5.4.2) The host MUST join the all-nodes multicast address and the solicited-node multicast address of the Tentative address. The host SHOULD NOT delay before sending Neighbor Solicitation messages. The difference is that packets can be sent basically immediately in Optimistic DAD. This is valid behaviour, and the host knows that by using an optimistic address there is the chance of delivery failure. No existing Neighbour Discovery Binding is overwritten by RFC4429 operations, so there is no problem with Optimistic DAD's impact on the network. The impact is specific to the host, which is the functional trade-off built into optimistic DAD. In summary: It does not mean that Optimistic DAD is not allowed. =20 > This is also the case for mobile devices which are not required to always perform full DAD when > reattaching to the same LAN from a different switch port (for example through a different WLAN AP). > Packets transmitted at that time would be lost until the binding is updated. Frank=3D>IMHO, packet loss due to handover seem to be irrelevent to packet filtering because of false soure address. The impact is functionally the same for false address use and for mobile devices. The binding exists on one port, and then moves to another port without signalling.=20 This is not packet loss due to mobility, the SAVI device would block any such port movement were DAD/MLD/DHCPv6 (take your pick for binding protocol) not to occur. By default, the moving device doesn't perform DAD, as it is in the same Link. =20 ------_=_NextPart_001_01C9F5E6.ED6562B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Frank, 

I have highlighted my points below, which = are=20 salient, even though the title has not changed on the thread.


-----Original=20 Message-----
From: Frank Xia [mailto:xiayangsong@huawei.com]=
Sent:=20 Thursday, 25 June 2009 8:47 AM
To: Greg Daley; Christian Vogt
Cc: = SAVI=20 Mailing List
Subject: Re: [savi] A different trade off for = SAVI

Hi=20 Greg

Just as the title say "the trade off for SAVI", I prefer = letting a=20 packet go even we are not  sure if it is legitimate.

Please = see my=20 other inline comments...

BR
Frank


>
> In = reference=20 to Frank's discussion of RFC 4429, there is indeed a race condition = between
> packet transmission and DAD operation in Optimistic = DAD. =20 There are already explicit assumptions
> in that document = which=20 outline that packet transmission from optimistic addresses may be = lost
>=20 before DAD is completed.
Frank=3D>That means Optimistic DAD is not = allowed.

Actually, I'd like = to clarify the=20 behaviour of Optimistic DAD (RFC4429) in this case:

There is no implied delay for the DAD NS delivery in = Optimistic=20 DAD:
 
(Section = 3.3)
   * (modifies section 5.4.2) The host MUST join the all-nodes =
multicast
        address and the solicited-node multicast address of the
        Tentative address.  The host SHOULD NOT delay before sending
        Neighbor Solicitation messages.

The difference is that packets can be =
sent basically immediately in
Optimistic DAD.  This is valid =
behaviour, and the host knows that by
using an optimistic address =
there is the chance of delivery failure.
No existing Neighbour Discovery Binding is =
overwritten by RFC4429 operations,
so there is no problem with =
Optimistic DAD's impact on the network.  The 
impact is specific to =
the host, which is the functional trade-off built
into optimistic =
DAD.
In summary: It =
does not mean that Optimistic DAD is not allowed.
 

> This is also the case for mobile devices = which are=20 not required to always perform full DAD when
> reattaching to the = same LAN=20 from a different switch port (for example through a different WLAN=20 AP).
> Packets transmitted at that time would be lost until the = binding=20 is updated.
Frank=3D>IMHO, packet loss due to handover seem = to be=20 irrelevent
to packet filtering because of false soure address.

The impact is functionally the = same for false=20 address use and for mobile devices.  The binding
exists on one port, and then moves to = another port=20 without signalling. 

This is not packet loss due to = mobility, the=20 SAVI device would block any such port movement
were DAD/MLD/DHCPv6 = (take your=20 pick for binding protocol) not to occur.  By default, the
moving = device=20 doesn't perform DAD, as it is in the same Link.

 

------_=_NextPart_001_01C9F5E6.ED6562B0-- From fred@cisco.com Thu Jun 25 16:04:18 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A774D3A6807 for ; Thu, 25 Jun 2009 16:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkeidhUKRxtu for ; Thu, 25 Jun 2009 16:04:11 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id DAC233A67E6 for ; Thu, 25 Jun 2009 16:03:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,292,1243814400"; d="scan'208";a="205809138" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 25 Jun 2009 23:00:05 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n5PN06MO001069; Thu, 25 Jun 2009 16:00:06 -0700 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n5PMw7iG010034; Thu, 25 Jun 2009 23:00:06 GMT Message-Id: From: Fred Baker To: Christian Vogt In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 25 Jun 2009 16:00:06 -0700 References: <81955095-4CA3-41E8-8435-99B2AF644621@ericsson.com> <9E06E8D3-EED1-42FC-8D78-90626E341CD8@cisco.com> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1114; t=1245970806; x=1246834806; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20On=20the=20Protection=20of=20Unused=20A ddresses |Sender:=20; bh=3vrgLZU8Kaeno3QjwebIrR0eb0O6STzpArr0fUvux5E=; b=SD3x+0ZaEWQi1t4iYN7VzwCXtKpDgKWjv7udtXbUfJ8UwRd76zGEd6uPub uycsm+spnSjPXLZCPKbyxqfVaz5PbuwugswU4z+Y4MSF0hdBCUhEI2juzBw4 7US/0TINIo; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: SAVI Mailing List Subject: Re: [savi] On the Protection of Unused Addresses X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 23:04:18 -0000 Given that there is no product on the market today that uses DHCP for address assignment... it seems vacuous. On Jun 25, 2009, at 3:44 PM, Christian Vogt wrote: > On Jun 24, 2009, Fred Baker wrote: > >> we should also consider the problem statement, which was that folks >> wanted to prevent viruses etc from using addresses not assigned to >> them. >> >> Speaking as someone who has a product in the field that does this, >> and >> therefore has a handle on both the costs and the customer statements >> made when buying equipment with that feature, I think this is a very >> straightforward value proposition. > > > Fred - > > I understand your arguments. Yet, as I explained in my previous > email, > I think it is hard, perhaps impossible, to build a non-disruptive and > cost-efficient SAVI solution that protects unused addresses in > networks > where Stateless Address Autoconfiguration is permitted. What do you > think of the proposal to limit the protection of unused addresses to > networks that use only DHCP for address assignment? > > - Christian > > From xiayangsong@huawei.com Thu Jun 25 16:13:21 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C57E3A68A4 for ; Thu, 25 Jun 2009 16:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.128 X-Spam-Level: X-Spam-Status: No, score=-1.128 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_102=0.6, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdsCcREY0s41 for ; Thu, 25 Jun 2009 16:13:20 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 9BA5E3A67E6 for ; Thu, 25 Jun 2009 16:13:19 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLT00KXMHTWT9@szxga03-in.huawei.com> for savi@ietf.org; Fri, 26 Jun 2009 07:13:08 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLT00BLVHTWCO@szxga03-in.huawei.com> for savi@ietf.org; Fri, 26 Jun 2009 07:13:08 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLT00H1OHTTCY@szxml04-in.huawei.com> for savi@ietf.org; Fri, 26 Jun 2009 07:13:07 +0800 (CST) Date: Thu, 25 Jun 2009 18:13:04 -0500 From: Frank Xia To: Greg Daley , Christian Vogt Message-id: <005301c9f5ea$7fcaa870$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_DD/fHAXwaxp/8qYSWiWQFQ)" X-Priority: 3 X-MSMail-priority: Normal References: <4A2C0DFB.3040803@it.uc3m.es> <00e301c9edcf$c7cc7bd0$3e0c7c0a@china.huawei.com> <4A36706D.9050501@it.uc3m.es> <001901c9edda$ff5bceb0$3e0c7c0a@china.huawei.com> <4ECD61DE-172E-486D-A9DC-948DB322D565@ericsson.com> <6983BF97BFC24D4EA551F14071232918010FFEE7@melmail.netstarnetworks.com> <011701c9f51d$b225fae0$3e0c7c0a@china.huawei.com> <6983BF97BFC24D4EA551F1407123291801100069@melmail.netstarnetworks.com> Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 23:13:21 -0000 This is a multi-part message in MIME format. --Boundary_(ID_DD/fHAXwaxp/8qYSWiWQFQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Greg " Optimistic address - an address that is assigned to an interface and available for use, subject to restrictions, while its uniqueness on a link is being verified. This memo introduces the Optimistic state and defines its behaviors and restrictions." An address could be used for sending packets even DAD is ongoing. That means there is not DAD state established. It also means it could happen sending a packet prior to sending any DAD message(that is, NS). Please check other inline responses... BR Frank ----- Original Message ----- From: Greg Daley To: Frank Xia ; Christian Vogt Cc: SAVI Mailing List Sent: Thursday, June 25, 2009 5:47 PM Subject: Re: [savi] A different trade off for SAVI Hi Frank, I have highlighted my points below, which are salient, even though the title has not changed on the thread. -----Original Message----- From: Frank Xia [mailto:xiayangsong@huawei.com] Sent: Thursday, 25 June 2009 8:47 AM To: Greg Daley; Christian Vogt Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI Hi Greg Just as the title say "the trade off for SAVI", I prefer letting a packet go even we are not sure if it is legitimate. Please see my other inline comments... BR Frank > > In reference to Frank's discussion of RFC 4429, there is indeed a race condition between > packet transmission and DAD operation in Optimistic DAD. There are already explicit assumptions > in that document which outline that packet transmission from optimistic addresses may be lost > before DAD is completed. Frank=>That means Optimistic DAD is not allowed. Actually, I'd like to clarify the behaviour of Optimistic DAD (RFC4429) in this case: There is no implied delay for the DAD NS delivery in Optimistic DAD: (Section 3.3) * (modifies section 5.4.2) The host MUST join the all-nodes multicast address and the solicited-node multicast address of the Tentative address. The host SHOULD NOT delay before sending Neighbor Solicitation messages. Frank=>"SHOULD NOT delay" does not mean "sending NS prior to any datapackets" The difference is that packets can be sent basically immediately inOptimistic DAD. This is valid behaviour, and the host knows that byusing an optimistic address there is the chance of delivery failure.No existing Neighbour Discovery Binding is overwritten by RFC4429 operations,so there is no problem with Optimistic DAD's impact on the network. The impact is specific to the host, which is the functional trade-off builtinto optimistic DAD.In summary: It does not mean that Optimistic DAD is not allowed.> This is also the case for mobile devices which are not required to always perform full DAD when> reattaching to the same LAN from a different switch port (for example through a different WLAN AP).> Packets transmitted at that time would be lost until the binding is updated.Frank=>IMHO, packet loss due to handover seem to be irreleventto packet filtering because of false soure address.The impact is functionally the same for false address use and for mobile devices. The bindin g exists on one port, and then moves to another port without signalling. This is not packet loss due to mobility, the SAVI device would block any such port movement were DAD/MLD/DHCPv6 (take your pick for binding protocol) not to occur. By default, the moving device doesn't perform DAD, as it is in the same Link. ------------------------------------------------------------------------------ _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi --Boundary_(ID_DD/fHAXwaxp/8qYSWiWQFQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Hi Greg
 
"   Optimistic = address - an=20 address that is assigned to an interface=20 and
        available for use, = subject to=20 restrictions, while its = uniqueness
       =20 on a link is being verified.  This memo introduces=20 the
        Optimistic state and = defines=20 its behaviors and restrictions."
 
An address could be used for sending = packets=20 even DAD is ongoing.
That means there is not DAD state=20 established.  It also means it could happen
sending a packet prior to  sending = any DAD=20 message(that is, NS).
 
Please check other inline = responses...
 
BR
Frank
----- Original Message -----
From:=20 Greg Daley
To: Frank Xia ; Christian Vogt
Sent: Thursday, June 25, 2009 = 5:47=20 PM
Subject: Re: [savi] A different = trade off=20 for SAVI

Hi Frank, 

I have highlighted my points below, = which are=20 salient, even though the title has not changed on the = thread.


-----Original Message-----
From: Frank = Xia [mailto:xiayangsong@huawei.com]=
Sent:=20 Thursday, 25 June 2009 8:47 AM
To: Greg Daley; Christian = Vogt
Cc: SAVI=20 Mailing List
Subject: Re: [savi] A different trade off for = SAVI

Hi=20 Greg

Just as the title say "the trade off for SAVI", I prefer = letting a=20 packet go even we are not  sure if it is = legitimate.

Please see my=20 other inline comments...

BR
Frank


>
> In = reference to Frank's discussion of RFC 4429, there is indeed a=20 race condition between
> packet transmission and DAD = operation in=20 Optimistic DAD.  There are already explicit = assumptions
> in=20 that document which outline that packet transmission from optimistic = addresses=20 may be lost
> before DAD is completed.
Frank=3D>That means = Optimistic DAD is not allowed.

Actually, I'd = like to clarify=20 the behaviour of Optimistic DAD (RFC4429) in this = case:

There is no implied delay for the DAD NS delivery in = Optimistic=20 DAD:
 
(Section = 3.3)
   * (modifies section 5.4.2) The host MUST join the =
all-nodes multicast
        address and the solicited-node multicast address of the
        Tentative address.  The host SHOULD NOT delay before sending
        Neighbor Solicitation messages.
Frank=3D>"SHOULD NOT delay" does not mean "sending NS prior to any =
data
packets"
The difference is that packets can be =
sent basically immediately in
Optimistic DAD.  This is valid =
behaviour, and the host knows that by
using an optimistic address =
there is the chance of delivery failure.
No existing Neighbour Discovery Binding is =
overwritten by RFC4429 operations,
so there is no problem with =
Optimistic DAD's impact on the network.  The 
impact is specific to =
the host, which is the functional trade-off built
into optimistic =
DAD.
In summary: It =
does not mean that Optimistic DAD is not allowed.
> This is also the case for mobile devices which are not =
required to always perform full DAD when
> reattaching to the same =
LAN from a different switch port (for example through a different =
WLAN AP).
> Packets transmitted at that time would be lost until =
the binding is updated.
Frank=3D>IMHO, packet loss due to =
handover seem to be irrelevent
to packet filtering because of false =
soure address.

The impact is functionally the = same for=20 false address use and for mobile devices.  The = binding
exists on one port, and then moves to = another port=20 without signalling. 

This is not packet loss due to = mobility, the=20 SAVI device would block any such port movement
were DAD/MLD/DHCPv6 = (take=20 your pick for binding protocol) not to occur.  By default, = the
moving=20 device doesn't perform DAD, as it is in the same Link.

 

_______________________________________________
savi mailing = = list
savi@ietf.org
https://www.ietf.org/mailman/listinfo/savi
--Boundary_(ID_DD/fHAXwaxp/8qYSWiWQFQ)-- From gdaley@netstarnetworks.com Thu Jun 25 16:34:31 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD2543A6840 for ; Thu, 25 Jun 2009 16:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.304 X-Spam-Level: X-Spam-Status: No, score=-1.304 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ud9VtN4yXgJL for ; Thu, 25 Jun 2009 16:34:30 -0700 (PDT) Received: from mail.syd.netstarnetworks.com (mail.syd.netstarnetworks.com [203.8.7.220]) by core3.amsl.com (Postfix) with ESMTP id 37B473A69EF for ; Thu, 25 Jun 2009 16:34:27 -0700 (PDT) Received: from sydmail.netstarnetworks.com ([10.18.193.13]) by mail.syd.netstarnetworks.com (8.12.8/8.12.8) with ESMTP id n5PNWZRs030213; Fri, 26 Jun 2009 09:32:35 +1000 Received: from melmail.netstarnetworks.com ([10.20.193.13]) by sydmail.netstarnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Jun 2009 09:32:31 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9F5ED.356FAC2C" Date: Fri, 26 Jun 2009 09:32:30 +1000 Message-ID: <6983BF97BFC24D4EA551F1407123291801100089@melmail.netstarnetworks.com> In-Reply-To: <005301c9f5ea$7fcaa870$3e0c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [savi] A different trade off for SAVI Thread-Index: Acn16oNFjtGLH3g9T7OUtef26ZYhVgAAnsig References: <4A2C0DFB.3040803@it.uc3m.es> <00e301c9edcf$c7cc7bd0$3e0c7c0a@china.huawei.com> <4A36706D.9050501@it.uc3m.es> <001901c9edda$ff5bceb0$3e0c7c0a@china.huawei.com> <4ECD61DE-172E-486D-A9DC-948DB322D565@ericsson.com> <6983BF97BFC24D4EA551F14071232918010FFEE7@melmail.netstarnetworks.com> <011701c9f51d$b225fae0$3e0c7c0a@china.huawei.com> <6983BF97BFC24D4EA551F1407123291801100069@melmail.netstarnetworks.com> <005301c9f5ea$7fcaa870$3e0c7c0a@china.huawei.com> From: "Greg Daley" To: "Frank Xia" , "Christian Vogt" X-OriginalArrivalTime: 25 Jun 2009 23:32:31.0559 (UTC) FILETIME=[35CF1D70:01C9F5ED] Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 23:34:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9F5ED.356FAC2C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Frank,=20 =20 The point I make again and again is that packet loss is not an issue: =20 The interface is in Optimistic mode so you get what you pay for. =20 With regard to the binding state: If there is no existing binding in the SAVI switch, why not send the packets as soon as a DAD NS is sent? =20 That would also be optimistic! =20 Greg Daley Security Consultant NetStar Australia Pty Ltd E-mail: gdaley@netstarnetworks.com Mobile: +61 401 772 770 Direct: +61 3 8532 4042 Fax: +61 3 8532 4032=20 =20 ________________________________ From: Frank Xia [mailto:xiayangsong@huawei.com]=20 Sent: Friday, 26 June 2009 9:13 AM To: Greg Daley; Christian Vogt Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI Hi Greg =20 " Optimistic address - an address that is assigned to an interface and available for use, subject to restrictions, while its uniqueness on a link is being verified. This memo introduces the Optimistic state and defines its behaviors and restrictions." =20 An address could be used for sending packets even DAD is ongoing. That means there is not DAD state established. It also means it could happen sending a packet prior to sending any DAD message(that is, NS). =20 Please check other inline responses... =20 BR Frank ----- Original Message -----=20 From: Greg Daley =20 To: Frank Xia ; Christian Vogt =20 Cc: SAVI Mailing List =20 Sent: Thursday, June 25, 2009 5:47 PM Subject: Re: [savi] A different trade off for SAVI =09 =09 Hi Frank,=20 I have highlighted my points below, which are salient, even though the title has not changed on the thread. =09 -----Original Message----- From: Frank Xia [mailto:xiayangsong@huawei.com] Sent: Thursday, 25 June 2009 8:47 AM To: Greg Daley; Christian Vogt Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI =09 Hi Greg =09 Just as the title say "the trade off for SAVI", I prefer letting a packet go even we are not sure if it is legitimate. =09 Please see my other inline comments... =09 BR Frank =09 =09 > > In reference to Frank's discussion of RFC 4429, there is indeed a race condition between > packet transmission and DAD operation in Optimistic DAD. There are already explicit assumptions > in that document which outline that packet transmission from optimistic addresses may be lost > before DAD is completed. Frank=3D>That means Optimistic DAD is not allowed. =09 Actually, I'd like to clarify the behaviour of Optimistic DAD (RFC4429) in this case: There is no implied delay for the DAD NS delivery in Optimistic DAD: =20 (Section 3.3) * (modifies section 5.4.2) The host MUST join the all-nodes multicast address and the solicited-node multicast address of the Tentative address. The host SHOULD NOT delay before sending Neighbor Solicitation messages. Frank=3D>"SHOULD NOT delay" does not mean "sending NS prior to any data packets" The difference is that packets can be sent basically immediately in Optimistic DAD. This is valid behaviour, and the host knows that by using an optimistic address there is the chance of delivery failure. No existing Neighbour Discovery Binding is overwritten by RFC4429 operations, so there is no problem with Optimistic DAD's impact on the network. The=20 impact is specific to the host, which is the functional trade-off built into optimistic DAD. In summary: It does not mean that Optimistic DAD is not allowed. > This is also the case for mobile devices which are not required to always perform full DAD when > reattaching to the same LAN from a different switch port (for example through a different WLAN AP). > Packets transmitted at that time would be lost until the binding is updated. Frank=3D>IMHO, packet loss due to handover seem to be irrelevent to packet filtering because of false soure address. The impact is functionally the same for false address use and for mobile devices. The binding exists on one port, and then moves to another port without signalling.=20 This is not packet loss due to mobility, the SAVI device would block any such port movement were DAD/MLD/DHCPv6 (take your pick for binding protocol) not to occur. By default, the moving device doesn't perform DAD, as it is in the same Link. =20 =09 =09 ________________________________ =09 _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi =09 ------_=_NextPart_001_01C9F5ED.356FAC2C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Frank,
 
The point I make again and again is that packet = loss is not an=20 issue:
 
The interface is in Optimistic mode so you get = what you pay=20 for.
 
With regard to the binding state: If there is no = existing=20 binding in the SAVI
switch, why not send the packets as soon as a DAD = NS is=20 sent?
 
That would also be optimistic!
 

Greg Daley
Security Consultant
NetStar Australia = Pty=20 Ltd

E-mail: gdaley@netstarnetworks.com
Mobile: +61 401 772=20 770
Direct: +61 3 8532 4042
Fax:    +61 3 8532 = 4032=20

 

From: Frank Xia = [mailto:xiayangsong@huawei.com]=20
Sent: Friday, 26 June 2009 9:13 AM
To: Greg Daley;=20 Christian Vogt
Cc: SAVI Mailing List
Subject: Re: = [savi] A=20 different trade off for SAVI

Hi Greg
 
"   Optimistic = address - an=20 address that is assigned to an interface=20 and
        available for use, = subject to=20 restrictions, while its = uniqueness
       =20 on a link is being verified.  This memo introduces=20 the
        Optimistic state and = defines=20 its behaviors and restrictions."
 
An address could be used for sending = packets=20 even DAD is ongoing.
That means there is not DAD state=20 established.  It also means it could happen
sending a packet prior to  sending = any DAD=20 message(that is, NS).
 
Please check other inline = responses...
 
BR
Frank
----- Original Message -----
From:=20 Greg Daley
To: Frank Xia ; Christian Vogt
Sent: Thursday, June 25, 2009 = 5:47=20 PM
Subject: Re: [savi] A different = trade off=20 for SAVI

Hi Frank, 

I have highlighted my points below, = which are=20 salient, even though the title has not changed on the = thread.


-----Original Message-----
From: Frank Xia = [mailto:xiayangsong@huawei.com]=
Sent:=20 Thursday, 25 June 2009 8:47 AM
To: Greg Daley; Christian = Vogt
Cc: SAVI=20 Mailing List
Subject: Re: [savi] A different trade off for = SAVI

Hi=20 Greg

Just as the title say "the trade off for SAVI", I prefer = letting a=20 packet go even we are not  sure if it is = legitimate.

Please see my=20 other inline comments...

BR
Frank


>
> In = reference to Frank's discussion of RFC 4429, there is indeed a=20 race condition between
> packet transmission and DAD = operation in=20 Optimistic DAD.  There are already explicit = assumptions
> in=20 that document which outline that packet transmission from optimistic = addresses=20 may be lost
> before DAD is completed.
Frank=3D>That means = Optimistic DAD is not allowed.

Actually, I'd = like to clarify=20 the behaviour of Optimistic DAD (RFC4429) in this = case:

There is no implied delay for the DAD NS delivery in = Optimistic=20 DAD:
 
(Section = 3.3)
   * (modifies section 5.4.2) The host MUST join the =
all-nodes multicast
        address and the solicited-node multicast address of the
        Tentative address.  The host SHOULD NOT delay before sending
        Neighbor Solicitation messages.
Frank=3D>"SHOULD NOT delay" does not mean "sending NS prior to any =
data
packets"
The =
difference is that packets can be sent basically immediately =
in
Optimistic DAD.  This is valid behaviour, and the host knows that =
by
using an optimistic address there is the chance of delivery =
failure.
No existing =
Neighbour Discovery Binding is overwritten by RFC4429 operations,
so =
there is no problem with Optimistic DAD's impact on the network.  The =

impact is specific to the host, which is the functional trade-off =
built
into optimistic DAD.
In summary: It does not mean that Optimistic DAD is not =
allowed.
> This is also the case for =
mobile devices which are not required to always perform full DAD =
when
> reattaching to the same LAN from a different switch port =
(for example through a different WLAN AP).
> Packets =
transmitted at that time would be lost until the binding =
is updated.
Frank=3D>IMHO, packet loss due to handover seem =
to be irrelevent
to packet filtering because of false soure =
address.

The impact is functionally the = same for=20 false address use and for mobile devices.  The = binding
exists on one port, and then moves to = another port=20 without signalling. 

This is not packet loss due to = mobility, the=20 SAVI device would block any such port movement
were DAD/MLD/DHCPv6 = (take=20 your pick for binding protocol) not to occur.  By default, = the
moving=20 device doesn't perform DAD, as it is in the same Link.

 

_______________________________________________
savi mailing = = list
savi@ietf.org
https://www.ietf.org/mailman/listinfo/savi
------_=_NextPart_001_01C9F5ED.356FAC2C-- From gdaley@netstarnetworks.com Thu Jun 25 16:35:25 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ED923A68A4 for ; Thu, 25 Jun 2009 16:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.555 X-Spam-Level: X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0rbQXyEMvNm for ; Thu, 25 Jun 2009 16:35:24 -0700 (PDT) Received: from mail.syd.netstarnetworks.com (mail.syd.netstarnetworks.com [203.8.7.220]) by core3.amsl.com (Postfix) with ESMTP id 750933A6840 for ; Thu, 25 Jun 2009 16:35:24 -0700 (PDT) Received: from sydmail.netstarnetworks.com ([10.18.193.13]) by mail.syd.netstarnetworks.com (8.12.8/8.12.8) with ESMTP id n5PNY7Rs030268; Fri, 26 Jun 2009 09:34:07 +1000 Received: from melmail.netstarnetworks.com ([10.20.193.13]) by sydmail.netstarnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Jun 2009 09:34:03 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Jun 2009 09:34:02 +1000 Message-ID: <6983BF97BFC24D4EA551F140712329180110008B@melmail.netstarnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [savi] On the Protection of Unused Addresses Thread-Index: Acn16VRP8ZxWYpxfQw6lnPSVLdZdUAABAQ0w References: <81955095-4CA3-41E8-8435-99B2AF644621@ericsson.com><9E06E8D3-EED1-42FC-8D78-90626E341CD8@cisco.com> From: "Greg Daley" To: "Fred Baker" , "Christian Vogt" X-OriginalArrivalTime: 25 Jun 2009 23:34:03.0371 (UTC) FILETIME=[6C8883B0:01C9F5ED] Cc: SAVI Mailing List Subject: Re: [savi] On the Protection of Unused Addresses X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 23:35:25 -0000 =20 > Given that there is no product on the market today that uses DHCP for address assignment... No product announcements ? ;-) Greg From gdaley@netstarnetworks.com Thu Jun 25 16:35:34 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 937EC3A6840 for ; Thu, 25 Jun 2009 16:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.632 X-Spam-Level: X-Spam-Status: No, score=-0.632 tagged_above=-999 required=5 tests=[AWL=-0.887, BAYES_20=-0.74, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HGt-fxvWgX6 for ; Thu, 25 Jun 2009 16:35:33 -0700 (PDT) Received: from mail.syd.netstarnetworks.com (mail.syd.netstarnetworks.com [203.8.7.220]) by core3.amsl.com (Postfix) with ESMTP id 83CE63A68A4 for ; Thu, 25 Jun 2009 16:35:33 -0700 (PDT) Received: from sydmail.netstarnetworks.com ([10.18.193.13]) by mail.syd.netstarnetworks.com (8.12.8/8.12.8) with ESMTP id n5PNUFRs030073; Fri, 26 Jun 2009 09:30:26 +1000 Received: from melmail.netstarnetworks.com ([10.20.193.13]) by sydmail.netstarnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Jun 2009 09:30:11 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9F5EC.E1D7388C" Date: Fri, 26 Jun 2009 09:30:10 +1000 Message-ID: <6983BF97BFC24D4EA551F1407123291801100086@melmail.netstarnetworks.com> In-Reply-To: <000801c9f5aa$fe34fa20$3e0c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [savi] feasibility of impmentation SAVI in a switch Thread-Index: Acn1qzoPwnq0dMlkRQW5cKbrABl6zQAQXdEw References: <000801c9f5aa$fe34fa20$3e0c7c0a@china.huawei.com> From: "Greg Daley" To: "Frank Xia" , "SAVI Mailing List" X-OriginalArrivalTime: 25 Jun 2009 23:30:11.0341 (UTC) FILETIME=[E23B8BD0:01C9F5EC] Subject: Re: [savi] feasibility of impmentation SAVI in a switch X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 23:35:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9F5EC.E1D7388C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Frank, =20 We are talking about the sort of switches which can already snoop MLD. =20 =20 Greg Daley Security Consultant NetStar Australia Pty Ltd E-mail: gdaley@netstarnetworks.com Mobile: +61 401 772 770 Direct: +61 3 8532 4042 Fax: +61 3 8532 4032=20 =20 ________________________________ From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Frank Xia Sent: Friday, 26 June 2009 1:38 AM To: SAVI Mailing List Subject: [savi] feasibility of impmentation SAVI in a switch Hi Guys =20 This question has been obsessing me for a while. =20 Aside from high end switches (such as layer 3 switches), most switches use commercial chips which only inspect layer 2 information(mac, vlan,etc). At the same time, SAVI requires switches to parse layer 3 information of each packet. =20 =20 Apparantly, current switch chips can not handle this. =20 That means switch vendors should in turn require chip vendors to support this feature. =20 IMHO, the impact of chip design probably will impede the adoption of SAVI in switch. =20 BR Frank =20 ------_=_NextPart_001_01C9F5EC.E1D7388C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Frank,
 
We are talking about the sort of switches which = can already=20 snoop MLD.
 
 

Greg Daley
Security = Consultant
NetStar=20 Australia Pty Ltd

E-mail: gdaley@netstarnetworks.com
Mobile: = +61 401=20 772 770
Direct: +61 3 8532 4042
Fax:    +61 3 8532=20 4032

 

From: = savi-bounces@ietf.org=20 [mailto:savi-bounces@ietf.org] On Behalf Of Frank = Xia
Sent:=20 Friday, 26 June 2009 1:38 AM
To: SAVI Mailing = List
Subject:=20 [savi] feasibility of impmentation SAVI in a = switch

Hi Guys
 
This question has been obsessing = me for a=20 while.
 
Aside from high end switches (such as = layer 3=20 switches),
most switches use commercial chips = which only=20 inspect
layer 2 information(mac, = vlan,etc).  At the=20 same time,
SAVI requires switches to parse layer 3 = information=20 of
each packet. 
 
Apparantly, current switch chips can = not handle=20 this. 
That means switch vendors should = in turn=20 require
chip vendors to support this = feature.
 
IMHO, the impact of chip design = probably will=20 impede
the adoption of SAVI in = switch.
 
BR
Frank
 
------_=_NextPart_001_01C9F5EC.E1D7388C-- From christian.vogt@ericsson.com Thu Jun 25 18:08:06 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2F483A69EF for ; Thu, 25 Jun 2009 18:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGg68aPUvtOE for ; Thu, 25 Jun 2009 18:08:06 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 849373A6452 for ; Thu, 25 Jun 2009 18:08:05 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n5PMxprg026307; Thu, 25 Jun 2009 17:59:52 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jun 2009 17:59:51 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jun 2009 17:59:51 -0500 Message-Id: <20DEB994-56B6-4D86-98BD-6C5F9CA56A5D@ericsson.com> From: Christian Vogt To: Eric Levy-Abegnoli In-Reply-To: <4A42591A.5060408@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 25 Jun 2009 15:59:50 -0700 References: <4A2C0DFB.3040803@it.uc3m.es> <4A2D2221.4030503@cisco.com> <4A2D2739.1000206@it.uc3m.es> <4A2F9E29.5070704@cisco.com> <4A30D6CD.8060209@it.uc3m.es> <49417952-8570-467E-B312-B759DC3D88DD@ericsson.com> <4A35ECEE.7060801@cisco.com> <86861CC6-385A-4CBA-9B9C-5D7E56EF119B@ericsson.com> <4A42591A.5060408@cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 25 Jun 2009 22:59:51.0258 (UTC) FILETIME=[A560EBA0:01C9F5E8] Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 01:08:07 -0000 Eric - > As far as the fcfs variant (is this the logging instead of droping > proposal?) I think it's a bad idea. If the switch does not drop, it > will > endup with binding inconsistent with end-nodes (4861/4862 are not > first-come first-serve based). This incosisyency will lead to a lot > more > logging than desirable. And on top of that, logging is often harmful > and > useless. Can you clarify which binding inconsistencies you are concerned about in FCFS? > Then this is me who mis-understood what you said: [DAD] it gives the > victim of a spoofing attack a chance to speak up. The attacker would > obviously not do DAD on the address he plans to spoof. So I took that > you meant victim = DAD sender. Then I see two cases: > > 1) There was initially no owner for the address in the binding table, > one is created on the NS DAD, and the NA (response), carrying a > different binding should be rejected by the switch (or a least not > change the binding entry). If not blocked, the DAD sender end up > with no > address. Binding table with bogus binding. But this is not how current SAVI solution proposals work. All current proposals would tentatively create a binding upon a DAD solicitation, and remove this binding upon a DAD response. Spoofed DAD responses are discarded by a SAVI device. > 2) There was initially a owner, the DAD NS should be sent to him (and > nobody else in my opinion); response sent back to him, binding table > not > changed. This is not a spoofing scenario. Right. In this case, the DAD response is not discarded because it corresponds to an existing binding. > So in that case, what DAD gives you over the other NDP messages? In > my > opinion, just an opportunity for the attacker to prevent the DAD > sender > to use an address. So it's rather a caveat than a chance. Can you clarify? I can't see your point. - Christian From gdaley@netstarnetworks.com Thu Jun 25 18:45:49 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 297263A6A59 for ; Thu, 25 Jun 2009 18:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSL2Ye-RZlSx for ; Thu, 25 Jun 2009 18:45:48 -0700 (PDT) Received: from mail.syd.netstarnetworks.com (mail.syd.netstarnetworks.com [203.8.7.220]) by core3.amsl.com (Postfix) with ESMTP id 193A53A6452 for ; Thu, 25 Jun 2009 18:45:47 -0700 (PDT) Received: from sydmail.netstarnetworks.com ([10.18.193.13]) by mail.syd.netstarnetworks.com (8.12.8/8.12.8) with ESMTP id n5Q1ixRs004909; Fri, 26 Jun 2009 11:44:59 +1000 Received: from melmail.netstarnetworks.com ([10.20.193.13]) by sydmail.netstarnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Jun 2009 11:44:53 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Jun 2009 11:44:52 +1000 Message-ID: <6983BF97BFC24D4EA551F14071232918011000EC@melmail.netstarnetworks.com> In-Reply-To: <20DEB994-56B6-4D86-98BD-6C5F9CA56A5D@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [savi] A different trade off for SAVI Thread-Index: Acn1+p1EhR2gOSjFRtG3/HeaoCQbyAABEaSA References: <4A2C0DFB.3040803@it.uc3m.es> <4A2D2221.4030503@cisco.com><4A2D2739.1000206@it.uc3m.es> <4A2F9E29.5070704@cisco.com><4A30D6CD.8060209@it.uc3m.es><49417952-8570-467E-B312-B759DC3D88DD@ericsson.com><4A35ECEE.7060801@cisco.com><86861CC6-385A-4CBA-9B9C-5D7E56EF119B@ericsson.com><4A42591A.5060408@cisco.com> <20DEB994-56B6-4D86-98BD-6C5F9CA56A5D@ericsson.com> From: "Greg Daley" To: "Christian Vogt" , "Eric Levy-Abegnoli" X-OriginalArrivalTime: 26 Jun 2009 01:44:53.0462 (UTC) FILETIME=[B38D5760:01C9F5FF] Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 01:45:49 -0000 Hi Christian, I think that Eric points out that monitoring ports for any ND=20 (in the same fashion that one could monitor ARP today) will identify that the addresses are in use, independent of whether the DAD message has been sent. This would allow the SAVI device to make bindings on unused addresses once it sees that the address is functionally in use, even if it doesn't see the DAD NS. Greg Daley Security Consultant NetStar Australia Pty Ltd E-mail: gdaley@netstarnetworks.com Mobile: +61 401 772 770 Direct: +61 3 8532 4042 Fax: +61 3 8532 4032 -----Original Message----- From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Christian Vogt Sent: Friday, 26 June 2009 9:00 AM To: Eric Levy-Abegnoli Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI Eric - > As far as the fcfs variant (is this the logging instead of droping > proposal?) I think it's a bad idea. If the switch does not drop, it=20 > will endup with binding inconsistent with end-nodes (4861/4862 are not > first-come first-serve based). This incosisyency will lead to a lot=20 > more logging than desirable. And on top of that, logging is often=20 > harmful and useless. Can you clarify which binding inconsistencies you are concerned about in FCFS? > Then this is me who mis-understood what you said: [DAD] it gives the=20 > victim of a spoofing attack a chance to speak up. The attacker would=20 > obviously not do DAD on the address he plans to spoof. So I took that=20 > you meant victim =3D DAD sender. Then I see two cases: > > 1) There was initially no owner for the address in the binding table,=20 > one is created on the NS DAD, and the NA (response), carrying a=20 > different binding should be rejected by the switch (or a least not=20 > change the binding entry). If not blocked, the DAD sender end up with=20 > no address. Binding table with bogus binding. But this is not how current SAVI solution proposals work. All current proposals would tentatively create a binding upon a DAD solicitation, and remove this binding upon a DAD response. Spoofed DAD responses are discarded by a SAVI device. > 2) There was initially a owner, the DAD NS should be sent to him (and > nobody else in my opinion); response sent back to him, binding table=20 > not changed. This is not a spoofing scenario. Right. In this case, the DAD response is not discarded because it corresponds to an existing binding. > So in that case, what DAD gives you over the other NDP messages? In=20 > my opinion, just an opportunity for the attacker to prevent the DAD=20 > sender to use an address. So it's rather a caveat than a chance. Can you clarify? I can't see your point. - Christian _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi From xiayangsong@huawei.com Thu Jun 25 19:09:41 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 190883A6AC6 for ; Thu, 25 Jun 2009 19:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.695 X-Spam-Level: X-Spam-Status: No, score=-0.695 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ktsu752uSFk for ; Thu, 25 Jun 2009 19:09:40 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id E56833A6AA6 for ; Thu, 25 Jun 2009 19:09:39 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLT006MUPZDXI@szxga04-in.huawei.com> for savi@ietf.org; Fri, 26 Jun 2009 10:09:13 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLT00GMWPZDNH@szxga04-in.huawei.com> for savi@ietf.org; Fri, 26 Jun 2009 10:09:13 +0800 (CST) Received: from X24512z ([10.51.0.73]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLT00558PZ87N@szxml06-in.huawei.com> for savi@ietf.org; Fri, 26 Jun 2009 10:09:13 +0800 (CST) Date: Thu, 25 Jun 2009 21:09:08 -0500 From: Frank Xia To: Greg Daley , SAVI Mailing List Message-id: <008a01c9f603$18bb4270$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_LKhMIVar/VGEGGI3s2enmw)" X-Priority: 3 X-MSMail-priority: Normal References: <000801c9f5aa$fe34fa20$3e0c7c0a@china.huawei.com> <6983BF97BFC24D4EA551F1407123291801100086@melmail.netstarnetworks.com> Subject: Re: [savi] feasibility of impmentation SAVI in a switch X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 02:09:41 -0000 This is a multi-part message in MIME format. --Boundary_(ID_LKhMIVar/VGEGGI3s2enmw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Greg Each switch has programable CPU could easily handle snooping MLD/DAD/DHCP etc, and each switch also has non-programable ASIC to forward packets. I am talking about SAVI packets forwarding processing which changes switches normal behavior which ususally inspects only layer 2. BR Frank ----- Original Message ----- From: Greg Daley To: Frank Xia ; SAVI Mailing List Sent: Thursday, June 25, 2009 6:30 PM Subject: Re: [savi] feasibility of impmentation SAVI in a switch Hi Frank, We are talking about the sort of switches which can already snoop MLD. Greg Daley Security Consultant NetStar Australia Pty Ltd E-mail: gdaley@netstarnetworks.com Mobile: +61 401 772 770 Direct: +61 3 8532 4042 Fax: +61 3 8532 4032 ------------------------------------------------------------------------------ From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Frank Xia Sent: Friday, 26 June 2009 1:38 AM To: SAVI Mailing List Subject: [savi] feasibility of impmentation SAVI in a switch Hi Guys This question has been obsessing me for a while. Aside from high end switches (such as layer 3 switches), most switches use commercial chips which only inspect layer 2 information(mac, vlan,etc). At the same time, SAVI requires switches to parse layer 3 information of each packet. Apparantly, current switch chips can not handle this. That means switch vendors should in turn require chip vendors to support this feature. IMHO, the impact of chip design probably will impede the adoption of SAVI in switch. BR Frank ------------------------------------------------------------------------------ _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi --Boundary_(ID_LKhMIVar/VGEGGI3s2enmw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Greg
 
Each switch has programable CPU could easily handle snooping
MLD/DAD/DHCP etc, and each switch also has non-programable
 ASIC to forward packets.
 
I am talking about SAVI packets forwarding processing which
changes switches normal behavior which ususally inspects only
layer 2.
 
BR
Frank
----- Original Message -----
From: Greg Daley
Sent: Thursday, June 25, 2009 6:30 PM
Subject: Re: [savi] feasibility of impmentation SAVI in a switch

Hi Frank,
 
We are talking about the sort of switches which can already snoop MLD.
 
 

Greg Daley
Security Consultant
NetStar Australia Pty Ltd

E-mail: gdaley@netstarnetworks.com
Mobile: +61 401 772 770
Direct: +61 3 8532 4042
Fax:    +61 3 8532 4032

 

From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Frank Xia
Sent: Friday, 26 June 2009 1:38 AM
To: SAVI Mailing List
Subject: [savi] feasibility of impmentation SAVI in a switch

Hi Guys
 
This question has been obsessing me for a while.
 
Aside from high end switches (such as layer 3 switches),
most switches use commercial chips which only inspect
layer 2 information(mac, vlan,etc).  At the same time,
SAVI requires switches to parse layer 3 information of
each packet. 
 
Apparantly, current switch chips can not handle this. 
That means switch vendors should in turn require
chip vendors to support this feature.
 
IMHO, the impact of chip design probably will impede
the adoption of SAVI in switch.
 
BR
Frank
 

_______________________________________________
savi mailing list
savi@ietf.org
https://www.ietf.org/mailman/listinfo/savi
--Boundary_(ID_LKhMIVar/VGEGGI3s2enmw)-- From xiayangsong@huawei.com Thu Jun 25 19:12:58 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 513413A6A99 for ; Thu, 25 Jun 2009 19:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.082 X-Spam-Level: X-Spam-Status: No, score=-0.082 tagged_above=-999 required=5 tests=[AWL=-0.788, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_102=0.6, J_CHICKENPOX_74=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iO34ZjUXLD6f for ; Thu, 25 Jun 2009 19:12:57 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 90E753A6AA8 for ; Thu, 25 Jun 2009 19:12:56 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLT00GO5Q4C5K@szxga04-in.huawei.com> for savi@ietf.org; Fri, 26 Jun 2009 10:12:12 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLT00DBMQ4C8B@szxga04-in.huawei.com> for savi@ietf.org; Fri, 26 Jun 2009 10:12:12 +0800 (CST) Received: from X24512z ([10.51.0.73]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLT00HSMQ3YTC@szxml06-in.huawei.com> for savi@ietf.org; Fri, 26 Jun 2009 10:12:12 +0800 (CST) Date: Thu, 25 Jun 2009 21:11:54 -0500 From: Frank Xia To: Greg Daley , Christian Vogt Message-id: <009d01c9f603$7f130ee0$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_5o5Ejv/PsB6oXI2Tv5Qg0A)" X-Priority: 3 X-MSMail-priority: Normal References: <4A2C0DFB.3040803@it.uc3m.es> <00e301c9edcf$c7cc7bd0$3e0c7c0a@china.huawei.com> <4A36706D.9050501@it.uc3m.es> <001901c9edda$ff5bceb0$3e0c7c0a@china.huawei.com> <4ECD61DE-172E-486D-A9DC-948DB322D565@ericsson.com> <6983BF97BFC24D4EA551F14071232918010FFEE7@melmail.netstarnetworks.com> <011701c9f51d$b225fae0$3e0c7c0a@china.huawei.com> <6983BF97BFC24D4EA551F1407123291801100069@melmail.netstarnetworks.com> <005301c9f5ea$7fcaa870$3e0c7c0a@china.huawei.com> <6983BF97BFC24D4EA551F1407123291801100089@melmail.netstarnetworks.com> Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 02:12:58 -0000 This is a multi-part message in MIME format. --Boundary_(ID_5o5Ejv/PsB6oXI2Tv5Qg0A) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi Greg >From my perspective, legitimate packets loss IS an issue. BR Frank ----- Original Message -----=20 From: Greg Daley=20 To: Frank Xia ; Christian Vogt=20 Cc: SAVI Mailing List=20 Sent: Thursday, June 25, 2009 6:32 PM Subject: Re: [savi] A different trade off for SAVI Hi Frank,=20 The point I make again and again is that packet loss is not an issue: The interface is in Optimistic mode so you get what you pay for. With regard to the binding state: If there is no existing binding in = the SAVI switch, why not send the packets as soon as a DAD NS is sent? That would also be optimistic! Greg Daley Security Consultant NetStar Australia Pty Ltd E-mail: gdaley@netstarnetworks.com Mobile: +61 401 772 770 Direct: +61 3 8532 4042 Fax: +61 3 8532 4032=20 -------------------------------------------------------------------------= ----- From: Frank Xia [mailto:xiayangsong@huawei.com]=20 Sent: Friday, 26 June 2009 9:13 AM To: Greg Daley; Christian Vogt Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI Hi Greg " Optimistic address - an address that is assigned to an interface = and available for use, subject to restrictions, while its = uniqueness on a link is being verified. This memo introduces the Optimistic state and defines its behaviors and restrictions." An address could be used for sending packets even DAD is ongoing. That means there is not DAD state established. It also means it could = happen sending a packet prior to sending any DAD message(that is, NS). Please check other inline responses... BR Frank ----- Original Message -----=20 From: Greg Daley=20 To: Frank Xia ; Christian Vogt=20 Cc: SAVI Mailing List=20 Sent: Thursday, June 25, 2009 5:47 PM Subject: Re: [savi] A different trade off for SAVI Hi Frank,=20 I have highlighted my points below, which are salient, even though = the title has not changed on the thread. -----Original Message----- From: Frank Xia [mailto:xiayangsong@huawei.com] Sent: Thursday, 25 June 2009 8:47 AM To: Greg Daley; Christian Vogt Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI Hi Greg Just as the title say "the trade off for SAVI", I prefer letting a = packet go even we are not sure if it is legitimate. Please see my other inline comments... BR Frank > > In reference to Frank's discussion of RFC 4429, there is indeed a = race condition between > packet transmission and DAD operation in Optimistic DAD. There = are already explicit assumptions > in that document which outline that packet transmission from = optimistic addresses may be lost > before DAD is completed. Frank=3D>That means Optimistic DAD is not allowed. Actually, I'd like to clarify the behaviour of Optimistic DAD = (RFC4429) in this case: There is no implied delay for the DAD NS delivery in Optimistic DAD: (Section 3.3) * (modifies section 5.4.2) The host MUST join the all-nodes multicast address and the solicited-node multicast address of the Tentative address. The host SHOULD NOT delay before sending Neighbor Solicitation messages. Frank=3D>"SHOULD NOT delay" does not mean "sending NS prior to any = datapackets"The difference is that packets can be sent basically = immediately inOptimistic DAD. This is valid behaviour, and the host = knows that byusing an optimistic address there is the chance of delivery = failure.No existing Neighbour Discovery Binding is overwritten by = RFC4429 operations,so there is no problem with Optimistic DAD's impact = on the network. The impact is specific to the host, which is the = functional trade-off builtinto optimistic DAD.In summary: It does not = mean that Optimistic DAD is not allowed.> This is also the case for = mobile devices which are not required to always perform full DAD when> = reattaching to the same LAN from a different switch port (for example = through a different WLAN AP).> Packets transmitted at that time would be = lost until the binding is updated.Frank=3D>IMHO, packet loss due to = handover seem to be irreleventto packet filtering because of false soure = address.The impact is functionally the same for false address use and = for mobile devices. The binding exists on one port, and then moves to another port without = signalling.=20 This is not packet loss due to mobility, the SAVI device would block = any such port movement were DAD/MLD/DHCPv6 (take your pick for binding protocol) not to = occur. By default, the moving device doesn't perform DAD, as it is in the same Link. -------------------------------------------------------------------------= --- _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi -------------------------------------------------------------------------= ----- _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi --Boundary_(ID_5o5Ejv/PsB6oXI2Tv5Qg0A) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Hi Greg
 
From my perspective,  legitimate = packets loss=20 IS an issue.
 
BR
Frank
----- Original Message -----
From:=20 Greg Daley
To: Frank Xia ; Christian Vogt
Sent: Thursday, June 25, 2009 = 6:32=20 PM
Subject: Re: [savi] A different = trade off=20 for SAVI

Hi Frank,
 
The point I make again and again is that = packet loss is=20 not an issue:
 
The interface is in Optimistic mode so you = get what you=20 pay for.
 
With regard to the binding state: If there is = no existing=20 binding in the SAVI
switch, why not send the packets as soon as a = DAD NS is=20 sent?
 
That would also be = optimistic!
 

Greg Daley
Security Consultant
NetStar = Australia Pty=20 Ltd

E-mail: gdaley@netstarnetworks.com=
Mobile:=20 +61 401 772 770
Direct: +61 3 8532 4042
Fax:    = +61 3=20 8532 4032

 

From: Frank Xia=20 [mailto:xiayangsong@huawei.com]
Sent: Friday, 26 June 2009 = 9:13=20 AM
To: Greg Daley; Christian Vogt
Cc: SAVI Mailing = List
Subject: Re: [savi] A different trade off for=20 SAVI

Hi Greg
 
"   = Optimistic address -=20 an address that is assigned to an interface=20 and
        available for use, = subject=20 to restrictions, while its=20 uniqueness
        on a link is = being=20 verified.  This memo introduces=20 the
        Optimistic state and = defines=20 its behaviors and restrictions."
 
An address could be used for sending = packets=20 even DAD is ongoing.
That means there is not DAD state=20 established.  It also means it could happen
sending a packet prior to  = sending any DAD=20 message(that is, NS).
 
Please check other inline=20 responses...
 
BR
Frank
----- Original Message -----
From:=20 Greg Daley
To: Frank Xia ; Christian Vogt =
Sent: Thursday, June 25, 2009 = 5:47=20 PM
Subject: Re: [savi] A = different trade=20 off for SAVI

Hi Frank, 

I have highlighted my points below, = which are=20 salient, even though the title has not changed on the = thread.


-----Original Message-----
From: Frank = Xia [mailto:xiayangsong@huawei.com]=
Sent:=20 Thursday, 25 June 2009 8:47 AM
To: Greg Daley; Christian = Vogt
Cc: SAVI=20 Mailing List
Subject: Re: [savi] A different trade off for = SAVI

Hi=20 Greg

Just as the title say "the trade off for SAVI", I prefer = letting=20 a packet go even we are not  sure if it is = legitimate.

Please=20 see my other inline = comments...

BR
Frank


>
>=20 In reference to Frank's discussion of RFC 4429, there is indeed a=20 race condition between
> packet transmission and DAD = operation in=20 Optimistic DAD.  There are already explicit = assumptions
> in=20 that document which outline that packet transmission from optimistic = addresses may be lost
> before DAD is = completed.
Frank=3D>That=20 means Optimistic DAD is not allowed.

Actually, I'd = like to clarify=20 the behaviour of Optimistic DAD (RFC4429) in this = case:

There is no implied delay for the DAD NS delivery in = Optimistic DAD:
 
(Section = 3.3)
   * (modifies section 5.4.2) The host MUST join the =
all-nodes multicast
        address and the solicited-node multicast address of the
        Tentative address.  The host SHOULD NOT delay before sending
        Neighbor Solicitation messages.
Frank=3D>"SHOULD NOT delay" does not mean "sending NS prior to any =
data
packets"
The =
difference is that packets can be sent basically immediately =
in
Optimistic DAD.  This is valid behaviour, and the host knows that =
by
using an optimistic address there is the chance of delivery =
failure.
No existing =
Neighbour Discovery Binding is overwritten by RFC4429 operations,
so =
there is no problem with Optimistic DAD's impact on the network.  The =

impact is specific to the host, which is the functional trade-off =
built
into optimistic DAD.
In summary: It does not mean that Optimistic DAD is not =
allowed.
> This is also the case for =
mobile devices which are not required to always perform full DAD =
when
> reattaching to the same LAN from a different switch port =
(for example through a different WLAN AP).
> Packets =
transmitted at that time would be lost until the binding =
is updated.
Frank=3D>IMHO, packet loss due to handover seem =
to be irrelevent
to packet filtering because of false soure =
address.

The impact is functionally the = same for=20 false address use and for mobile devices.  The = binding
exists on one port, and then moves to = another port=20 without signalling. 

This is not packet loss due to = mobility,=20 the SAVI device would block any such port movement
were = DAD/MLD/DHCPv6=20 (take your pick for binding protocol) not to occur.  By = default,=20 the
moving device doesn't perform DAD, as it is in the same=20 Link.

 

_______________________________________________
savi = mailing=20 = list
savi@ietf.org
https://www.ietf.org/mailman/listinfo/savi

_______________________________________________
savi mailing = = list
savi@ietf.org
https://www.ietf.org/mailman/listinfo/savi
--Boundary_(ID_5o5Ejv/PsB6oXI2Tv5Qg0A)-- From gdaley@netstarnetworks.com Thu Jun 25 19:25:03 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 627D83A6849 for ; Thu, 25 Jun 2009 19:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.468 X-Spam-Level: X-Spam-Status: No, score=-1.468 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CRY43n3QNDC for ; Thu, 25 Jun 2009 19:25:02 -0700 (PDT) Received: from mail.syd.netstarnetworks.com (mail.syd.netstarnetworks.com [203.8.7.220]) by core3.amsl.com (Postfix) with ESMTP id B10EA3A6A26 for ; Thu, 25 Jun 2009 19:25:01 -0700 (PDT) Received: from sydmail.netstarnetworks.com ([10.18.193.13]) by mail.syd.netstarnetworks.com (8.12.8/8.12.8) with ESMTP id n5Q2ONRs007914; Fri, 26 Jun 2009 12:24:31 +1000 Received: from melmail.netstarnetworks.com ([10.20.193.13]) by sydmail.netstarnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Jun 2009 12:24:16 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9F605.33EB1B1C" Date: Fri, 26 Jun 2009 12:24:15 +1000 Message-ID: <6983BF97BFC24D4EA551F1407123291801100105@melmail.netstarnetworks.com> In-Reply-To: <008a01c9f603$18bb4270$3e0c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [savi] feasibility of impmentation SAVI in a switch Thread-Index: Acn2Axuug0jzVwS7QxiDk1vO0Sz4egAAB2Nw References: <000801c9f5aa$fe34fa20$3e0c7c0a@china.huawei.com> <6983BF97BFC24D4EA551F1407123291801100086@melmail.netstarnetworks.com> <008a01c9f603$18bb4270$3e0c7c0a@china.huawei.com> From: "Greg Daley" To: "Frank Xia" , "SAVI Mailing List" X-OriginalArrivalTime: 26 Jun 2009 02:24:16.0712 (UTC) FILETIME=[3428AC80:01C9F605] Subject: Re: [savi] feasibility of impmentation SAVI in a switch X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 02:25:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9F605.33EB1B1C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Frank,=20 =20 I think we can safely say that customizing the SAVI protocol to those limited devices which today cannot parse an IP datagram are certainly out-of-scope. =20 Even existing equipment vendors have a graduated set of features for their=20 LAN switching equipment, from the most basic commodity based systems to=20 the more sophisticated=20 =20 Additionally, as technology advances, the price point for the capability to put IP datagram recognition into consumer devices will be more attractive. =20 So I am not worried or interested in developing for the lowest common denominator here. I would only really be worried if we placed complex cryptographic requirements on the analysis mechanisms, as most LAN switches do not have this capability on the data plane. =20 Greg Daley Security Consultant NetStar Australia Pty Ltd E-mail: gdaley@netstarnetworks.com Mobile: +61 401 772 770 Direct: +61 3 8532 4042 Fax: +61 3 8532 4032=20 =20 ________________________________ From: Frank Xia [mailto:xiayangsong@huawei.com]=20 Sent: Friday, 26 June 2009 12:09 PM To: Greg Daley; SAVI Mailing List Subject: Re: [savi] feasibility of impmentation SAVI in a switch Hi Greg =20 Each switch has programable CPU could easily handle snooping MLD/DAD/DHCP etc, and each switch also has non-programable ASIC to forward packets. =20 I am talking about SAVI packets forwarding processing which=20 changes switches normal behavior which ususally inspects only layer 2. =20 BR Frank ----- Original Message -----=20 From: Greg Daley =20 To: Frank Xia ; SAVI Mailing List =20 Sent: Thursday, June 25, 2009 6:30 PM Subject: Re: [savi] feasibility of impmentation SAVI in a switch Hi Frank, =20 We are talking about the sort of switches which can already snoop MLD. =20 =20 Greg Daley Security Consultant NetStar Australia Pty Ltd =09 E-mail: gdaley@netstarnetworks.com Mobile: +61 401 772 770 Direct: +61 3 8532 4042 Fax: +61 3 8532 4032=20 =20 =09 ________________________________ From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Frank Xia Sent: Friday, 26 June 2009 1:38 AM To: SAVI Mailing List Subject: [savi] feasibility of impmentation SAVI in a switch =09 =09 =09 Hi Guys =20 This question has been obsessing me for a while. =20 Aside from high end switches (such as layer 3 switches), most switches use commercial chips which only inspect layer 2 information(mac, vlan,etc). At the same time, SAVI requires switches to parse layer 3 information of each packet. =20 =20 Apparantly, current switch chips can not handle this. =20 That means switch vendors should in turn require chip vendors to support this feature. =20 IMHO, the impact of chip design probably will impede the adoption of SAVI in switch. =20 BR Frank =20 =09 ________________________________ =09 _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi =09 ------_=_NextPart_001_01C9F605.33EB1B1C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Frank,
 
I think we can safely say that customizing the = SAVI protocol=20 to those limited devices
which today cannot parse an IP datagram are = certainly=20 out-of-scope.
 
Even  existing equipment vendors have a = graduated set of=20 features for their
LAN switching equipment, from the most basic = commodity based=20 systems to
the more sophisticated
 
Additionally, as technology advances, the price = point for the=20 capability to put IP
datagram recognition into consumer devices will be = more=20 attractive.
 
So I am not worried or interested in developing = for the lowest=20 common denominator here.
I would only really be worried if we placed = complex=20 cryptographic requirements on the
analysis mechanisms, as most LAN switches do not = have this=20 capability on the data plane.
 

Greg Daley
Security Consultant
NetStar Australia = Pty=20 Ltd

E-mail: gdaley@netstarnetworks.com
Mobile: +61 401 772=20 770
Direct: +61 3 8532 4042
Fax:    +61 3 8532 = 4032=20

 

From: Frank Xia = [mailto:xiayangsong@huawei.com]=20
Sent: Friday, 26 June 2009 12:09 PM
To: Greg Daley; = SAVI=20 Mailing List
Subject: Re: [savi] feasibility of impmentation = SAVI in a=20 switch

Hi Greg
 
Each switch has programable CPU = could easily=20 handle snooping
MLD/DAD/DHCP etc, and = each switch also has = non-programable
 ASIC to forward = packets.
 
I am talking about SAVI packets = forwarding=20 processing which
changes switches normal behavior = which ususally=20 inspects only
layer 2.
 
BR
Frank
----- Original Message -----
From:=20 Greg Daley
Sent: Thursday, June 25, 2009 = 6:30=20 PM
Subject: Re: [savi] feasibility = of=20 impmentation SAVI in a switch

Hi Frank,
 
We are talking about the sort of switches which = can already=20 snoop MLD.
 
 

Greg Daley
Security = Consultant
NetStar=20 Australia Pty Ltd

E-mail: gdaley@netstarnetworks.com=
Mobile:=20 +61 401 772 770
Direct: +61 3 8532 4042
Fax:    = +61 3=20 8532 4032

 

From: savi-bounces@ietf.org=20 [mailto:savi-bounces@ietf.org] On Behalf Of Frank = Xia
Sent:=20 Friday, 26 June 2009 1:38 AM
To: SAVI Mailing=20 List
Subject: [savi] feasibility of impmentation SAVI in a=20 switch

Hi Guys
 
This question has been obsessing = me for a=20 while.
 
Aside from high end switches (such as = layer 3=20 switches),
most switches use commercial chips = which only=20 inspect
layer 2 information(mac, = vlan,etc).  At the=20 same time,
SAVI requires switches to parse layer = 3=20 information of
each packet. 
 
Apparantly, current switch chips can = not handle=20 this. 
That means switch vendors should = in turn=20 require
chip vendors to support this=20 feature.
 
IMHO, the impact of chip design = probably will=20 impede
the adoption of SAVI in = switch.
 
BR
Frank
 

_______________________________________________
savi mailing = = list
savi@ietf.org
https://www.ietf.org/mailman/listinfo/savi
------_=_NextPart_001_01C9F605.33EB1B1C-- From gdaley@netstarnetworks.com Thu Jun 25 19:43:17 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85D533A69EF for ; Thu, 25 Jun 2009 19:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.482 X-Spam-Level: X-Spam-Status: No, score=-1.482 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArYqedhu6vMS for ; Thu, 25 Jun 2009 19:43:16 -0700 (PDT) Received: from mail.syd.netstarnetworks.com (mail.syd.netstarnetworks.com [203.8.7.220]) by core3.amsl.com (Postfix) with ESMTP id 9725F3A6969 for ; Thu, 25 Jun 2009 19:43:16 -0700 (PDT) Received: from sydmail.netstarnetworks.com ([10.18.193.13]) by mail.syd.netstarnetworks.com (8.12.8/8.12.8) with ESMTP id n5Q2hYRs008951; Fri, 26 Jun 2009 12:43:34 +1000 Received: from melmail.netstarnetworks.com ([10.20.193.13]) by sydmail.netstarnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Jun 2009 12:43:27 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Jun 2009 12:43:27 +1000 Message-ID: <6983BF97BFC24D4EA551F1407123291801100111@melmail.netstarnetworks.com> In-Reply-To: <009d01c9f603$7f130ee0$3e0c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [savi] A different trade off for SAVI Thread-Index: Acn2A4Z85d/A/DL7Rp6tfkHYxRQ+ogAA9QZQ References: <4A2C0DFB.3040803@it.uc3m.es> <00e301c9edcf$c7cc7bd0$3e0c7c0a@china.huawei.com> <4A36706D.9050501@it.uc3m.es> <001901c9edda$ff5bceb0$3e0c7c0a@china.huawei.com> <4ECD61DE-172E-486D-A9DC-948DB322D565@ericsson.com> <6983BF97BFC24D4EA551F14071232918010FFEE7@melmail.netstarnetworks.com> <011701c9f51d$b225fae0$3e0c7c0a@china.huawei.com> <6983BF97BFC24D4EA551F1407123291801100069@melmail.netstarnetworks.com> <005301c9f5ea$7fcaa870$3e0c7c0a@china.huawei.com> <6983BF97BFC24D4EA551F1407123291801100089@melmail.netstarnetworks.com> <009d01c9f603$7f130ee0$3e0c7c0a@china.huawei.com> From: "Greg Daley" To: "Frank Xia" , "Christian Vogt" X-OriginalArrivalTime: 26 Jun 2009 02:43:27.0970 (UTC) FILETIME=[E25CB420:01C9F607] Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 02:43:17 -0000 Hi Frank,=20 =20 That's an upper layer issue though (for example TCP will manage this loss as normal). =20 We are looking at Layer 3. In any case, if people do not want to use Optimistic DAD, it is off by default. Then they don't get the interface for packet transmission until the DAD completes. The applicability statement for Optimistic DAD covers this: _It is only a local (to that host) problem_ Greg ________________________________ From: Frank Xia [mailto:xiayangsong@huawei.com]=20 Sent: Friday, 26 June 2009 12:12 PM To: Greg Daley; Christian Vogt Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI Hi Greg =20 >From my perspective, legitimate packets loss IS an issue. =20 BR Frank From xiayangsong@huawei.com Fri Jun 26 08:37:01 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56CB93A68B9 for ; Fri, 26 Jun 2009 08:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[AWL=0.913, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCXTkh26ZU0R for ; Fri, 26 Jun 2009 08:36:54 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 655733A6922 for ; Fri, 26 Jun 2009 08:36:54 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLU001ASRDVOC@szxga03-in.huawei.com> for savi@ietf.org; Fri, 26 Jun 2009 23:37:07 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLU00BVTRDVCO@szxga03-in.huawei.com> for savi@ietf.org; Fri, 26 Jun 2009 23:37:07 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLU00AOPRDSWO@szxml04-in.huawei.com> for savi@ietf.org; Fri, 26 Jun 2009 23:37:07 +0800 (CST) Date: Fri, 26 Jun 2009 10:37:03 -0500 From: Frank Xia To: Greg Daley , SAVI Mailing List Message-id: <002a01c9f673$f5cca030$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_W2Jlhr3WW8EUE/A1kk74nA)" X-Priority: 3 X-MSMail-priority: Normal References: <000801c9f5aa$fe34fa20$3e0c7c0a@china.huawei.com> <6983BF97BFC24D4EA551F1407123291801100086@melmail.netstarnetworks.com> <008a01c9f603$18bb4270$3e0c7c0a@china.huawei.com> <6983BF97BFC24D4EA551F1407123291801100105@melmail.netstarnetworks.com> Subject: Re: [savi] feasibility of impmentation SAVI in a switch X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 15:37:01 -0000 This is a multi-part message in MIME format. --Boundary_(ID_W2Jlhr3WW8EUE/A1kk74nA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Greg Sure,you are not worried because I assume you are not going to sell switches with SAVI function :-). Switch is layer 2 device while SAVI needs do layer 3 work, and this introduces architectural issues. I am not the only one who has such concerns which are also shared by my hardware colleagues. Please also check my inline reply... BR Frank ----- Original Message ----- From: Greg Daley To: Frank Xia ; SAVI Mailing List Sent: Thursday, June 25, 2009 9:24 PM Subject: Re: [savi] feasibility of impmentation SAVI in a switch Hi Frank, I think we can safely say that customizing the SAVI protocol to those limited devices which today cannot parse an IP datagram are certainly out-of-scope. Frank=>IMHO, talking about potential engineering problem seems to be relevent to SAVI protocol design Even existing equipment vendors have a graduated set of features for their LAN switching equipment, from the most basic commodity based systems to the more sophisticated Frank=>So, we should assume some of switchs are naturally not able to implement SAVI. Additionally, as technology advances, the price point for the capability to put IP datagram recognition into consumer devices will be more attractive. Frank=>it is always a tradeoff between price and performance. So I am not worried or interested in developing for the lowest common denominator here. I would only really be worried if we placed complex cryptographic requirements on the analysis mechanisms, as most LAN switches do not have this capability on the data plane. Greg Daley Security Consultant NetStar Australia Pty Ltd E-mail: gdaley@netstarnetworks.com Mobile: +61 401 772 770 Direct: +61 3 8532 4042 Fax: +61 3 8532 4032 ------------------------------------------------------------------------------ From: Frank Xia [mailto:xiayangsong@huawei.com] Sent: Friday, 26 June 2009 12:09 PM To: Greg Daley; SAVI Mailing List Subject: Re: [savi] feasibility of impmentation SAVI in a switch Hi Greg Each switch has programable CPU could easily handle snooping MLD/DAD/DHCP etc, and each switch also has non-programable ASIC to forward packets. I am talking about SAVI packets forwarding processing which changes switches normal behavior which ususally inspects only layer 2. BR Frank ----- Original Message ----- From: Greg Daley To: Frank Xia ; SAVI Mailing List Sent: Thursday, June 25, 2009 6:30 PM Subject: Re: [savi] feasibility of impmentation SAVI in a switch Hi Frank, We are talking about the sort of switches which can already snoop MLD. Greg Daley Security Consultant NetStar Australia Pty Ltd E-mail: gdaley@netstarnetworks.com Mobile: +61 401 772 770 Direct: +61 3 8532 4042 Fax: +61 3 8532 4032 ---------------------------------------------------------------------------- From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Frank Xia Sent: Friday, 26 June 2009 1:38 AM To: SAVI Mailing List Subject: [savi] feasibility of impmentation SAVI in a switch Hi Guys This question has been obsessing me for a while. Aside from high end switches (such as layer 3 switches), most switches use commercial chips which only inspect layer 2 information(mac, vlan,etc). At the same time, SAVI requires switches to parse layer 3 information of each packet. Apparantly, current switch chips can not handle this. That means switch vendors should in turn require chip vendors to support this feature. IMHO, the impact of chip design probably will impede the adoption of SAVI in switch. BR Frank ---------------------------------------------------------------------------- _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi ------------------------------------------------------------------------------ _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi --Boundary_(ID_W2Jlhr3WW8EUE/A1kk74nA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Greg
 
Sure，you are not worried because I assume you
are not going to sell switches with SAVI function  :-).
 
Switch is layer 2 device while SAVI needs do layer 3
work,   and this introduces architectural issues.
 
I am not the only one who has such concerns which
are also shared by my hardware colleagues.
 
Please also check my inline reply...
 
BR
Frank
----- Original Message -----
From: Greg Daley
Sent: Thursday, June 25, 2009 9:24 PM
Subject: Re: [savi] feasibility of impmentation SAVI in a switch

Hi Frank,
 
I think we can safely say that customizing the SAVI protocol to those limited devices
which today cannot parse an IP datagram are certainly out-of-scope.
Frank=>IMHO, talking about potential engineering problem seems to be relevent
to SAVI protocol design
 
Even  existing equipment vendors have a graduated set of features for their
LAN switching equipment, from the most basic commodity based systems to
the more sophisticated
Frank=>So, we should assume some of switchs are naturally not able to
implement SAVI. 
 
Additionally, as technology advances, the price point for the capability to put IP
datagram recognition into consumer devices will be more attractive.
Frank=>it is always a tradeoff between price and performance.
 
So I am not worried or interested in developing for the lowest common denominator here.
I would only really be worried if we placed complex cryptographic requirements on the
analysis mechanisms, as most LAN switches do not have this capability on the data plane.
 
 

Greg Daley
Security Consultant
NetStar Australia Pty Ltd

E-mail: gdaley@netstarnetworks.com
Mobile: +61 401 772 770
Direct: +61 3 8532 4042
Fax:    +61 3 8532 4032

 

From: Frank Xia [mailto:xiayangsong@huawei.com]
Sent: Friday, 26 June 2009 12:09 PM
To: Greg Daley; SAVI Mailing List
Subject: Re: [savi] feasibility of impmentation SAVI in a switch

Hi Greg
 
Each switch has programable CPU could easily handle snooping
MLD/DAD/DHCP etc, and each switch also has non-programable
 ASIC to forward packets.
 
I am talking about SAVI packets forwarding processing which
changes switches normal behavior which ususally inspects only
layer 2.
 
BR
Frank
----- Original Message -----
From: Greg Daley
Sent: Thursday, June 25, 2009 6:30 PM
Subject: Re: [savi] feasibility of impmentation SAVI in a switch

Hi Frank,
 
We are talking about the sort of switches which can already snoop MLD.
 
 

Greg Daley
Security Consultant
NetStar Australia Pty Ltd

E-mail: gdaley@netstarnetworks.com
Mobile: +61 401 772 770
Direct: +61 3 8532 4042
Fax:    +61 3 8532 4032

 

From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Frank Xia
Sent: Friday, 26 June 2009 1:38 AM
To: SAVI Mailing List
Subject: [savi] feasibility of impmentation SAVI in a switch

Hi Guys
 
This question has been obsessing me for a while.
 
Aside from high end switches (such as layer 3 switches),
most switches use commercial chips which only inspect
layer 2 information(mac, vlan,etc).  At the same time,
SAVI requires switches to parse layer 3 information of
each packet. 
 
Apparantly, current switch chips can not handle this. 
That means switch vendors should in turn require
chip vendors to support this feature.
 
IMHO, the impact of chip design probably will impede
the adoption of SAVI in switch.
 
BR
Frank
 

_______________________________________________
savi mailing list
savi@ietf.org
https://www.ietf.org/mailman/listinfo/savi

_______________________________________________
savi mailing list
savi@ietf.org
https://www.ietf.org/mailman/listinfo/savi
--Boundary_(ID_W2Jlhr3WW8EUE/A1kk74nA)-- From zhangdong_rh@huaweisymantec.com Sat Jun 27 00:31:46 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8748A3A68B2 for ; Sat, 27 Jun 2009 00:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.733 X-Spam-Level: * X-Spam-Status: No, score=1.733 tagged_above=-999 required=5 tests=[AWL=-2.471, BAYES_50=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdETusnckCvc for ; Sat, 27 Jun 2009 00:31:45 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id B18803A6A7E for ; Sat, 27 Jun 2009 00:31:45 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KLV00H61ZLEMQ30@hstga01-in.huaweisymantec.com> for savi@ietf.org; Sat, 27 Jun 2009 15:32:03 +0800 (CST) Received: from z90001956 ([10.27.154.181]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KLV00EEAZLEHR10@hstml02-in.huaweisymantec.com> for savi@ietf.org; Sat, 27 Jun 2009 15:32:02 +0800 (CST) Date: Sat, 27 Jun 2009 15:32:03 +0800 From: Dong Zhang To: savi References: <20090627030530.9953328C1E7@core3.amsl.com> Message-id: <200906271532034761598@huaweisymantec.com> X-Mailer: Foxmail 6, 10, 201, 20 [cn] Content-transfer-encoding: base64 Cc: Padmanabha Nallur 73868 Subject: [savi] Fw: New Version Notification for draft-dong-savi-cga-header-02 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2009 07:31:46 -0000 SGkgYWxsLA0KDQpXZSBoYXZlIHVwZGF0ZWQgdGhlIGRyYWZ0LCBkcmFmdC1kb25nLXNhdmktY2dh LWhlYWRlci0wMi4gV2UgYWRkIGEgc2VjdGlvbiBjYWxsZWQgdXNlIGNhc2VzIGRlc2NyaXB0aW9u LiBUaGlzIHBhcnQgaWxsdXN0cmF0ZXMgc29tZSB1c2UgY2FzZXMsIHdoaWNoIG91ciBDR0EgcHJv cG9zYWwgY291bGQgcHJvdmlkZSBhIGdvb2Qgc29sdXRpb24gZm9yLiANCg0KTG9va2luZyBmb3J3 YXJkIHRvIHlvdXIgcmVhZGluZyBhbmQgY29tbWVudHMuDQpUaGFuayB5b3UuIA0KDQotLS0tLS0t LS0tLS0tLS0tLS0JCQkJIA0KRG9uZyBaaGFuZw0KMjAwOS0wNi0yNw0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQq3orz+yMuj uklFVEYgSS1EIFN1Ym1pc3Npb24gVG9vbA0Kt6LLzcjVxtqjujIwMDktMDYtMjcgMTE6MDU6NTEN CsrVvP7Iy6O6emhhbmdkb25nX3JoQGh1YXdlaXN5bWFudGVjLmNvbQ0Ks63LzaO6cG5hbGx1ckBo dWF3ZWkuY29tDQrW98zio7pOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRvbmct c2F2aS1jZ2EtaGVhZGVyLTAyDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWRvbmct c2F2aS1jZ2EtaGVhZGVyLTAyLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVseSBzdWJtaXR0ZWQgYnkg RG9uZyBaaGFuZyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1l OgkgZHJhZnQtZG9uZy1zYXZpLWNnYS1oZWFkZXINClJldmlzaW9uOgkgMDINClRpdGxlOgkJIENH QSBFeHRlbnNpb24gSGVhZGVyIG9mIElQdjYNCkNyZWF0aW9uX2RhdGU6CSAyMDA5LTA2LTI3DQpX RyBJRDoJCSBJbmRlcGVuZGVudCBTdWJtaXNzaW9uDQpOdW1iZXJfb2ZfcGFnZXM6IDE2DQoNCkFi c3RyYWN0Og0KVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBtZXRob2QgdG8gY2FycnkgQ3J5cHRv Z3JhcGhpY2FsbHkgR2VuZXJhdGVkDQpBZGRyZXNzZXMgKENHQSkgaW5mb3JtYXRpb24gaW4gYW4g SVB2NiBleHRlbnNpb24gaGVhZGVyIHRvIHByb3RlY3QNCnRoZSBJUHY2IG5ldHdvcmsgZnJvbSBh ZGRyZXNzIHNwb29maW5nLg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRG IFNlY3JldGFyaWF0Lg0KDQoNCg== From zhangdong_rh@huaweisymantec.com Sat Jun 27 01:00:20 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 182423A68A2 for ; Sat, 27 Jun 2009 01:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.823 X-Spam-Level: X-Spam-Status: No, score=0.823 tagged_above=-999 required=5 tests=[AWL=-1.209, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkhIZi6zB6Pc for ; Sat, 27 Jun 2009 01:00:19 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id DE3BF3A6899 for ; Sat, 27 Jun 2009 01:00:18 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/related; boundary="Boundary_(ID_Fjq+MzzjKLJRd2VFeevpmA)"; type="multipart/alternative" Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KLW008W30WRV310@hstga02-in.huaweisymantec.com> for savi@ietf.org; Sat, 27 Jun 2009 16:00:27 +0800 (CST) Received: from z90001956 ([10.27.154.181]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KLW00FHP0WQBO10@hstml02-in.huaweisymantec.com> for savi@ietf.org; Sat, 27 Jun 2009 16:00:27 +0800 (CST) Date: Sat, 27 Jun 2009 16:00:29 +0800 From: Dong Zhang To: "christian.vogt" , fenner Message-id: <200906271600291115795@huaweisymantec.com> X-Mailer: Foxmail 6, 10, 201, 20 [cn] Cc: Padmanabha Nallur 73868 , savi Subject: [savi] Ask for presentation in IETF 75 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2009 08:00:20 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Fjq+MzzjKLJRd2VFeevpmA) Content-type: multipart/alternative; boundary="Boundary_(ID_wTVrfVmjrc47oZAoNINGIA)" --Boundary_(ID_wTVrfVmjrc47oZAoNINGIA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Dear chairs, In ietf75 draft meeting agenda published, there will be a savi session, July 30. I am waiting for the chair's call for presentation in IETF75. We have added the use cases in draft-dong-savi-cga-header-02.txt. Here we want to request a time slot to present the use cases. Could I ask for a 15 minutes slot? Thanks a lot. 2009-06-27 Dong Zhang --Boundary_(ID_wTVrfVmjrc47oZAoNINGIA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Dear chairs,
 
In ietf75 draft meeting agenda published, there will be a savi session, July 30. I am waiting for the chair's call for presentation in IETF75.  
We have added the use cases in draft-dong-savi-cga-header-02.txt. Here we want to request a time slot to present the use cases.
Could I ask for a 15 minutes slot?
 
Thanks a lot.
 
2009-06-27
Dong Zhang
 
 --Boundary_(ID_wTVrfVmjrc47oZAoNINGIA)-- --Boundary_(ID_Fjq+MzzjKLJRd2VFeevpmA) Content-id: <__0@Foxmail.net> Content-type: image/gif; name=14.gif Content-transfer-encoding: base64 Content-disposition: attachment; filename=14.gif R0lGODlhFAAUAPfkAOrq6rCQZeq6KMi7qPfv1vDw8OWgCsCGIPnaX9jW1ZRKEJ1bGPfdiO/PTv77 TLqlgkIpCEIhCMyZM/PdQP7HQf3NFdeoKf75T+feQv/wUv/hRcatKf/oH8yzTf/tJf//5//GP//n IP/7PsaUGL2EEOfGGJlmM//bR9alEP7mUqVjEP/RQuLQpv/9SP/7Sf/xLP/VRP/65f/7Of79Qf/8 Rv/9Qr2tQqWUe5yESv/lM3tjGM6lGPzMFf3rUu/GMf/9TPzLG//PPszMzPz4P/++CK1rGP35Sf3j bfz5Q//cP//HJ/roMf79Rey/J//vLv/hSu/OKfz2RoRjGOfGId7OrfzzTP/tT/PVNvrvSf/kSf/f QYx7GP/qTP/MM//+Rf/zKs6lIfntRK1rEP/rMf/pKPvvNP/GQf/uJfXdN0opCMa1IWNCEK2UIfbk Rf/8PefeOd61Id6tIebMMLWcIfjfLf/jTv/ERP/eRf3rJf/IQ//xTf/0Uv+7Cf6/C//4MP7ACf/l O/nvPv/XO/73Nf7zUv3wLPzsLZxaEMzMmcyZZv/jIvf39/778//XRPjrO/30MuiwM/7xKvzzOP/j Tf+/B/z2PP/INP/NQNbOKf/yLP76T++zE//rUf/TRP/3Tf/2T//7R//0UP/GRP73MfzwTv/dScaM If/5Tc69KfPPMv/rJvfnOPnRJP/kKv/cRvfVLfnwQv/1M96tKf/VQ5R7MffvMa2ca4RrQrWlOf31 Mf37Rf/0Qf/0Sv33Nv/mSP/0NP/qRf/5Sv37Qv36Pv/3N//uSq2UQqWMOf/6RP/wSP76Pf/2Rf/4 P//xRv/xRLWlUv/1R86tQoxrKf75OdbGrf/zPv/oRpyMWqWMWs69QtbGpf//MbWcUv/3Mf//OaWM a72thL2tSv/vQP/7Q////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/C05FVFNDQVBFMi4wAwEA AAAh+QQFyADkACwAAAAAFAAUAAAI/wDJCRzIgMERBAiOMBjIkKHBDHtChcrAKcWThQ0FHiFE6sIF TRc+hbJSp1GDjAx+aNLkwMEPB6c86eHypFMHhz2wGDmGg1YLFy7CSTM2qdSKmwLrtImCwdYHbdlo YMD2AVw0VyskCGTQJgwSG1Q+EHhWA6xYbncuQTpGjoEmLENsXLtx45YIXN9uUMOhAQYIthsDVXqz JkIEHTIwpDEsRcMsOybIIcjgSNK2ORAgoBrkbUsECBu0PC7SlsuqMo+6qcHkZ1SsWmw2AEqyQlRk Bly4LDFU6EWkL5leOBmTw4cgtbQEouFCpwgYPB7OeFBFphUUBbJEmQogsIGGV1MU7GQIwYFDCEVw FJiyREEFQyha7rg6pGJEiREqFMRR0uXAN4Y++EDHLDygQIIYJKBQQQVKHBBZQ3HEAcQrffxBCRF8 VGDAAcllRI4EEhhgAB98QCLiAiR4yNAB2HBYBDbYqCjjjAEBACH5BAUKAOQALAIAAQARABAAAAiV AMkJzLBHEzk9VsjVWSGwYcNPn/Y4nOjwE8WGGk405CIQVIsWDYPxKpbFoUFdTJh48UKOBihoyXxV JCdshs0a5MYhW9bMmsM9SIYpE+HGDTkRzHY5AybQDjlCDafJcFhNnMBGechlINdrIjGKomglJJdr 4q+JTi+qpaC2rduJIN42tBRXbkMSarsECWLJkpJNRXA0DAgAIfkEBcgA5AAsAgACABEADwAACI0A yQkkdeGCwIMIEWpKiPAJwh4X9hzDQetgOGnGyDWygxCDrQ/aspHDgO0DuGiNuiC0QeUDgWfkWLrk JiihjWs3btwih+vbDWo4BIJIGCECwqICZ3EUuC2hN4Z2ihzslrBWQlECuTDcCkmgr61gyX0NS85H QlYlwCoBO4uhJYEVGfb5Q4kInwoGDpg4GBAAIfkEBQoA5AAsAQACABAAEAAACIMAyQkk9+lTKEJ6 rFjh4mugw4cONUAE1aLFwGC8ipErtULgnj1MmHjxQo4GKGjJfLnqKFDYjJc1yI1DtqyZtTsOhykT 4cYNORHMdjkDBpHcNBkOq4mD2OshMYgarZDL9fCXwzxFs2otamerQ0sO77jS2gUij6wHTEAMApEE La8DDwgMCAA7 --Boundary_(ID_Fjq+MzzjKLJRd2VFeevpmA)-- From gdaley@netstarnetworks.com Sun Jun 28 15:43:43 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EC013A6BB0 for ; Sun, 28 Jun 2009 15:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.193 X-Spam-Level: X-Spam-Status: No, score=-0.193 tagged_above=-999 required=5 tests=[AWL=-1.189, BAYES_50=0.001, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEReZRZUQ2gj for ; Sun, 28 Jun 2009 15:43:43 -0700 (PDT) Received: from mail.syd.netstarnetworks.com (mail.syd.netstarnetworks.com [203.8.7.220]) by core3.amsl.com (Postfix) with ESMTP id C412E3A6A05 for ; Sun, 28 Jun 2009 15:43:39 -0700 (PDT) Received: from sydmail.netstarnetworks.com ([10.18.193.13]) by mail.syd.netstarnetworks.com (8.12.8/8.12.8) with ESMTP id n5SMhWRs001859; Mon, 29 Jun 2009 08:43:44 +1000 Received: from melmail.netstarnetworks.com ([10.20.193.13]) by sydmail.netstarnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Jun 2009 08:43:28 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9F841.DA8505F8" Date: Mon, 29 Jun 2009 08:43:27 +1000 Message-ID: <6983BF97BFC24D4EA551F14071232918011001AE@melmail.netstarnetworks.com> In-Reply-To: <002a01c9f673$f5cca030$3e0c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [savi] feasibility of impmentation SAVI in a switch Thread-Index: Acn2c/t/2Gwtj/jWTq+Zh+sU70TykgBzbmcA References: <000801c9f5aa$fe34fa20$3e0c7c0a@china.huawei.com> <6983BF97BFC24D4EA551F1407123291801100086@melmail.netstarnetworks.com> <008a01c9f603$18bb4270$3e0c7c0a@china.huawei.com> <6983BF97BFC24D4EA551F1407123291801100105@melmail.netstarnetworks.com> <002a01c9f673$f5cca030$3e0c7c0a@china.huawei.com> From: "Greg Daley" To: "Frank Xia" , "SAVI Mailing List" X-OriginalArrivalTime: 28 Jun 2009 22:43:28.0351 (UTC) FILETIME=[DAC276F0:01C9F841] Subject: Re: [savi] feasibility of impmentation SAVI in a switch X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 22:43:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9F841.DA8505F8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Frank, =20 "Sure you are not worried because I assume you are not going to sell switches with SAVI function :-)." =20 This is insulting and incorrect. =20 I am finishing this thread. Greg ------_=_NextPart_001_01C9F841.DA8505F8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Frank,
 
"Sure = you=20 are not worried because I assume you
are not = going to sell=20 switches with SAVI function  :-)."
 
This=20 is insulting and incorrect.
 
I am=20 finishing this thread.

Greg

------_=_NextPart_001_01C9F841.DA8505F8-- From christian.vogt@ericsson.com Mon Jun 29 16:11:49 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7822E3A6C35 for ; Mon, 29 Jun 2009 16:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-OYKuR958at for ; Mon, 29 Jun 2009 16:11:48 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 7B1523A6AAE for ; Mon, 29 Jun 2009 16:11:48 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n5TNC89S014616; Mon, 29 Jun 2009 18:12:08 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jun 2009 18:12:08 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jun 2009 18:12:07 -0500 Message-Id: From: Christian Vogt To: SAVI Mailing List In-Reply-To: <81955095-4CA3-41E8-8435-99B2AF644621@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 29 Jun 2009 16:12:07 -0700 References: <81955095-4CA3-41E8-8435-99B2AF644621@ericsson.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 29 Jun 2009 23:12:07.0587 (UTC) FILETIME=[05EACF30:01C9F90F] Subject: [savi] More Opinions, Please - On the Protection of Unused Addresses X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 23:11:49 -0000 Folks - I would like to solicit more feedback on the benefit-cost analysis (below) for protecting unused addresses. How valuable do people consider protection of unused addresses, how much cost do they think is OK? Is there something that the analysis overlooks? We already got several very useful comments from a few people. What do the others think? To recap: We need to decide between the following three options of dealing with unused addresses: - Not protect unused addresses, i.e., forward packets without a binding. Logging is still possible, though. - Protect unused addresses, and coordinate SAVI devices on the same link by manually disabling SAVI protection on ports connecting to other SAVI devices. - Protect unused addresses, and coordinate SAVI devices on the same link with a dedicated binding synchronization protocol. Please send your feedback by Sunday, July 5. We will vote after that. - Christian On Jun 24, 2009, Christian Vogt wrote: > On Jun 23, 2009, Fred Baker wrote on thread "Your opinion on a > different > tradeoff for SAVI": > >> SAVI without protecting unused addresses is pointless. > > > Fred and all - > > Protection of unused addresses would, of course, be a useful feature. > But before making this mandatory, we should do a benefit-cost > analysis. > Here is one, along with a proposal of how to move forward: > > The benefit of protecting unused addresses is that it prevents an > attacker from hiding its identity or location. An attacker who > wants to > do this can use any source address as long as it is not its own > address. > Protecting unused addresses is especially useful in networks where > DHCP > is the only permitted method for address configuration, since those > networks are in control of which addresses are used. On the other > hand, > in networks where Stateless Address Autoconfiguration is permitted, it > is up to the (potentially malicious) hosts which addresses are used. > Protecting unused addresses then has little benefit: All it > achieves is > requiring an attacker to formally turn an unused address into a used > address by sending a DAD solicitation. > > The cost of protecting unused addresses is a need to coordinate > multiple > SAVI devices on the same link. If this coordination does not exist, > or > is insufficient, legitimate packets may get dropped, because one SAVI > device may consider unused an address that is in fact in use at > another > SAVI device. Coordination between SAVI devices, in turn, can be > accomplished in one of two ways: > > - By partitioning the scope of SAVI protection into one area per SAVI > device. This requires manual configuration of SAVI devices, since > switch ports that connect to other SAVI devices must be labeled as > such. Link partitioning is the approach of the CPS solution. > > - By synchronizing binding state across SAVI devices so that each SAVI > device can validate addresses from anywhere else on the link. This > requires an extra binding distribution protocol, plus extra memory > for binding state copied from other SAVI devices. Synchronization > was proposed as an add-on to the original FCFS solution. > > Either form of coordination implies an undesired cost for protecting > unused addresses. Given this cost, and given that the main benefit is > in networks where DHCP is the only permitted address configuration > method, a potential way to move forward may be to make the protection > of unused addresses optional and limited to those DHCP-only networks. > More specifically, we could add an optional "DHCP-only mode" to SAVI, > in which SAVI devices would permit only those addresses that have been > explicitly assigned via DHCP. In DHCP-only mode, SAVI devices would: > > - Create bindings only based on DHCP address assignments, but not > based > on DAD solicitations. > > - Drop packets with unused source addresses. > > As a method for inter-SAVI-device coordination, I suggest partitioning > the scope of SAVI protection. Thus, network administrators who enable > DHCP-only mode may also have to manually designate switch ports that > connect to other SAVI devices. This extra manual configuration should > be acceptable given that the DHCP-only mode already needs to be turned > on manually. At the same time, link partitioning avoids the extra > complexity and manufacturing cost that synchronization would entail. > > What do folks think? Would this be a reasonable approach? > > - Christian From christian.vogt@ericsson.com Mon Jun 29 16:19:24 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A1193A6B3E for ; Mon, 29 Jun 2009 16:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMMCQG-iCkPF for ; Mon, 29 Jun 2009 16:19:24 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id E47F53A6879 for ; Mon, 29 Jun 2009 16:19:23 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n5TNJdSC017785; Mon, 29 Jun 2009 18:19:39 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jun 2009 18:19:38 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jun 2009 18:19:38 -0500 Message-Id: <61BAD70D-933F-4D91-B849-E9B9DA655D08@ericsson.com> From: Christian Vogt To: Fred Baker In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 29 Jun 2009 16:19:38 -0700 References: <81955095-4CA3-41E8-8435-99B2AF644621@ericsson.com> <9E06E8D3-EED1-42FC-8D78-90626E341CD8@cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 29 Jun 2009 23:19:38.0656 (UTC) FILETIME=[12C67A00:01C9F910] Cc: SAVI Mailing List Subject: Re: [savi] On the Protection of Unused Addresses X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 23:19:24 -0000 On Jun 25, 2009, Fred Baker wrote: >> What do you think of the proposal to limit the protection of unused >> addresses to networks that use only DHCP for address assignment? > > Given that there is no product on the market today that uses DHCP for > address assignment... > > it seems vacuous. At this point, there are no products that support SAVI in IPv6 either. And yet we are hoping for those to be developed. Why wouldn't the same apply to DHCPv6 products if those proved to enable higher security in conjunction with SAVI? - Christian From christian.vogt@ericsson.com Mon Jun 29 16:29:23 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 581253A6C44 for ; Mon, 29 Jun 2009 16:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyArP-4ODPNB for ; Mon, 29 Jun 2009 16:29:22 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 8B0CC3A6B64 for ; Mon, 29 Jun 2009 16:29:22 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n5TNTeEi005914; Mon, 29 Jun 2009 18:29:40 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jun 2009 18:29:39 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jun 2009 18:29:39 -0500 From: Christian Vogt To: Frank Xia In-Reply-To: <008a01c9f603$18bb4270$3e0c7c0a@china.huawei.com> X-Priority: 3 References: <000801c9f5aa$fe34fa20$3e0c7c0a@china.huawei.com> <6983BF97BFC24D4EA551F1407123291801100086@melmail.netstarnetworks.com> <008a01c9f603$18bb4270$3e0c7c0a@china.huawei.com> Message-Id: <1904C99D-C5F1-4356-AC1D-1A4E8F6DEB22@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 29 Jun 2009 16:29:39 -0700 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 29 Jun 2009 23:29:39.0254 (UTC) FILETIME=[78C27560:01C9F911] Cc: SAVI Mailing List , Greg Daley Subject: Re: [savi] feasibility of impmentation SAVI in a switch X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 23:29:23 -0000 Frank - I don't think SAVI imposes significant new requirements on the forwarding plane of layer-2 switches. The only new requirement for the forwarding plane is to look at an extra field, the Source Address field in the IP header, and verify this in a binding table. This doesn't seem to involve significantly more sophistication than what layer-2 switches do already today. The processing of DAD and DHCP packets, in turn, is something that can be done on the control plane, just as MLD-aware switches do it today. - Christian On Jun 25, 2009, Frank Xia wrote: > Hi Greg > > Each switch has programable CPU could easily handle snooping > MLD/DAD/DHCP etc, and each switch also has non-programable > ASIC to forward packets. > > I am talking about SAVI packets forwarding processing which > changes switches normal behavior which ususally inspects only > layer 2. > > BR > Frank From jmh@joelhalpern.com Mon Jun 29 16:36:32 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3784E3A6C04 for ; Mon, 29 Jun 2009 16:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blfc3VDnSuzV for ; Mon, 29 Jun 2009 16:36:31 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 73A7C3A6A48 for ; Mon, 29 Jun 2009 16:36:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4133C430516 for ; Mon, 29 Jun 2009 16:36:47 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id AEB31430515 for ; Mon, 29 Jun 2009 16:36:46 -0700 (PDT) Message-ID: <4A49500B.6000702@joelhalpern.com> Date: Mon, 29 Jun 2009 19:36:43 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: SAVI Mailing List References: <81955095-4CA3-41E8-8435-99B2AF644621@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [savi] More Opinions, Please - On the Protection of Unused Addresses X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 23:36:32 -0000 While I appreciate Christian's question, I think that this is part of a larger pair of questions that we talk around, but do not address. 1) What threats are we actually trying to protect against. The threats draft talks about general internet threats and the need to be able to track them back. But it is not particularly clear about what behavioral threats we are actually concerned with stopping in SAVI - Are we concerned with ensure that every packet leaving a site can be reliably tracked back to a human being - Are we concerned with preventing one device within a site from masquerading as another device, either at the IP or MAC layer. 2) What tools do we want to require or prohibit. While we probably do not want to mandate a single tool set, without mandating something we get nowhere. Possibilities include - restricting mobility (with or without session continuity) - Requiring MAC or IP authentication (*02.1X, SEND, ...) - Requiring central management of addressing and bindings No, those are not all the alternatives. As far as I can tell from watching this list, there are folks who take as given the need for almost any subset of these and related constraints you can imagine. Unless we pick, explicitly, we will continue to argue in circles. For example, the question of controlling unregistered addresses turns on assumptions about what threats we are addressing, and assumptions about address allocation that mean that "unregistered" is a meaningful condition. I don't object to that particular pair, but it is really hard to discuss the acceptability of answers without agreeing on the questions. Yours, Joel M. Halpern Christian Vogt wrote: > Folks - > > I would like to solicit more feedback on the benefit-cost analysis > (below) for protecting unused addresses. How valuable do people consider > protection of unused addresses, how much cost do they think is OK? Is > there something that the analysis overlooks? We already got several > very useful comments from a few people. What do the others think? > > To recap: We need to decide between the following three options of > dealing with unused addresses: > > - Not protect unused addresses, i.e., forward packets without a binding. > Logging is still possible, though. > > - Protect unused addresses, and coordinate SAVI devices on the same link > by manually disabling SAVI protection on ports connecting to other > SAVI devices. > > - Protect unused addresses, and coordinate SAVI devices on the same link > with a dedicated binding synchronization protocol. > > Please send your feedback by Sunday, July 5. We will vote after that. > > - Christian From jmh@joelhalpern.com Mon Jun 29 16:39:32 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD7063A6A48 for ; Mon, 29 Jun 2009 16:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.514 X-Spam-Level: X-Spam-Status: No, score=-3.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbYTyYdU1xU7 for ; Mon, 29 Jun 2009 16:39:31 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id EBD6A3A683D for ; Mon, 29 Jun 2009 16:39:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0A6CF430515 for ; Mon, 29 Jun 2009 16:39:53 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 82ED9430504 for ; Mon, 29 Jun 2009 16:39:52 -0700 (PDT) Message-ID: <4A4950C5.2080206@joelhalpern.com> Date: Mon, 29 Jun 2009 19:39:49 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: SAVI Mailing List References: <000801c9f5aa$fe34fa20$3e0c7c0a@china.huawei.com> <6983BF97BFC24D4EA551F1407123291801100086@melmail.netstarnetworks.com> <008a01c9f603$18bb4270$3e0c7c0a@china.huawei.com> <1904C99D-C5F1-4356-AC1D-1A4E8F6DEB22@ericsson.com> In-Reply-To: <1904C99D-C5F1-4356-AC1D-1A4E8F6DEB22@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [savi] feasibility of impmentation SAVI in a switch X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 23:39:32 -0000 There are two sides to this. On the one hand, the charter explicitly states that we are concerned with L3 aware switches. Obviosuly, any L3 aware switch can look at IP addresses in packets. On the other hand, in fairness to Frank, if we take as given taht we must support environments in which very low end edge switches are used, it is not reasonable to expect those devices to be able to perform content inspection. They do not support policy. They do not support high level ACLs. They might be able to redirect some packets to a control infrastructure, but then again, they may not. As far as I can tell, our charter says "too bad." But we seem perfectly willing to overlook the charter in other regards, so we should not pretend that all edge switches are L3 aware. (Many are. Some aren't.) Yours, Joel Christian Vogt wrote: > Frank - > > I don't think SAVI imposes significant new requirements on the > forwarding plane of layer-2 switches. > > The only new requirement for the forwarding plane is to look at an extra > field, the Source Address field in the IP header, and verify this in a > binding table. This doesn't seem to involve significantly more > sophistication than what layer-2 switches do already today. > > The processing of DAD and DHCP packets, in turn, is something that can > be done on the control plane, just as MLD-aware switches do it today. > > - Christian > > > > On Jun 25, 2009, Frank Xia wrote: > >> Hi Greg >> >> Each switch has programable CPU could easily handle snooping >> MLD/DAD/DHCP etc, and each switch also has non-programable >> ASIC to forward packets. >> >> I am talking about SAVI packets forwarding processing which >> changes switches normal behavior which ususally inspects only >> layer 2. >> >> BR >> Frank > > > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From christian.vogt@ericsson.com Mon Jun 29 16:54:44 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC4A03A6BFB for ; Mon, 29 Jun 2009 16:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSHbWL+w5r6W for ; Mon, 29 Jun 2009 16:54:44 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 075BB3A683D for ; Mon, 29 Jun 2009 16:54:43 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n5TNt3Fl000782; Mon, 29 Jun 2009 18:55:03 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jun 2009 18:55:02 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jun 2009 18:55:02 -0500 Message-Id: <75D6B967-CF62-4D44-9856-C7052D14BE10@ericsson.com> From: Christian Vogt To: Greg Daley , Eric Levy-Abegnoli In-Reply-To: <6983BF97BFC24D4EA551F14071232918011000EC@melmail.netstarnetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 29 Jun 2009 16:55:02 -0700 References: <4A2C0DFB.3040803@it.uc3m.es> <4A2D2221.4030503@cisco.com><4A2D2739.1000206@it.uc3m.es> <4A2F9E29.5070704@cisco.com><4A30D6CD.8060209@it.uc3m.es><49417952-8570-467E-B312-B759DC3D88DD@ericsson.com><4A35ECEE.7060801@cisco.com><86861CC6-385A-4CBA-9B9C-5D7E56EF119B@ericsson.com><4A42591A.5060408@cisco.com> <20DEB994-56B6-4D86-98BD-6C5F9CA56A5D@ericsson.com> <6983BF97BFC24D4EA551F14071232918011000EC@melmail.netstarnetworks.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 29 Jun 2009 23:55:02.0397 (UTC) FILETIME=[049FA2D0:01C9F915] Cc: SAVI Mailing List Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 23:54:45 -0000 Greg and Eric - Thanks for explaining, Greg. What you are saying was exactly my understanding of Eric's first message in this thread. But I had thought that, in his latest message, he was getting at something different. In any case: Eric, can you clarify what is the benefit of your proposal over the current FCFS solution, which creates packets based on all packets, including data, DAD, and other ND packets? - Christian On Jun 25, 2009, Greg Daley wrote: > Hi Christian, > > I think that Eric points out that monitoring ports for any ND > (in the same fashion that one could monitor ARP today) will identify > that the addresses are in use, independent of whether the DAD message > has > been sent. > > This would allow the SAVI device to make bindings on unused addresses > once it sees > that the address is functionally in use, even if it doesn't see the > DAD > NS. > > > Greg Daley > Security Consultant > NetStar Australia Pty Ltd From christian.vogt@ericsson.com Mon Jun 29 19:42:28 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD5F23A6C6C for ; Mon, 29 Jun 2009 19:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BInVw199j+iQ for ; Mon, 29 Jun 2009 19:42:27 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id C7D133A6C6B for ; Mon, 29 Jun 2009 19:42:27 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n5U2ghxd002381; Mon, 29 Jun 2009 21:42:48 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jun 2009 21:42:43 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jun 2009 21:42:42 -0500 Message-Id: <3514B34A-B63C-42F4-9D0B-DB6B488B33A3@ericsson.com> From: Christian Vogt To: "Joel M. Halpern" In-Reply-To: <4A49500B.6000702@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 29 Jun 2009 19:42:42 -0700 References: <81955095-4CA3-41E8-8435-99B2AF644621@ericsson.com> <4A49500B.6000702@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 30 Jun 2009 02:42:42.0833 (UTC) FILETIME=[711C5810:01C9F92C] Cc: SAVI Mailing List Subject: Re: [savi] More Opinions, Please - On the Protection of Unused Addresses X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 02:42:28 -0000 Joel - I agree with you that the Threats document needs a revision. But the question at hand at this stage is actually very clear: Do we want to protect unused addresses despite the complexity this requires? And part of the answer to this question will be exactly what you call us to agree upon: Which attacks SAVI should protect against, and which tools SAVI should require. The attacks SAVI would prevent if SAVI were to protect unused addresses are those where the attacker wants to hide its identity or location. Without protecting unused addresses, SAVI would only prevent impersonation attacks. The tools SAVI could use to protect unused addresses are manual configuration or a separate binding distribution protocol. We should extend this list if there are more tools. I understand that your arguments relate to SAVI in general, not to the particular question we are discussing now. But I suggest to discuss one question after the other, and to tackle now the important question at hand. One may argue that we should have discussed this question long before, but only now do we fully understand the consequences that the possible answers have. - Christian On Jun 29, 2009, Joel M. Halpern wrote: > While I appreciate Christian's question, I think that this is part > of a > larger pair of questions that we talk around, but do not address. > > 1) What threats are we actually trying to protect against. The > threats > draft talks about general internet threats and the need to be able > to track them back. But it is not particularly clear about what > behavioral threats we are actually concerned with stopping in SAVI > > - Are we concerned with ensure that every packet leaving a site can be > reliably tracked back to a human being > > - Are we concerned with preventing one device within a site from > masquerading as another device, either at the IP or MAC layer. > > 2) What tools do we want to require or prohibit. While we probably do > not want to mandate a single tool set, without mandating something > we get nowhere. Possibilities include > > - restricting mobility (with or without session continuity) > > - Requiring MAC or IP authentication (*02.1X, SEND, ...) > > - Requiring central management of addressing and bindings > > No, those are not all the alternatives. As far as I can tell from > watching this list, there are folks who take as given the need for > almost any subset of these and related constraints you can imagine. > Unless we pick, explicitly, we will continue to argue in circles. > > For example, the question of controlling unregistered addresses > turns on > assumptions about what threats we are addressing, and assumptions > about > address allocation that mean that "unregistered" is a meaningful > condition. I don't object to that particular pair, but it is really > hard to discuss the acceptability of answers without agreeing on the > questions. > > Yours, > Joel M. Halpern From christian.vogt@ericsson.com Mon Jun 29 19:45:36 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 642EF3A6C80 for ; Mon, 29 Jun 2009 19:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a10oaM3MtcH9 for ; Mon, 29 Jun 2009 19:45:35 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 940E03A6C70 for ; Mon, 29 Jun 2009 19:45:35 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n5U2juEL005710; Mon, 29 Jun 2009 21:45:56 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jun 2009 21:45:56 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jun 2009 21:45:55 -0500 Message-Id: From: Christian Vogt To: "Joel M. Halpern" In-Reply-To: <4A49500B.6000702@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 29 Jun 2009 19:45:55 -0700 References: <81955095-4CA3-41E8-8435-99B2AF644621@ericsson.com> <4A49500B.6000702@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 30 Jun 2009 02:45:55.0861 (UTC) FILETIME=[E42A1450:01C9F92C] Cc: SAVI Mailing List Subject: Re: [savi] More Opinions, Please - On the Protection of Unused Addresses X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 02:45:36 -0000 Joel - One more thing, regarding your comment on the threats we are tackling: > 1) What threats are we actually trying to protect against. The > threats > draft talks about general internet threats and the need to be able to > track them back. But it is not particularly clear about what > behavioral > threats we are actually concerned with stopping in SAVI > > - Are we concerned with ensure that every packet leaving a site can be > reliably tracked back to a human being > > - Are we concerned with preventing one device within a site from > masquerading as another device, either at the IP or MAC layer. It is the latter. Tracing humans was explictly deemed out of scope during the working group chartering discussion. - Christian From christian.vogt@ericsson.com Mon Jun 29 19:50:32 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C51453A6C29 for ; Mon, 29 Jun 2009 19:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4VcbyYde4eT for ; Mon, 29 Jun 2009 19:50:31 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id BC4C63A6873 for ; Mon, 29 Jun 2009 19:50:31 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n5U2ooCc004864; Mon, 29 Jun 2009 21:50:50 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jun 2009 21:50:50 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jun 2009 21:50:49 -0500 Message-Id: <95D66AAA-E43C-4D1B-9BFB-B2D4D0B6A518@ericsson.com> From: Christian Vogt To: Joel Halpern , Frank Xia In-Reply-To: <4A4950C5.2080206@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 29 Jun 2009 19:50:49 -0700 References: <000801c9f5aa$fe34fa20$3e0c7c0a@china.huawei.com> <6983BF97BFC24D4EA551F1407123291801100086@melmail.netstarnetworks.com> <008a01c9f603$18bb4270$3e0c7c0a@china.huawei.com> <1904C99D-C5F1-4356-AC1D-1A4E8F6DEB22@ericsson.com> <4A4950C5.2080206@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 30 Jun 2009 02:50:49.0683 (UTC) FILETIME=[934BC230:01C9F92D] Cc: SAVI Mailing List Subject: Re: [savi] feasibility of impmentation SAVI in a switch X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 02:50:32 -0000 Joel - This is a very good summary. The point I was making is that the requirements we impose on SAVI devices are actually not that high and, therefore, meeting these requirements should be feasible without significantly increasing the cost of a switch. Does this make sense? - Christian On Jun 29, 2009, Joel M. Halpern wrote: > There are two sides to this. On the one hand, the charter explicitly > states that we are concerned with L3 aware switches. Obviosuly, any > L3 > aware switch can look at IP addresses in packets. > > On the other hand, in fairness to Frank, if we take as given taht we > must support environments in which very low end edge switches are > used, > it is not reasonable to expect those devices to be able to perform > content inspection. They do not support policy. They do not support > high level ACLs. They might be able to redirect some packets to a > control infrastructure, but then again, they may not. As far as I can > tell, our charter says "too bad." But we seem perfectly willing to > overlook the charter in other regards, so we should not pretend that > all > edge switches are L3 aware. (Many are. Some aren't.) > > Yours, Joel From jmh@joelhalpern.com Mon Jun 29 20:10:40 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 585EA3A6979 for ; Mon, 29 Jun 2009 20:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.517 X-Spam-Level: X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPLuc0-2tBrk for ; Mon, 29 Jun 2009 20:10:39 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 96B273A6C26 for ; Mon, 29 Jun 2009 20:10:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9282943052E for ; Mon, 29 Jun 2009 20:11:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 0DA6843052A for ; Mon, 29 Jun 2009 20:10:59 -0700 (PDT) Message-ID: <4A498240.10404@joelhalpern.com> Date: Mon, 29 Jun 2009 23:10:56 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: SAVI Mailing List References: <000801c9f5aa$fe34fa20$3e0c7c0a@china.huawei.com> <6983BF97BFC24D4EA551F1407123291801100086@melmail.netstarnetworks.com> <008a01c9f603$18bb4270$3e0c7c0a@china.huawei.com> <1904C99D-C5F1-4356-AC1D-1A4E8F6DEB22@ericsson.com> <4A4950C5.2080206@joelhalpern.com> <95D66AAA-E43C-4D1B-9BFB-B2D4D0B6A518@ericsson.com> In-Reply-To: <95D66AAA-E43C-4D1B-9BFB-B2D4D0B6A518@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [savi] feasibility of impmentation SAVI in a switch X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 03:10:40 -0000 I tend to think that if we can get clarity on the problem, we can find a set of solutions with a moderate set of requirements on the devices and the system as a whole. There may be some choices which even allow us to move some of the costs around. (If the network uses 802.1x, then the routers may be able to be leveraged because the MACs are meaningful. Alternatively, if the leaf devices can do a little more, it may allow more flexible topologies ...) My point was that we should not pretend that the cost will be zero, or that every device out there now will be inherently upgradable. We will ahve to make some choices, which have implications. Yours, Joel M. Halpern Christian Vogt wrote: > Joel - > > This is a very good summary. > > The point I was making is that the requirements we impose on SAVI > devices are actually not that high and, therefore, meeting these > requirements should be feasible without significantly increasing the > cost of a switch. Does this make sense? > > - Christian > > > > On Jun 29, 2009, Joel M. Halpern wrote: > >> There are two sides to this. On the one hand, the charter explicitly >> states that we are concerned with L3 aware switches. Obviosuly, any L3 >> aware switch can look at IP addresses in packets. >> >> On the other hand, in fairness to Frank, if we take as given taht we >> must support environments in which very low end edge switches are used, >> it is not reasonable to expect those devices to be able to perform >> content inspection. They do not support policy. They do not support >> high level ACLs. They might be able to redirect some packets to a >> control infrastructure, but then again, they may not. As far as I can >> tell, our charter says "too bad." But we seem perfectly willing to >> overlook the charter in other regards, so we should not pretend that all >> edge switches are L3 aware. (Many are. Some aren't.) >> >> Yours, Joel > > > > From xiayangsong@huawei.com Mon Jun 29 20:14:41 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96BBE3A6C85 for ; Mon, 29 Jun 2009 20:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.766 X-Spam-Level: X-Spam-Status: No, score=-0.766 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzZLZJT+jkCz for ; Mon, 29 Jun 2009 20:14:40 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id C22B13A6885 for ; Mon, 29 Jun 2009 20:14:40 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM100HA97OQVS@szxga02-in.huawei.com> for savi@ietf.org; Tue, 30 Jun 2009 11:14:51 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM1004I17OQ8I@szxga02-in.huawei.com> for savi@ietf.org; Tue, 30 Jun 2009 11:14:50 +0800 (CST) Received: from X24512z ([10.51.0.82]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KM1000L67ON32@szxml04-in.huawei.com> for savi@ietf.org; Tue, 30 Jun 2009 11:14:50 +0800 (CST) Date: Mon, 29 Jun 2009 22:14:46 -0500 From: Frank Xia To: Christian Vogt Message-id: <006701c9f930$edfcbd80$4201a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <000801c9f5aa$fe34fa20$3e0c7c0a@china.huawei.com> <6983BF97BFC24D4EA551F1407123291801100086@melmail.netstarnetworks.com> <008a01c9f603$18bb4270$3e0c7c0a@china.huawei.com> <1904C99D-C5F1-4356-AC1D-1A4E8F6DEB22@ericsson.com> Cc: SAVI Mailing List , Greg Daley Subject: Re: [savi] feasibility of impmentation SAVI in a switch X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 03:14:41 -0000 Hi Christian Please see my inline... BR Frank ----- Original Message ----- From: "Christian Vogt" To: "Frank Xia" Cc: "Greg Daley" ; "SAVI Mailing List" Sent: Monday, June 29, 2009 6:29 PM Subject: Re: [savi] feasibility of impmentation SAVI in a switch > Frank - > > I don't think SAVI imposes significant new requirements on the > forwarding plane of layer-2 switches. > > The only new requirement for the forwarding plane is to look at an extra > field, the Source Address field in the IP header, and verify this in a > binding table. This doesn't seem to involve significantly more > sophistication than what layer-2 switches do already today. Frank=>This processing needs extra hardware which seems to be more difficult than software update. Even though we can expect more sophisticated switches, I still think some switches are incapable of implementing SAVI. We should consider this constraint. > > The processing of DAD and DHCP packets, in turn, is something that can > be done on the control plane, just as MLD-aware switches do it today. Frank=> I am fine with control plane processing. > > - Christian > > > > On Jun 25, 2009, Frank Xia wrote: > >> Hi Greg >> >> Each switch has programable CPU could easily handle snooping >> MLD/DAD/DHCP etc, and each switch also has non-programable >> ASIC to forward packets. >> >> I am talking about SAVI packets forwarding processing which >> changes switches normal behavior which ususally inspects only >> layer 2. >> >> BR >> Frank > > > > From elevyabe@cisco.com Tue Jun 30 07:19:58 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4036B3A6B07 for ; Tue, 30 Jun 2009 07:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.27 X-Spam-Level: X-Spam-Status: No, score=-10.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKYm6zjwl9w0 for ; Tue, 30 Jun 2009 07:19:57 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E954A3A6AC1 for ; Tue, 30 Jun 2009 07:19:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,316,1243814400"; d="scan'208";a="44010137" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 30 Jun 2009 14:18:59 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5UEIxNG005613; Tue, 30 Jun 2009 16:18:59 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5UEIx64027781; Tue, 30 Jun 2009 14:18:59 GMT Received: from xmb-ams-335.cisco.com ([144.254.231.80]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jun 2009 16:18:59 +0200 Received: from [144.254.53.107] ([144.254.53.107]) by xmb-ams-335.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jun 2009 16:18:58 +0200 Message-ID: <4A4A1ECB.50109@cisco.com> Date: Tue, 30 Jun 2009 16:18:51 +0200 From: Eric Levy-Abegnoli User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Christian Vogt References: <4A2C0DFB.3040803@it.uc3m.es> <4A2D2221.4030503@cisco.com><4A2D2739.1000206@it.uc3m.es> <4A2F9E29.5070704@cisco.com><4A30D6CD.8060209@it.uc3m.es><49417952-8570-467E-B312-B759DC3D88DD@ericsson.com><4A35ECEE.7060801@cisco.com><86861CC6-385A-4CBA-9B9C-5D7E56EF119B@ericsson.com><4A42591A.5060408@cisco.com> <20DEB994-56B6-4D86-98BD-6C5F9CA56A5D@ericsson.com> <6983BF97BFC24D4EA551F14071232918011000EC@melmail.netstarnetworks.com> <75D6B967-CF62-4D44-9856-C7052D14BE10@ericsson.com> In-Reply-To: <75D6B967-CF62-4D44-9856-C7052D14BE10@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 30 Jun 2009 14:18:58.0947 (UTC) FILETIME=[B59D7530:01C9F98D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2045; t=1246371539; x=1247235539; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=elevyabe@cisco.com; z=From:=20Eric=20Levy-Abegnoli=20 |Subject:=20Re=3A=20[savi]=20A=20different=20trade=20off=20 for=20SAVI |Sender:=20; bh=yqXA7DGWdaY0pSgrnmL1aE7GiZ4FgN+HH5rbvGYuHMo=; b=oTAoBuRt3gYSBGzplgjnRoVTLxd3xtQhsz1PtMt1WjweFp9vt8NjAVt8o6 gtlgt7ADS67VrS9ANLf9E3IX9kEFF4bUpabO2/avkD4pDD3wnqXcEeR0TXl5 oUrsbzgpD2; Authentication-Results: ams-dkim-1; header.From=elevyabe@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: SAVI Mailing List , Greg Daley Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 14:19:58 -0000 Christian, there are several alleys where I am proposing something "different", hence the confusion that I may have created in the thread. Apologies to the wg for that. "Unfortunately", these differences are tight up together to some extend, and it's hard for me to extract one piece and describe the benefit as if it was standalone (hopefully, if I get a chance to present the proposal at ietf75, maybe it become clearer). To this sepcific point, the reasons why I was proposing to look at other ND packets are of two folds: - use them to maintain most accurate/up-to-date "state" of the binding entries, to make more accurate decisions (in case DAD was not seen, for movement, to poll entry owners, etc.) - to exploit the content of the binding information provided in these ND packets, in particular the LLA. From a switch standpoint, I don't see much extra difficulty or burden to look at all NDP packets rather than "just" the DAD. Eric Christian Vogt a écrit : > Greg and Eric - > > Thanks for explaining, Greg. What you are saying was exactly my > understanding of Eric's first message in this thread. But I had > thought that, in his latest message, he was getting at something > different. > > In any case: Eric, can you clarify what is the benefit of your > proposal over the current FCFS solution, which creates packets based > on all packets, including data, DAD, and other ND packets? > > - Christian > > > > On Jun 25, 2009, Greg Daley wrote: > >> Hi Christian, >> >> I think that Eric points out that monitoring ports for any ND >> (in the same fashion that one could monitor ARP today) will identify >> that the addresses are in use, independent of whether the DAD message >> has >> been sent. >> >> This would allow the SAVI device to make bindings on unused addresses >> once it sees >> that the address is functionally in use, even if it doesn't see the DAD >> NS. >> >> >> Greg Daley >> Security Consultant >> NetStar Australia Pty Ltd > > > > > From christian.vogt@ericsson.com Tue Jun 30 10:28:38 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5921D28C419 for ; Tue, 30 Jun 2009 10:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7-6ReoQ4wu5 for ; Tue, 30 Jun 2009 10:28:37 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 3045428C40F for ; Tue, 30 Jun 2009 10:28:37 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n5UHS6rK016464; Tue, 30 Jun 2009 12:28:06 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jun 2009 12:28:06 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jun 2009 12:28:05 -0500 From: Christian Vogt To: Frank Xia In-Reply-To: <006701c9f930$edfcbd80$4201a8c0@china.huawei.com> X-Priority: 3 References: <000801c9f5aa$fe34fa20$3e0c7c0a@china.huawei.com> <6983BF97BFC24D4EA551F1407123291801100086@melmail.netstarnetworks.com> <008a01c9f603$18bb4270$3e0c7c0a@china.huawei.com> <1904C99D-C5F1-4356-AC1D-1A4E8F6DEB22@ericsson.com> <006701c9f930$edfcbd80$4201a8c0@china.huawei.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 30 Jun 2009 10:28:06 -0700 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 30 Jun 2009 17:28:05.0982 (UTC) FILETIME=[20F997E0:01C9F9A8] Cc: SAVI Mailing List , Greg Daley Subject: Re: [savi] feasibility of impmentation SAVI in a switch X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 17:28:38 -0000 On Jun 29, 2009, Frank Xia wrote: >> I don't think SAVI imposes significant new requirements on the >> forwarding plane of layer-2 switches. >> >> The only new requirement for the forwarding plane is to look at an >> extra >> field, the Source Address field in the IP header, and verify this >> in a >> binding table. This doesn't seem to involve significantly more >> sophistication than what layer-2 switches do already today. > > Frank=>This processing needs extra hardware which seems to be > more difficult than software update. Even though we can expect > more sophisticated switches, I still think some switches are > incapable > of implementing SAVI. We should consider this constraint. This is true, of course. And yet there is no way around it. SAVI is about protecting IP source addresses, so SAVI devices must at least be capable of looking at packets' IP source addresses. - Christian From christian.vogt@ericsson.com Tue Jun 30 10:44:20 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11FA728C438 for ; Tue, 30 Jun 2009 10:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7zGAUpGFemg for ; Tue, 30 Jun 2009 10:44:19 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 113783A6E7D for ; Tue, 30 Jun 2009 10:43:47 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n5UHhVdX026824; Tue, 30 Jun 2009 12:43:33 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jun 2009 12:43:31 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jun 2009 12:43:31 -0500 Message-Id: From: Christian Vogt To: "Joel M. Halpern" In-Reply-To: <4A498240.10404@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 30 Jun 2009 10:43:32 -0700 References: <000801c9f5aa$fe34fa20$3e0c7c0a@china.huawei.com> <6983BF97BFC24D4EA551F1407123291801100086@melmail.netstarnetworks.com> <008a01c9f603$18bb4270$3e0c7c0a@china.huawei.com> <1904C99D-C5F1-4356-AC1D-1A4E8F6DEB22@ericsson.com> <4A4950C5.2080206@joelhalpern.com> <95D66AAA-E43C-4D1B-9BFB-B2D4D0B6A518@ericsson.com> <4A498240.10404@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 30 Jun 2009 17:43:31.0121 (UTC) FILETIME=[48669A10:01C9F9AA] Cc: SAVI Mailing List Subject: Re: [savi] feasibility of impmentation SAVI in a switch X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 17:44:20 -0000 On Jun 29, 2009, Joel M. Halpern wrote: > I tend to think that if we can get clarity on the problem, we can > find a > set of solutions with a moderate set of requirements on the devices > and > the system as a whole. Absolutely. That's why we now discuss whether to protect unused addresses. Our charter is very clear about the need to protect the addresses in use on a link, but it doesn't make a statement about the protection of unused addresses. This was deliberately left to the working group, since making a decision on this matter requires some up-front analysis on the benefits and costs involved. I therefore urge people now to focus on answering the key question [1] of whether we want to protect unused addresses. I would also like people to consider the middle-ground approach of protecting unused addresses only in DHCP-only networks, which I proposed in [1]. - Christian [1] http://www.ietf.org/mail-archive/web/savi/current/msg00715.html From christian.vogt@ericsson.com Tue Jun 30 10:50:50 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B19963A6C33 for ; Tue, 30 Jun 2009 10:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZ0EbIJxZLRo for ; Tue, 30 Jun 2009 10:50:50 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 596E828C441 for ; Tue, 30 Jun 2009 10:50:49 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n5UHowlF005898; Tue, 30 Jun 2009 12:51:02 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jun 2009 12:51:00 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jun 2009 12:50:59 -0500 Message-Id: <73ECA0F6-1C5A-49D6-95A0-486C0E0962DA@ericsson.com> From: Christian Vogt To: Eric Levy-Abegnoli In-Reply-To: <4A4A1ECB.50109@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 30 Jun 2009 10:51:00 -0700 References: <4A2C0DFB.3040803@it.uc3m.es> <4A2D2221.4030503@cisco.com><4A2D2739.1000206@it.uc3m.es> <4A2F9E29.5070704@cisco.com><4A30D6CD.8060209@it.uc3m.es><49417952-8570-467E-B312-B759DC3D88DD@ericsson.com><4A35ECEE.7060801@cisco.com><86861CC6-385A-4CBA-9B9C-5D7E56EF119B@ericsson.com><4A42591A.5060408@cisco.com> <20DEB994-56B6-4D86-98BD-6C5F9CA56A5D@ericsson.com> <6983BF97BFC24D4EA551F14071232918011000EC@melmail.netstarnetworks.com> <75D6B967-CF62-4D44-9856-C7052D14BE10@ericsson.com> <4A4A1ECB.50109@cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 30 Jun 2009 17:50:59.0737 (UTC) FILETIME=[53CBF890:01C9F9AB] Cc: SAVI Mailing List , Greg Daley Subject: Re: [savi] A different trade off for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 17:50:50 -0000 Eric - Thanks for clarifying. Yet what I think you need to clarify even further is why the benefits of snooping ND packets, which you identify in your email below, cannot already be obtained with the current SAVI solution, which snoops all packets. Could you do this? - Christian On Jun 30, 2009, Eric Levy-Abegnoli wrote: > Christian, > > there are several alleys where I am proposing something "different", > hence the confusion that I may have created in the thread. Apologies > to > the wg for that. "Unfortunately", these differences are tight up > together to some extend, and it's hard for me to extract one piece and > describe the benefit as if it was standalone (hopefully, if I get a > chance to present the proposal at ietf75, maybe it become clearer). > > To this sepcific point, the reasons why I was proposing to look at > other > ND packets are of two folds: > > - use them to maintain most accurate/up-to-date "state" of the binding > entries, to make more accurate decisions (in case DAD was not seen, > for > movement, to poll entry owners, etc.) > > - to exploit the content of the binding information provided in > these ND > packets, in particular the LLA. > > From a switch standpoint, I don't see much extra difficulty or > burden to > look at all NDP packets rather than "just" the DAD. > > Eric