From christian.vogt@ericsson.com Sat Oct 10 16:42: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 CCD023A68D5 for ; Sat, 10 Oct 2009 16:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 9-iZCBcUIJY3 for ; Sat, 10 Oct 2009 16:42:40 -0700 (PDT) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by core3.amsl.com (Postfix) with ESMTP id B73873A688A for ; Sat, 10 Oct 2009 16:42:40 -0700 (PDT) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id D7018A4D80; Sat, 10 Oct 2009 19:44:27 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sat, 10 Oct 2009 19:44:27 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:resent-from:date:content-transfer-encoding:resent-date:resent-to:references:message-id:to; s=smtpout; bh=HzCIgpDrTEjOK/qCV4nB8ONsd9g=; b=fPCXZv0ejAeQ7AAaPMPCmc2H5fMlAosT8BGj+FKLfDxdmTYBRBJOzKPcg/hC2e4e4MyDg051TX4hfA5T1MBfZBWNOkf9/YJvtvjrI2yp5XMOnbAPSyCsMP+J8yhAH3GNBlnaFHTwn83NnI764tOizhJPjpFZoDHMo9k978zCX6k= X-Sasl-enc: 7z9Ae0yz8cFwTNY98ljKczD4R9VeJZWG5W9fvAs+/lN5 1255218267 Received: from [10.0.1.3] (adsl-99-35-52-135.dsl.pltn13.sbcglobal.net [99.35.52.135]) by mail.messagingengine.com (Postfix) with ESMTPSA id 4D34C690C1; Sat, 10 Oct 2009 19:44:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Christian Vogt In-Reply-To: Resent-From: Christian Vogt Date: Thu, 8 Oct 2009 17:16:45 -0700 Content-Transfer-Encoding: 7bit Resent-Date: Sat, 10 Oct 2009 16:44:48 -0700 Resent-To: SAVI Mailing List References: Message-Id: To: SAVI Mailing List X-Mailer: Apple Mail (2.1076) Resent-Message-Id: <20091010234240.B73873A688A@core3.amsl.com> Subject: Re: [savi] Consensus call on separate documents for DHCP and SLAAC 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, 10 Oct 2009 23:42:41 -0000 Dear all - Thank you for your feedback in our recent consensus call on separate documents for DHCP and SLAAC: > This is a consensus call on whether the SAVI working group should > change > its approach towards producing separate documents for the validation > of > DHCP-assigned IP source addresses and SLAAC-assigned IP source > addresses, plus a framework document. Please answer either "yes" or > "no" to the following question: > > Should the SAVI working group produce separate documents for DHCP- > assigned IP source addresses and SLAAC-assigned IP source addresses, > plus a framework document that describes the relationship between, > and > common principles of, the various IP address validation types? There were 10 responses in favor of the document separation, and no responses against it. Based on this unequivocal result, I conclude that the document separation is the right way forward for the SAVI working group. I will present this conclusion to the IESG and ask for a corresponding adjustment of the working group milestones. In the meantime, the editors of our existing working group documents will work on implementing the conclusion in the documents. - Christian From christian.vogt@ericsson.com Sat Oct 10 16:43: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 92EC73A6929 for ; Sat, 10 Oct 2009 16:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 1PoTbZZO67r2 for ; Sat, 10 Oct 2009 16:43:15 -0700 (PDT) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by core3.amsl.com (Postfix) with ESMTP id 57F0F3A688A for ; Sat, 10 Oct 2009 16:43:15 -0700 (PDT) Received: from compute2.internal (compute2.internal [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id 63797A4DA7; Sat, 10 Oct 2009 19:45:03 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Sat, 10 Oct 2009 19:45:03 -0400 X-Sasl-enc: N4M8dnsRFrB3qJ9vFwGq8mwAeaCVNcMNowOP9Dqmzq0r 1255218302 Received: from [10.0.1.3] (adsl-99-35-52-135.dsl.pltn13.sbcglobal.net [99.35.52.135]) by mail.messagingengine.com (Postfix) with ESMTPSA id 67169690CA; Sat, 10 Oct 2009 19:45:02 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Christian Vogt Resent-Cc: SAVI Mailing List Resent-From: Christian Vogt In-Reply-To: <001501ca32d6$2c6bc190$0f11990a@h3c.huawei3com.com> Date: Thu, 8 Oct 2009 17:17:22 -0700 Content-Transfer-Encoding: 7bit Resent-Date: Sat, 10 Oct 2009 16:45:25 -0700 Resent-To: Lin Tao References: <001501ca32d6$2c6bc190$0f11990a@h3c.huawei3com.com> Message-Id: To: Lin Tao X-Mailer: Apple Mail (2.1076) Resent-Message-Id: <20091010234315.57F0F3A688A@core3.amsl.com> Cc: Bill Fenner , SAVI Mailing List Subject: Re: [savi] Consensus call on separate documents for DHCP and SLAAC 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, 10 Oct 2009 23:43:16 -0000 Lin Tao - It is good to have you aboard the working group. And you are most welcome to help working on our working group documents, such as by reviewing and contributing text. All other working group members are, too. For practical reasons, though, we have designated document editors who hold the pen for a given document. - Christian On Sep 11, 2009, Lin Tao wrote: > Dear workgroup members, > > I have the same idea as below. I think it's clear to describe the > source > assigned process. My answer is "YES". > > I have worked in TCP/IP area for twelve years, and worked in IPv6 area > for six years. I'm very interesting about it. I like the TAO of IETF. > And I have discuss some problem in IETF'S maillist(include SAVI) for > one > year. > > So I want to work together with the intelligent people of IETF. Could > you let me take part in the writting of this draft? Thank you very > much. > > Best Regards, > > LinTao From christian.vogt@ericsson.com Thu Oct 22 16:01: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 6BB803A6911 for ; Thu, 22 Oct 2009 16:01:24 -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 MOrdd89cIc8y for ; Thu, 22 Oct 2009 16:01:23 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 96CBA3A686A for ; Thu, 22 Oct 2009 16:01: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 n9MN1URU006465 for ; Thu, 22 Oct 2009 18:01:33 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 18:01:27 -0500 Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 18:01:26 -0500 Received: from eharopa-t5400.eamcs.ericsson.se (147.117.20.212) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.1.375.2; Thu, 22 Oct 2009 19:01:26 -0400 From: Christian Vogt Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 22 Oct 2009 16:01:59 -0700 Message-ID: <871D15B0-6B49-49F4-AD94-88AC7523044C@ericsson.com> To: SAVI Mailing List MIME-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-OriginalArrivalTime: 22 Oct 2009 23:01:26.0845 (UTC) FILETIME=[958296D0:01CA536B] Subject: [savi] Framework Document Suggestion 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, 22 Oct 2009 23:01:24 -0000 SAVI folks - As part of our recent consensus-based decision for separate documents on DHCP-assigned IP source addresses and on SLAAC-assigned IP source addresses, we agreed to create a framework document that describes the relationship between, and common principles of, the various IP address validation types. Here is a suggestion of how such a framework document may look like: http://tools.ietf.org/id/draft-vogt-savi-framework Your feedback on this document is highly appreciated. Please read and comment. - Christian From christian.vogt@ericsson.com Thu Oct 22 16:52: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 D895A28C1A6 for ; Thu, 22 Oct 2009 16:52:00 -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 i2zQQnhH19Ht for ; Thu, 22 Oct 2009 16:52:00 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 237483A686A for ; Thu, 22 Oct 2009 16:52:00 -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 n9MNq9YL004182 for ; Thu, 22 Oct 2009 18:52:09 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 18:51:17 -0500 Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 18:51:17 -0500 Received: from eharopa-t5400.eamcs.ericsson.se (147.117.20.212) by eusaamw0707.eamcs.ericsson.se (147.117.20.92) with Microsoft SMTP Server id 8.1.375.2; Thu, 22 Oct 2009 19:51:16 -0400 From: Christian Vogt Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 22 Oct 2009 16:51:51 -0700 Message-ID: To: SAVI Mailing List MIME-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-OriginalArrivalTime: 22 Oct 2009 23:51:17.0654 (UTC) FILETIME=[8C2BD360:01CA5372] Subject: [savi] Call for Presentations 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, 22 Oct 2009 23:52:01 -0000 Ladies and Gentlemen - If you would like to make a presentation at our upcoming working group meeting in Hiroshima, please let me know by next Tuesday, October 27. Priority of the next meeting will be on discussing documents that may be candidates for working group adoption. This is the immediate next step for the working group following our decision for separate documents on DHCP, on SLAAC, and on the overall framework. Our upcoming working group meeting is currently scheduled for Monday, November 9, in room Acacia West of the IETF hotel. This may change, though, as the schedule of working group meetings is still tentative. - Christian From zhangdong_rh@huaweisymantec.com Thu Oct 22 19:45: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 8B00E3A689F for ; Thu, 22 Oct 2009 19:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 Q2k8ThOMO5ZM for ; Thu, 22 Oct 2009 19:45:27 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id B38273A6895 for ; Thu, 22 Oct 2009 19:45:27 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=gb2312 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 <0KRY001WP4ZFZ240@hstga01-in.huaweisymantec.com> for savi@ietf.org; Fri, 23 Oct 2009 10:45:15 +0800 (CST) Received: from z90001956 ([10.27.154.173]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KRY00JZE4ZEIX00@hstml01-in.huaweisymantec.com> for savi@ietf.org; Fri, 23 Oct 2009 10:45:15 +0800 (CST) Date: Fri, 23 Oct 2009 10:45:14 +0800 From: Dong Zhang To: Christian Vogt , SAVI Mailing List References: <871D15B0-6B49-49F4-AD94-88AC7523044C@ericsson.com> Message-id: <200910231045135108459@huaweisymantec.com> X-Mailer: Foxmail 6, 10, 201, 20 [cn] Subject: [savi] A few comments on draft-vogt-savi-framework 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, 23 Oct 2009 02:45:28 -0000 Hi Christian, I remember that the framework document would inlcude the relationship between DHCP-assigned IP source addresses and SLAAC-assigned IP source addresses according to the discussion in ml, but it seems that the description about the relationship is not quit clear in draft-vogt-savi-framework. Therefore, I suppose the framework document should has an introduction for the components of savi protocol instances and include in what case which savi protocol instance is used better. Nowthat there is the possibility of co-existence of multiple protocol instances, the interoperability needs to be considered. Is it possible to set priority for the savi protocol instances according to some qualifications? If so, it facilitates choosing the savi protocol instance which is more reliable and effective. Additionally, in section "IP Address Assignment Methods", I think it could comprises these types: static address, dhcp address, SLAAC address, CGA address and manual address. Thank you. B.R. ------------------ Dong Zhang 2009-10-23 From root@core3.amsl.com Fri Oct 23 01:30:08 2009 Return-Path: X-Original-To: savi@ietf.org Delivered-To: savi@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9FFF03A69F3; Fri, 23 Oct 2009 01:30:08 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091023083008.9FFF03A69F3@core3.amsl.com> Date: Fri, 23 Oct 2009 01:30:08 -0700 (PDT) Cc: savi@ietf.org Subject: [savi] I-D Action:draft-ietf-savi-send-01.txt 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, 23 Oct 2009 08:30:08 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Address Validation Improvements Working Group of the IETF. Title : SEND-based Source-Address Validation Implementation Author(s) : M. Bagnulo, A. Garcia-Martinez Filename : draft-ietf-savi-send-01.txt Pages : 19 Date : 2009-10-23 This memo describes SEND SAVI, a mechanism to provide source address validation using the SEND protocol. The proposed mechanism is intended to complement ingress filtering techniques to provide a higher granularity on the control of the source addresses used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-savi-send-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-savi-send-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-23012418.I-D@ietf.org> --NextPart-- From alberto@it.uc3m.es Fri Oct 23 01:47: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 8A6373A68F9 for ; Fri, 23 Oct 2009 01:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 niPXyjJ9pT+p for ; Fri, 23 Oct 2009 01:47:35 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 507243A695C for ; Fri, 23 Oct 2009 01:47:35 -0700 (PDT) Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) by smtp03.uc3m.es (Postfix) with ESMTP id 9A7707F3583 for ; Fri, 23 Oct 2009 10:47:43 +0200 (CEST) From: =?iso-8859-15?Q?Alberto_Garc=EDa?= To: "'SAVI Mailing List'" Date: Fri, 23 Oct 2009 10:47:44 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01CA53CE.40779E70" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpTvQkmHK9alCI2TxOHoM270p22RA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16964.003 Subject: [savi] New version of SEND-SAVI draft 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, 23 Oct 2009 08:47:39 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001A_01CA53CE.40779E70 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Hi, We have uploaded a new version of the SEND SAVI draft. The main changes from version -00 are the following: - Now deployment is perimetrical (with trusted and untrusted ports). Therefore, only border SEND SAVI devices have to check for the validity of a binding. - The mechanism is described as a state machine - Bindings are created by making a SEND SAVI devices issue secured NUD NSOL messages with their own addresses. - SEND Anchors, Certification Path Solicitations/Advertisements. are considered - A mechanism is provided to protect against DoS attacks by blocking for some time ports from which validation was unsuccessful. Regards, Alberto Title : SEND-based Source-Address Validation Implementation Author(s) : M. Bagnulo, A. Garcia-Martinez Filename : draft-ietf-savi-send-01.txt Pages : 19 Date : 2009-10-23 This memo describes SEND SAVI, a mechanism to provide source address validation using the SEND protocol. The proposed mechanism is intended to complement ingress filtering techniques to provide a higher granularity on the control of the source addresses used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-savi-send-01.txt ------=_NextPart_000_001A_01CA53CE.40779E70 Content-Type: text/html; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable

Hi,

We have uploaded a new version of the SEND = SAVI draft.

 

The main changes from version -00 are the = following:

-        Now deployment = is perimetrical (with trusted and untrusted ports). Therefore, only border = SEND SAVI devices have to check for the validity of a = binding.

-        The mechanism = is described as a state machine

-        Bindings are = created by making a SEND SAVI devices issue secured NUD NSOL messages with their = own addresses.

-        SEND Anchors, Certification Path Solicitations/Advertisements… are = considered

-        A mechanism is = provided to protect against DoS attacks by blocking for some time ports from which = validation was unsuccessful.

Regards,

Alberto

 

 

=A0=A0=A0=A0=A0 = Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : SEND-based = Source-Address Validation Implementation

=A0=A0=A0=A0=A0 Author(s)=A0=A0=A0=A0=A0=A0 : M. Bagnulo, A. = Garcia-Martinez

=A0=A0=A0=A0=A0 Filename=A0=A0=A0=A0=A0=A0=A0 : = draft-ietf-savi-send-01.txt

=A0=A0=A0=A0=A0 Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 19

=A0=A0=A0=A0=A0 Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2009-10-23

 

This = memo describes SEND SAVI, a mechanism to provide source = address

validation using the SEND protocol.=A0 The proposed mechanism = is

intended to complement ingress filtering techniques to provide = a

higher granularity on the control of the source addresses = used.

 

A URL = for this Internet-Draft is:

= http://www.ietf.org/internet-drafts/draft-ietf-savi-send-01.= txt

 

 

------=_NextPart_000_001A_01CA53CE.40779E70-- From xiayangsong@huawei.com Fri Oct 23 08:42:33 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 9B8413A6889 for ; Fri, 23 Oct 2009 08:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, 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 lDZqWuomnvrg for ; Fri, 23 Oct 2009 08:42:32 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id DAAE63A6821 for ; Fri, 23 Oct 2009 08:42:32 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRZ000UZ4Z6UK@usaga02-in.huawei.com> for savi@ietf.org; Fri, 23 Oct 2009 08:42:42 -0700 (PDT) Received: from X24512z ([10.124.12.62]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRZ00EUX4Z514@usaga02-in.huawei.com> for savi@ietf.org; Fri, 23 Oct 2009 08:42:42 -0700 (PDT) Date: Fri, 23 Oct 2009 10:42:41 -0500 From: Frank Xia To: Christian Vogt , SAVI Mailing List Message-id: <00a901ca53f7$75336350$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.3598 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: Cc: John Kaippallimalil Subject: Re: [savi] Call for Presentations 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, 23 Oct 2009 15:42:33 -0000 Hi Christian We would like to present our DHCP solution http://tools.ietf.org/id/draft-kaippallimalil-savi-dhcp-pd-00.txt which deals with Broadband Forum networks. 10 minutes are fine. BR Frank ----- Original Message ----- From: "Christian Vogt" To: "SAVI Mailing List" Sent: Thursday, October 22, 2009 6:51 PM Subject: [savi] Call for Presentations > Ladies and Gentlemen - > > If you would like to make a presentation at our upcoming working group > meeting in Hiroshima, please let me know by next Tuesday, October 27. > > Priority of the next meeting will be on discussing documents that may be > candidates for working group adoption. This is the immediate next step > for the working group following our decision for separate documents on > DHCP, on SLAAC, and on the overall framework. > > Our upcoming working group meeting is currently scheduled for Monday, > November 9, in room Acacia West of the IETF hotel. This may change, > though, as the schedule of working group meetings is still tentative. > > - Christian > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From christian.vogt@ericsson.com Fri Oct 23 11:59: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 53B723A695E for ; Fri, 23 Oct 2009 11:59:46 -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 VQINdO9SdHEl for ; Fri, 23 Oct 2009 11:59:45 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 760293A6856 for ; Fri, 23 Oct 2009 11:59:45 -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 n9NIx76k021299; Fri, 23 Oct 2009 13:59:11 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 13:59:04 -0500 Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 13:59:04 -0500 Received: from [155.53.229.47] (147.117.20.212) by eusaamw0707.eamcs.ericsson.se (147.117.20.92) with Microsoft SMTP Server id 8.1.375.2; Fri, 23 Oct 2009 14:59:03 -0400 MIME-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset="us-ascii"; format=flowed; delsp=yes From: Christian Vogt In-Reply-To: <200910231045135108459@huaweisymantec.com> Date: Fri, 23 Oct 2009 11:59:38 -0700 Content-Transfer-Encoding: 7bit Message-ID: <5FDC3979-13E4-480A-A1F6-334B95E2ED66@ericsson.com> References: <871D15B0-6B49-49F4-AD94-88AC7523044C@ericsson.com> <200910231045135108459@huaweisymantec.com> To: Dong Zhang X-Mailer: Apple Mail (2.1076) X-OriginalArrivalTime: 23 Oct 2009 18:59:04.0583 (UTC) FILETIME=[E40F4170:01CA5412] Cc: SAVI Mailing List Subject: Re: [savi] A few comments on draft-vogt-savi-framework 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, 23 Oct 2009 18:59:46 -0000 Dong - Your recollection is correct; the Framework document should and will include the properties of, and the relationship between, the various IP address assignment methods. Section 3.1 in the current Framework document version is a placeholder for this. Text for this section is still to be added, as noted in the document. And yes, this text shall cover not only SLAAC and DHCP, but also SEND and manual IP address configuration. - Christian On Oct 22, 2009, Dong Zhang wrote: > Hi Christian, > > I remember that the framework document would inlcude the relationship > between DHCP-assigned IP source addresses and SLAAC-assigned IP source > addresses according to the discussion in ml, but it seems that the > description about the relationship is not quit clear in > draft-vogt-savi-framework. Therefore, I suppose the framework > document > should has an introduction for the components of savi protocol > instances and include in what case which savi protocol instance is > used > better. > > Nowthat there is the possibility of co-existence of multiple protocol > instances, the interoperability needs to be considered. Is it > possible > to set priority for the savi protocol instances according to some > qualifications? If so, it facilitates choosing the savi protocol > instance which is more reliable and effective. > > Additionally, in section "IP Address Assignment Methods", I think it > could comprises these types: static address, dhcp address, SLAAC > address, CGA address and manual address. > > > Thank you. B.R. From root@core3.amsl.com Mon Oct 26 10:00:01 2009 Return-Path: X-Original-To: savi@ietf.org Delivered-To: savi@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 619BE3A6A60; Mon, 26 Oct 2009 10:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026170001.619BE3A6A60@core3.amsl.com> Date: Mon, 26 Oct 2009 10:00:01 -0700 (PDT) Cc: savi@ietf.org Subject: [savi] I-D Action:draft-ietf-savi-send-02.txt 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, 26 Oct 2009 17:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Address Validation Improvements Working Group of the IETF. Title : SEND-based Source-Address Validation Implementation Author(s) : M. Bagnulo, A. Garcia-Martinez Filename : draft-ietf-savi-send-02.txt Pages : 19 Date : 2009-10-26 This memo describes SEND SAVI, a mechanism to provide source address validation using the SEND protocol. The proposed mechanism is intended to complement ingress filtering techniques to provide a higher granularity on the control of the source addresses used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-savi-send-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-savi-send-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26095232.I-D@ietf.org> --NextPart-- From alberto@it.uc3m.es Mon Oct 26 10:13: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 A80443A6A7B for ; Mon, 26 Oct 2009 10:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 wPs3hhU+E16z for ; Mon, 26 Oct 2009 10:13:08 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id A42413A697C for ; Mon, 26 Oct 2009 10:13:03 -0700 (PDT) Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) by smtp03.uc3m.es (Postfix) with ESMTP id 3BFD97F4149 for ; Mon, 26 Oct 2009 18:13:15 +0100 (CET) From: =?iso-8859-15?Q?Alberto_Garc=EDa?= To: "'SAVI Mailing List'" Date: Mon, 26 Oct 2009 18:13:15 +0100 Message-ID: <4C9E26588E7948F4BEA1F30F49303325@bombo> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03AF_01CA5667.FCE4E540" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 thread-index: AcpWX5NG+fZTrm/4SvOpNm+nTEMYzg== X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16972.000 Subject: [savi] Version -02 of SEND 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, 26 Oct 2009 17:13:09 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_03AF_01CA5667.FCE4E540 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Hi, We have generated a new version (-02) of the SEND SAVI draft. Regards, Alberto Title : SEND-based Source-Address Validation Implementation Author(s) : M. Bagnulo, A. Garcia-Martinez Filename : draft-ietf-savi-send-02.txt Pages : 19 Date : 2009-10-26 This memo describes SEND SAVI, a mechanism to provide source address validation using the SEND protocol. The proposed mechanism is intended to complement ingress filtering techniques to provide a higher granularity on the control of the source addresses used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-savi-send-02.txt ------=_NextPart_000_03AF_01CA5667.FCE4E540 Content-Type: text/html; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable

Hi,

We have generated a new version (-02) of the = SEND SAVI draft.

 

Regards,

Alberto

 

 

=A0=A0=A0=A0=A0=A0 Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : SEND-based Source-Address Validation = Implementation

=A0=A0=A0=A0=A0=A0 Author(s)=A0=A0=A0=A0=A0=A0 : M. Bagnulo, A. = Garcia-Martinez

=A0=A0=A0=A0=A0=A0 Filename=A0=A0=A0=A0=A0=A0=A0 : = draft-ietf-savi-send-02.txt

=A0=A0=A0=A0=A0=A0 Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 19

=A0=A0=A0=A0=A0=A0 Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2009-10-26

 

This = memo describes SEND SAVI, a mechanism to provide source = address

validation using the SEND protocol.=A0 The proposed mechanism = is

intended to complement ingress filtering techniques to provide = a

higher = granularity on the control of the source addresses = used.

 

A URL = for this Internet-Draft is:

= http://www.ietf.org/internet-drafts/draft-ietf-savi-send-02.= txt

 

------=_NextPart_000_03AF_01CA5667.FCE4E540-- From root@core3.amsl.com Mon Oct 26 10:15:01 2009 Return-Path: X-Original-To: savi@ietf.org Delivered-To: savi@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 954143A6AF6; Mon, 26 Oct 2009 10:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026171501.954143A6AF6@core3.amsl.com> Date: Mon, 26 Oct 2009 10:15:01 -0700 (PDT) Cc: savi@ietf.org Subject: [savi] I-D Action:draft-ietf-savi-fcfs-02.txt 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, 26 Oct 2009 17:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Address Validation Improvements Working Group of the IETF. Title : FCFS-SAVI: First-Come First-Serve Source-Address Validation for Locally Assigned Addresses Author(s) : E. Nordmark, et al. Filename : draft-ietf-savi-fcfs-02.txt Pages : 19 Date : 2009-10-26 This memo describes FCFS SAVI a mechanism to provide source address validation for IPv6 networks using the First-Come First-Serve approach. The proposed mechanism is intended to complement ingress filtering techniques to provide a higher granularity on the control of the source addresses used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-savi-fcfs-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-savi-fcfs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26100020.I-D@ietf.org> --NextPart-- From zhangdong_rh@huaweisymantec.com Wed Oct 28 19:36:04 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 C83BB28C103 for ; Wed, 28 Oct 2009 19:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[AWL=-1.237, BAYES_20=-0.74, 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 TmGdy+fIJIfF for ; Wed, 28 Oct 2009 19:36:04 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 0831028C0DB for ; Wed, 28 Oct 2009 19:36:04 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=gb2312 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 <0KS900C2D8JPJ550@hstga01-in.huaweisymantec.com> for savi@ietf.org; Thu, 29 Oct 2009 10:35:49 +0800 (CST) Received: from z90001956 ([10.27.154.173]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KS900I1S8JOPA10@hstml01-in.huaweisymantec.com> for savi@ietf.org; Thu, 29 Oct 2009 10:35:48 +0800 (CST) Date: Thu, 29 Oct 2009 10:35:48 +0800 From: Dong Zhang To: Christian Vogt References: <871D15B0-6B49-49F4-AD94-88AC7523044C@ericsson.com> <200910231045135108459@huaweisymantec.com> <5FDC3979-13E4-480A-A1F6-334B95E2ED66@ericsson.com> Message-id: <200910291035478406365@huaweisymantec.com> X-Mailer: Foxmail 6, 10, 201, 20 [cn] Cc: SAVI Mailing List Subject: Re: [savi] A few comments on draft-vogt-savi-framework 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, 29 Oct 2009 02:36:04 -0000 Hi Christian, >Your recollection is correct; the Framework document should and will >include the properties of, and the relationship between, the various IP >address assignment methods. Section 3.1 in the current Framework >document version is a placeholder for this. Text for this section is >still to be added, as noted in the document. And yes, this text shall >cover not only SLAAC and DHCP, but also SEND and manual IP address >configuration. My concern is that as a vendor, it may implement the savi approaches, including fcfs approach, cps approach and SEND approach. So how to coordinate them needs to be considered. I mean all the approaches work together or choose one to work. I guess it could be the latter. If so, the condition for choosing each approach should be illustrated unambiguously. However, I assumed that there is still an exception, which means several address assignment methods exist in one case. How do the savi approaches deal with this case? Thanks. ------------------ Dong Zhang From christian.vogt@ericsson.com Wed Oct 28 20:57: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 D55DA3A677E for ; Wed, 28 Oct 2009 20:57:23 -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 6kmD3UfD8IvZ for ; Wed, 28 Oct 2009 20:57:23 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 039DC3A67B8 for ; Wed, 28 Oct 2009 20:57:22 -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 n9T3uN4Z008427; Wed, 28 Oct 2009 22:56:26 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 22:56:17 -0500 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 22:56:16 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.35]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 28 Oct 2009 23:56:15 -0400 From: Christian Vogt To: Dong Zhang Date: Wed, 28 Oct 2009 23:56:52 -0400 Thread-Topic: [savi] A few comments on draft-vogt-savi-framework Thread-Index: AcpYS8MClmEx4+BuTkmkLgqP+tM0Xw== Message-ID: <4540D1DA-94A6-4DC9-B5B9-E9C0E32D127B@ericsson.com> References: <871D15B0-6B49-49F4-AD94-88AC7523044C@ericsson.com> <200910231045135108459@huaweisymantec.com> <5FDC3979-13E4-480A-A1F6-334B95E2ED66@ericsson.com> <200910291035478406365@huaweisymantec.com> In-Reply-To: <200910291035478406365@huaweisymantec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Oct 2009 03:56:16.0641 (UTC) FILETIME=[C3EDBF10:01CA584B] Cc: SAVI Mailing List Subject: Re: [savi] A few comments on draft-vogt-savi-framework 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, 29 Oct 2009 03:57:23 -0000 On Oct 28, 2009, Dong Zhang wrote: > My concern is that as a vendor, it may implement the savi approaches, > including fcfs approach, cps approach and SEND approach. So how to > coordinate them needs to be considered. I mean all the approaches work > together or choose one to work. I guess it could be the latter. If so, > the condition for choosing each approach should be illustrated > unambiguously. Yes, I agree. > However, I assumed that there is still an exception, which means > several address assignment methods exist in one case. How do the savi > approaches deal with this case? For this case, we need a prioritization of which address assignment methods take precedence over which other address assignment methods. And you are right that the definition of this prioritization will require care. Does this make sense? Does it address your question and comment? - Christian From zhangdong_rh@huaweisymantec.com Wed Oct 28 22:00: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 696973A6811 for ; Wed, 28 Oct 2009 22:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[AWL=1.363, 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 3+OnWQQjY0Cq for ; Wed, 28 Oct 2009 22:00:42 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 805E43A676A for ; Wed, 28 Oct 2009 22:00:42 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=gb2312 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 <0KS9000EBF8Z4K00@hstga02-in.huaweisymantec.com> for savi@ietf.org; Thu, 29 Oct 2009 13:00:36 +0800 (CST) Received: from z90001956 ([10.27.154.173]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KS90013IF8ZUM10@hstml02-in.huaweisymantec.com> for savi@ietf.org; Thu, 29 Oct 2009 13:00:35 +0800 (CST) Date: Thu, 29 Oct 2009 13:00:35 +0800 From: Dong Zhang To: Christian Vogt References: <871D15B0-6B49-49F4-AD94-88AC7523044C@ericsson.com> <200910231045135108459@huaweisymantec.com> <5FDC3979-13E4-480A-A1F6-334B95E2ED66@ericsson.com> <200910291035478406365@huaweisymantec.com> <4540D1DA-94A6-4DC9-B5B9-E9C0E32D127B@ericsson.com> Message-id: <200910291300345606841@huaweisymantec.com> X-Mailer: Foxmail 6, 10, 201, 20 [cn] Cc: SAVI Mailing List Subject: Re: [savi] A few comments on draft-vogt-savi-framework 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, 29 Oct 2009 05:00:43 -0000 Christian Vogt 2009-10-29 Wrote: >On Oct 28, 2009, Dong Zhang wrote: > >> My concern is that as a vendor, it may implement the savi approaches, >> including fcfs approach, cps approach and SEND approach. So how to >> coordinate them needs to be considered. I mean all the approaches work >> together or choose one to work. I guess it could be the latter. If so, >> the condition for choosing each approach should be illustrated >> unambiguously. > >Yes, I agree. > >> However, I assumed that there is still an exception, which means >> several address assignment methods exist in one case. How do the savi >> approaches deal with this case? > >For this case, we need a prioritization of which address assignment >methods take precedence over which other address assignment methods. >And you are right that the definition of this prioritization will >require care. > >Does this make sense? Does it address your question and comment? Yes, it makes sense. Thanks. > >- Christian ------------------ Dong Zhang 2009-10-29 From marcelo@it.uc3m.es Wed Oct 28 23:50: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 788E73A6A22 for ; Wed, 28 Oct 2009 23:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.48 X-Spam-Level: X-Spam-Status: No, score=-6.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 YpECWt0T2jBf for ; Wed, 28 Oct 2009 23:50:17 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 719F53A69F3 for ; Wed, 28 Oct 2009 23:50:17 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.30.143]) by smtp02.uc3m.es (Postfix) with ESMTP id B68F96C110D; Thu, 29 Oct 2009 07:50:31 +0100 (CET) Message-ID: <4AE93B2C.7060906@it.uc3m.es> Date: Thu, 29 Oct 2009 07:50:20 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Christian Vogt References: <871D15B0-6B49-49F4-AD94-88AC7523044C@ericsson.com> <200910231045135108459@huaweisymantec.com> <5FDC3979-13E4-480A-A1F6-334B95E2ED66@ericsson.com> <200910291035478406365@huaweisymantec.com> <4540D1DA-94A6-4DC9-B5B9-E9C0E32D127B@ericsson.com> In-Reply-To: <4540D1DA-94A6-4DC9-B5B9-E9C0E32D127B@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-16976.003 Cc: SAVI Mailing List Subject: Re: [savi] A few comments on draft-vogt-savi-framework 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, 29 Oct 2009 06:50:18 -0000 Christian Vogt escribió: > On Oct 28, 2009, Dong Zhang wrote: > > >> My concern is that as a vendor, it may implement the savi approaches, >> including fcfs approach, cps approach and SEND approach. So how to >> coordinate them needs to be considered. I mean all the approaches work >> together or choose one to work. I guess it could be the latter. If so, >> the condition for choosing each approach should be illustrated >> unambiguously. >> > > Yes, I agree. > > >> However, I assumed that there is still an exception, which means >> several address assignment methods exist in one case. How do the savi >> approaches deal with this case? >> > > For this case, we need a prioritization of which address assignment > methods take precedence over which other address assignment methods. > And you are right that the definition of this prioritization will > require care. > > yes, moreover, we need to figure if it is enough with a prioritazation or we need to change the mechanisms in order to interact properly. As i stated earlier (and eric noted before me), we certainly need to update send savi to properly interact with the slaac savi (at least, haven't doen the analysis for dhcp savi yet) Regards, marcelo > Does this make sense? Does it address your question and comment? > > - Christian > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > > From alberto@it.uc3m.es Thu Oct 29 03:03:55 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 DD4B33A691A for ; Thu, 29 Oct 2009 03:03:55 -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.001, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 1PWTj3I1Qtj9 for ; Thu, 29 Oct 2009 03:03:55 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 912CC3A6819 for ; Thu, 29 Oct 2009 03:03:54 -0700 (PDT) Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) by smtp01.uc3m.es (Postfix) with ESMTP id 60799BA5276; Thu, 29 Oct 2009 11:04:09 +0100 (CET) From: =?ISO-8859-15?Q?Alberto_Garc=EDa?= To: "'marcelo bagnulo braun'" , "'Christian Vogt'" References: <871D15B0-6B49-49F4-AD94-88AC7523044C@ericsson.com> <200910231045135108459@huaweisymantec.com> <5FDC3979-13E4-480A-A1F6-334B95E2ED66@ericsson.com> <200910291035478406365@huaweisymantec.com><4540D1DA-94A6-4DC9-B5B9-E9C0E32D127B@ericsson.com> <4AE93B2C.7060906@it.uc3m.es> Date: Thu, 29 Oct 2009 11:04:09 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcpYZB9ib3M9rcwhTlGnOOacuVzexAAGJ0iA In-reply-to: <4AE93B2C.7060906@it.uc3m.es> X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16976.003 Cc: 'SAVI Mailing List' Subject: Re: [savi] A few comments on draft-vogt-savi-framework 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, 29 Oct 2009 10:03:56 -0000 Hi | -----Mensaje original----- | De: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] En nombre de marcelo | bagnulo braun | Enviado el: jueves, 29 de octubre de 2009 7:50 | Para: Christian Vogt | CC: SAVI Mailing List | Asunto: Re: [savi] A few comments on draft-vogt-savi-framework | =20 | Christian Vogt escribi=F3: | > On Oct 28, 2009, Dong Zhang wrote: | > | > | >> My concern is that as a vendor, it may implement the savi = approaches, | >> including fcfs approach, cps approach and SEND approach. So how to | >> coordinate them needs to be considered. I mean all the approaches = work | >> together or choose one to work. I guess it could be the latter. If = so, | >> the condition for choosing each approach should be illustrated | >> unambiguously. | >> | > | > Yes, I agree. | > | > | >> However, I assumed that there is still an exception, which means | >> several address assignment methods exist in one case. How do the = savi | >> approaches deal with this case? | >> | > | > For this case, we need a prioritization of which address assignment | > methods take precedence over which other address assignment = methods. | > And you are right that the definition of this prioritization will | > require care. | > | > | yes, moreover, we need to figure if it is enough with a = prioritazation | or we need to change the mechanisms in order to interact properly. As = i | stated earlier (and eric noted before me), we certainly need to = update | send savi to properly interact with the slaac savi (at least, haven't | doen the analysis for dhcp savi yet) | =20 | Regards, marcelo My opinion is that priorization is not enough.=20 I think we need to define "operation modes" (SEND-only, SLAAC-only, SEND-SLAAC-compatible...) and describe the state machine for each one.=20 To support the idea of why we need a new state machine for SEND-SLAAC compatibility, i.e. for a domain in which both SEND hosts and non-SEND = hosts coexist, just consider what a node should do (extending naturally the current FCFS and SEND proposals) if a SAVI device is in NO_BIND state, = and a data packet (not DAD NSOL) is received, from a Validating port VP. In = this case, the SEND SAVI device should send - 2 (unsecured) NSOL messages through Trusted ports (according to FCFS SAVI) - and a secured NUD NSOL message through the Validating Port (according to SEND SAVI And The state is moved to TENTATIVE. In the TENTATIVE state, the SAVI device should maybe wait long enough (a RetransTimer, which is the waiting time for NUD operation) for a secured = NUD NADV even if an unsecured DAD NSOL is received from a trusted port in = the meanwhile, to assure that SEND validated addresses have priority over non-SEND addresses. [Note that this may occur if a SEND host has one collision when performing DAD for an address, and it is not withdrawing = the second address if an unsecured DAD NSOL is received for it, as RFC 3971 says].=20 Different states should be defined (VALID_SEND, VALID_NON_SEND), with different behavior when the valid_timeout expires. So I don't think this is just "ships in the night", but different modes should be defined to integrate all the possible combinations of address configuration mechanisms. Maybe one of these modes should be the default one, but the administrator could set the SAVI devices to the appropriate mode (well, they also have to define which ports are trusted or not...). Does this make sense? Regards, Alberto | =20 | =20 | =20 | > Does this make sense? Does it address your question and comment? | > | > - Christian | > | > | > _______________________________________________ | > savi mailing list | > savi@ietf.org | > https://www.ietf.org/mailman/listinfo/savi | > | > | =20 | _______________________________________________ | savi mailing list | savi@ietf.org | https://www.ietf.org/mailman/listinfo/savi From christian.vogt@ericsson.com Thu Oct 29 13:24: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 D92873A6A39 for ; Thu, 29 Oct 2009 13:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 eAaffBfSJ1BQ for ; Thu, 29 Oct 2009 13:24:13 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id DE6F33A694A for ; Thu, 29 Oct 2009 13:24:12 -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 n9TKOSXI009934; Thu, 29 Oct 2009 15:24:28 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 15:24:21 -0500 Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 15:24:20 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.35]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 29 Oct 2009 16:24:19 -0400 From: Christian Vogt To: =?iso-8859-1?Q?Alberto_Garc=EDa?= Date: Thu, 29 Oct 2009 16:24:57 -0400 Thread-Topic: [savi] A few comments on draft-vogt-savi-framework Thread-Index: AcpY1crk7UURBt59Rr60RxRdo46goQ== Message-ID: <210BBA32-43EB-49EC-B9BB-0C5B9AE7C4EA@ericsson.com> References: <871D15B0-6B49-49F4-AD94-88AC7523044C@ericsson.com> <200910231045135108459@huaweisymantec.com> <5FDC3979-13E4-480A-A1F6-334B95E2ED66@ericsson.com> <200910291035478406365@huaweisymantec.com><4540D1DA-94A6-4DC9-B5B9-E9C0E32D127B@ericsson.com> <4AE93B2C.7060906@it.uc3m.es> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Oct 2009 20:24:20.0858 (UTC) FILETIME=[CC135DA0:01CA58D5] Cc: SAVI Mailing List Subject: Re: [savi] A few comments on draft-vogt-savi-framework 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, 29 Oct 2009 20:24:13 -0000 Alberto - As a member of the working group, not as its chair: You are right =20 that co-existence scenarios need to be handled. But I'm not sure that =20 coexistence requires /special/ behavior. As long as the behavior =20 desired for coexistence scenarios does not preclude the behavior =20 desired for non-coexistence scenarios, I think coexistence should be =20 covered by the /regular/ behavior of the various SAVI protocol =20 specifications. That is, in the particular case of SLAAC/SEND co-=20 existence, I think we should strive for a SAVI SEND protocol that can =20 handle non-SEND-capable SAVI devices. Does this make sense? - Christian On Oct 29, 2009, at 3:04, Alberto Garc=EDa wrote: > My opinion is that priorization is not enough. > I think we need to define "operation modes" (SEND-only, SLAAC-only, > SEND-SLAAC-compatible...) and describe the state machine for each one. > > To support the idea of why we need a new state machine for SEND-SLAAC > compatibility, i.e. for a domain in which both SEND hosts and non-=20 > SEND hosts > coexist, just consider what a node should do (extending naturally the > current FCFS and SEND proposals) if a SAVI device is in NO_BIND =20 > state, and a > data packet (not DAD NSOL) is received, from a Validating port VP. =20 > In this > case, the SEND SAVI device should send > - 2 (unsecured) NSOL messages through Trusted ports (according to > FCFS SAVI) > - and a secured NUD NSOL message through the Validating Port > (according to SEND SAVI > And The state is moved to TENTATIVE. > > In the TENTATIVE state, the SAVI device should maybe wait long =20 > enough (a > RetransTimer, which is the waiting time for NUD operation) for a =20 > secured NUD > NADV even if an unsecured DAD NSOL is received from a trusted port =20 > in the > meanwhile, to assure that SEND validated addresses have priority over > non-SEND addresses. [Note that this may occur if a SEND host has one > collision when performing DAD for an address, and it is not =20 > withdrawing the > second address if an unsecured DAD NSOL is received for it, as RFC =20 > 3971 > says]. > Different states should be defined (VALID_SEND, VALID_NON_SEND), with > different behavior when the valid_timeout expires. > > > So I don't think this is just "ships in the night", but different =20 > modes > should be defined to integrate all the possible combinations of =20 > address > configuration mechanisms. Maybe one of these modes should be the =20 > default > one, but the administrator could set the SAVI devices to the =20 > appropriate > mode (well, they also have to define which ports are trusted or =20 > not...). > > Does this make sense? > Regards, > Alberto From christian.vogt@ericsson.com Thu Oct 29 13:24: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 3D2653A67DD for ; Thu, 29 Oct 2009 13:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 a3-U2mUK0cJH for ; Thu, 29 Oct 2009 13:24:57 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 630833A63EC for ; Thu, 29 Oct 2009 13:24:57 -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 n9TKO3aJ009759; Thu, 29 Oct 2009 15:24:07 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 15:23:23 -0500 Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 15:23:23 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.35]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 29 Oct 2009 16:23:22 -0400 From: Christian Vogt To: Marcelo Bagnulo Braun Date: Thu, 29 Oct 2009 16:24:01 -0400 Thread-Topic: [savi] A few comments on draft-vogt-savi-framework Thread-Index: AcpY1akNHT4Sapl0SniAQnJtvBVtqw== Message-ID: <633E8B21-3B7C-4E17-B661-2E56AA1DB635@ericsson.com> References: <871D15B0-6B49-49F4-AD94-88AC7523044C@ericsson.com> <200910231045135108459@huaweisymantec.com> <5FDC3979-13E4-480A-A1F6-334B95E2ED66@ericsson.com> <200910291035478406365@huaweisymantec.com> <4540D1DA-94A6-4DC9-B5B9-E9C0E32D127B@ericsson.com> <4AE93B2C.7060906@it.uc3m.es> In-Reply-To: <4AE93B2C.7060906@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Oct 2009 20:23:23.0437 (UTC) FILETIME=[A9D99DD0:01CA58D5] Cc: SAVI Mailing List Subject: Re: [savi] A few comments on draft-vogt-savi-framework 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, 29 Oct 2009 20:24:58 -0000 On Oct 28, 2009, marcelo bagnulo braun wrote: >> For this case, we need a prioritization of which address assignment >> methods take precedence over which other address assignment methods. >> And you are right that the definition of this prioritization will >> require care. >> > > yes, moreover, we need to figure if it is enough with a prioritazation > or we need to change the mechanisms in order to interact properly. =20 > As i > stated earlier (and eric noted before me), we certainly need to update > send savi to properly interact with the slaac savi (at least, haven't > doen the analysis for dhcp savi yet) Correct; the prioritization may affect the protocol specifications (SLAAC, DHCP, SEND) just as well as it affects the framework document. My suggestion -- as a working group member, not as a chair -- is that the framework document should talk about the prioritization conceptually, whereas the protocol specifications need to include the details that implement the prioritization. Thoughts? - Christian From zhangdong_rh@huaweisymantec.com Thu Oct 29 18:08:29 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 8555D3A695A for ; Thu, 29 Oct 2009 18:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[AWL=0.909, 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 vT5uZgvyXDUx for ; Thu, 29 Oct 2009 18:08:28 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id B056E3A67FC for ; Thu, 29 Oct 2009 18:08:28 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=gb2312 Received: from hstml01-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 <0KSA00F4YZ5VAS20@hstga02-in.huaweisymantec.com> for savi@ietf.org; Fri, 30 Oct 2009 09:08:19 +0800 (CST) Received: from z90001956 ([10.27.154.173]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KSA00FTEZ5U3H00@hstml01-in.huaweisymantec.com> for savi@ietf.org; Fri, 30 Oct 2009 09:08:19 +0800 (CST) Date: Fri, 30 Oct 2009 09:08:18 +0800 From: Dong Zhang To: Christian Vogt , Marcelo Bagnulo Braun References: <871D15B0-6B49-49F4-AD94-88AC7523044C@ericsson.com> <200910231045135108459@huaweisymantec.com> <5FDC3979-13E4-480A-A1F6-334B95E2ED66@ericsson.com> <200910291035478406365@huaweisymantec.com> <4540D1DA-94A6-4DC9-B5B9-E9C0E32D127B@ericsson.com> <4AE93B2C.7060906@it.uc3m.es> <633E8B21-3B7C-4E17-B661-2E56AA1DB635@ericsson.com> Message-id: <200910300908181272279@huaweisymantec.com> X-Mailer: Foxmail 6, 10, 201, 20 [cn] Cc: SAVI Mailing List Subject: Re: [savi] A few comments on draft-vogt-savi-framework 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, 30 Oct 2009 01:08:29 -0000 Hi, >My suggestion -- as a working group member, not as a chair -- is that >the framework document should talk about the prioritization >conceptually, whereas the protocol specifications need to include the >details that implement the prioritization. Thoughts? I think prioritization is an essential part. And I have already express this consideration in http://www.ietf.org/mail-archive/web/savi/current/msg00949.html Thank you. ------------------ Dong Zhang 2009-10-30 From christian.vogt@ericsson.com Thu Oct 29 23:53:51 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 9B2443A69D8 for ; Thu, 29 Oct 2009 23:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 N3HxuU3KuTGs for ; Thu, 29 Oct 2009 23:53:50 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id D3FFF3A63D3 for ; Thu, 29 Oct 2009 23:53:50 -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 n9U6s5XW017825 for ; Fri, 30 Oct 2009 01:54:05 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 01:53:26 -0500 Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 01:53:26 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.35]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 30 Oct 2009 02:53:25 -0400 From: Christian Vogt To: SAVI Mailing List Date: Fri, 30 Oct 2009 02:53:50 -0400 Thread-Topic: SAVI Meeting Agenda for IETF 76 Thread-Index: AcpZLa0Ibh/PD0rmQ0u2OyL2Jsv+oQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Oct 2009 06:53:26.0182 (UTC) FILETIME=[AE0ABC60:01CA592D] Subject: [savi] SAVI Meeting Agenda for IETF 76 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, 30 Oct 2009 06:53:51 -0000 Folks - Our upcoming working group meeting at IETF 76 in Hiroshima will be on Monday, November 9, 9:00 am - 11:30 am, in the Acacia West room of the IETF hotel. You find the meeting agenda at: http://www.ietf.org/proceedings/09nov/agenda/savi.txt Note that the meeting agenda is still subject to slight changes. Below is a current snapshot. Looking forward to seeing you soon! - Christian ---------------------------------------------------------------------- Agenda of the SAVI working group meeting at IETF 76 Monday, November 9, 9:00 am - 11:30 am, Acacia West room ---------------------------------------------------------------------- 09:00 Introduction and administrativa ........................ 10 min Christian Vogt 09:10 SAVI Framework ......................................... 25 min Christian Vogt (draft-vogt-savi-framework) 09:35 SAVI for Stateless Address Autoconfiguration ........... 25 min Marcelo Bagnulo (draft-ietf-savi-fcfs) 10:00 SAVI for DHCP .......................................... 25 min Jun Bi (draft-bi-savi-cps) 10:25 SAVI for Secure Neighbor Discovery ..................... 25 min Alberto Garcia (draft-ietf-savi-send ) 10:50 CNGI-CERNET2 SAVI deployment update .................... 20 min Jun Bi 11:10 SAVI for Delegated IPv6 Prefixes ....................... 20 min John Kaippallimalil (draft-kaippallimalil-savi-dhcp-pd) 11:30 End of working group meeting From marcelo@it.uc3m.es Fri Oct 30 00:50: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 000BA3A68E3 for ; Fri, 30 Oct 2009 00:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.395 X-Spam-Level: X-Spam-Status: No, score=-6.395 tagged_above=-999 required=5 tests=[AWL=0.204, 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 LwYlPDrOuyNM for ; Fri, 30 Oct 2009 00:50:40 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 50C143A689B for ; Fri, 30 Oct 2009 00:50:39 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id 5A7DB659D48; Fri, 30 Oct 2009 08:50:55 +0100 (CET) Message-ID: <4AEA9ADF.4030901@it.uc3m.es> Date: Fri, 30 Oct 2009 08:50:55 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Christian Vogt References: <871D15B0-6B49-49F4-AD94-88AC7523044C@ericsson.com> <200910231045135108459@huaweisymantec.com> <5FDC3979-13E4-480A-A1F6-334B95E2ED66@ericsson.com> <200910291035478406365@huaweisymantec.com><4540D1DA-94A6-4DC9-B5B9-E9C0E32D127B@ericsson.com> <4AE93B2C.7060906@it.uc3m.es> <210BBA32-43EB-49EC-B9BB-0C5B9AE7C4EA@ericsson.com> In-Reply-To: <210BBA32-43EB-49EC-B9BB-0C5B9AE7C4EA@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-16978.003 Cc: SAVI Mailing List , =?ISO-8859-1?Q?Alberto_Garc=EDa?= Subject: Re: [savi] A few comments on draft-vogt-savi-framework 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, 30 Oct 2009 07:50:42 -0000 Christian Vogt escribió: > Alberto - > > As a member of the working group, not as its chair: You are right > that co-existence scenarios need to be handled. But I'm not sure that > coexistence requires /special/ behavior. As long as the behavior > desired for coexistence scenarios does not preclude the behavior > desired for non-coexistence scenarios, I think coexistence should be > covered by the /regular/ behavior of the various SAVI protocol > specifications. That is, in the particular case of SLAAC/SEND co- > existence, I think we should strive for a SAVI SEND protocol that can > handle non-SEND-capable SAVI devices. > > Does this make sense? > yes, but the question is what do we do with the slaac send in the presence of send capable hosts. If we want to support them, then all slaac savi devices need to implement the send savi, which seems an overkill for a the send protocol which deployment is non existent afaict If we allow sllac savi only devices, then plugging a send host would not work well (in particular, the send node can be filtered by the savi device in some cases, making the deployment of send even harder later on. So this is a tough call imho Regards, marcelo > - Christian > > > > On Oct 29, 2009, at 3:04, Alberto García wrote: > > >> My opinion is that priorization is not enough. >> I think we need to define "operation modes" (SEND-only, SLAAC-only, >> SEND-SLAAC-compatible...) and describe the state machine for each one. >> >> To support the idea of why we need a new state machine for SEND-SLAAC >> compatibility, i.e. for a domain in which both SEND hosts and non- >> SEND hosts >> coexist, just consider what a node should do (extending naturally the >> current FCFS and SEND proposals) if a SAVI device is in NO_BIND >> state, and a >> data packet (not DAD NSOL) is received, from a Validating port VP. >> In this >> case, the SEND SAVI device should send >> - 2 (unsecured) NSOL messages through Trusted ports (according to >> FCFS SAVI) >> - and a secured NUD NSOL message through the Validating Port >> (according to SEND SAVI >> And The state is moved to TENTATIVE. >> >> In the TENTATIVE state, the SAVI device should maybe wait long >> enough (a >> RetransTimer, which is the waiting time for NUD operation) for a >> secured NUD >> NADV even if an unsecured DAD NSOL is received from a trusted port >> in the >> meanwhile, to assure that SEND validated addresses have priority over >> non-SEND addresses. [Note that this may occur if a SEND host has one >> collision when performing DAD for an address, and it is not >> withdrawing the >> second address if an unsecured DAD NSOL is received for it, as RFC >> 3971 >> says]. >> Different states should be defined (VALID_SEND, VALID_NON_SEND), with >> different behavior when the valid_timeout expires. >> >> >> So I don't think this is just "ships in the night", but different >> modes >> should be defined to integrate all the possible combinations of >> address >> configuration mechanisms. Maybe one of these modes should be the >> default >> one, but the administrator could set the SAVI devices to the >> appropriate >> mode (well, they also have to define which ports are trusted or >> not...). >> >> Does this make sense? >> Regards, >> Alberto >> > > > > > From junbi@cernet.edu.cn Fri Oct 30 01:47: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 F2CB93A6A59 for ; Fri, 30 Oct 2009 01:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.098 X-Spam-Level: X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696, 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 EYLQaLxuKroJ for ; Fri, 30 Oct 2009 01:47:19 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 09EEC3A67E5 for ; Fri, 30 Oct 2009 01:47:17 -0700 (PDT) Received: from junbiVAIO([59.66.24.41]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm364aeaafc4; Fri, 30 Oct 2009 16:47:31 +0800 Message-ID: <001D73EA1D454F0BAE91F989B597D73D@junbiVAIO> From: "Bi Jun" To: "SAVI Mailing List" Date: Fri, 30 Oct 2009 16:42:51 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_023C_01CA5980.056F8100" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: 54tInDXB Subject: [savi] SAVI Solution for DHCPv4/v6 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, 30 Oct 2009 08:47:20 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_023C_01CA5980.056F8100 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Dear WG members, Please read the SAVI solution for DHCP. =20 This draft is for DHCP case. We removed the text on SLAAC of CPS-01 and = contributed to SAVI SLAAC draft. This version have taken the suggestions from Christian, Eric = Levy-Abegnoli , Alberto Garc=A8=AAa, etc. Thanks to all of them. Please provide your comments. thanks, Jun Bi http://www.ietf.org/id/draft-bi-savi-cps-02.txt =20 SAVI Solution for DHCPv4/v6 draft-bi-savi-cps-02.txt Abstract This document specifies the procedure of setting up bindings between DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and anchor (refer to [SAVI-framework]) on SAVI (Source Address Validation Improvements) device. The bindings can be used to filter packets with forged IP addresses. ------=_NextPart_000_023C_01CA5980.056F8100 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Dear WG members,
 
Please read the SAVI solution for DHCP.  =
This=20 draft is for DHCP case. We removed the text on SLAAC of CPS-01 and = contributed=20 to SAVI SLAAC draft.
This version have taken the suggestions from = Christian,=20 Eric Levy-Abegnoli , Alberto Garc=A8=AAa, etc. Thanks to all of=20 them.
Please provide your = comments.
thanks,
Jun=20 Bi
 
  http://www.ietf.= org/id/draft-bi-savi-cps-02.txt      &n= bsp; 
 
       =20        SAVI Solution for=20 DHCPv4/v6
          =             &= nbsp; =20 draft-bi-savi-cps-02.txt
 
Abstract

   This document = specifies the=20 procedure of setting up bindings between
   DHCPv4 = [RFC2131]/DHCPv6=20 [RFC3315] assigned source IP address and
   anchor (refer = to=20 [SAVI-framework]) on SAVI (Source Address Validation
  =20 Improvements) device. The bindings can be used to filter packets=20 with
   forged IP addresses.
------=_NextPart_000_023C_01CA5980.056F8100-- From junbi@cernet.edu.cn Fri Oct 30 03:32:29 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 51B403A6929 for ; Fri, 30 Oct 2009 03:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.336 X-Spam-Level: ** X-Spam-Status: No, score=2.336 tagged_above=-999 required=5 tests=[AWL=-2.239, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_73=0.6, SUBJ_ALL_CAPS=2.077] 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 MP8lCmnvRI15 for ; Fri, 30 Oct 2009 03:32:23 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 188E13A699A for ; Fri, 30 Oct 2009 03:32:12 -0700 (PDT) Received: from junbiVAIO([59.66.24.41]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54aeac859; Fri, 30 Oct 2009 18:32:24 +0800 Message-ID: <0AC38B235E5F49AA922FC02151234C9C@junbiVAIO> From: "Bi Jun" To: "'SAVI Mailing List'" Date: Fri, 30 Oct 2009 18:27:46 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0470_01CA598E.AD80D4D0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: 59YmoDXB Subject: [savi] IETF SAVI SLAAC 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, 30 Oct 2009 10:32:29 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_0470_01CA598E.AD80D4D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0471_01CA598E.AD80D4D0" ------=_NextPart_001_0471_01CA598E.AD80D4D0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Dear Erik=A3=ACMarcelo, and Eric, Below is our revision suggestion towards final draft-ietf-slaac-00. Thanks, Jun Bi A merge proposal based on FCFS-02 and slaac-cps-00(as attachments): =20 Basic frame: FCFS-02. =20 1. Sections to Add =20 1.1 Add a section for IPv4(Section 10.1.2 in slaac-cps may contribute) =20 Add a section to handle IPv4 address using the similar mechanism. This = section specifies the procedure to set up binding for manually = configured(but not static) IPv4 address, as described in [RFC5227].=20 This mechanism can handle the situation in which users can configure = their address manually so long as the address belongs to an allowed = prefix. This situation is different from that any interface can only configure a = fixed address, and manually configuration on the SAVI device = wouldn=A1=AFt handle it. =20 1.2 Add a port type: host port, as a complement of port-validation =20 For a port directly attached to a single host, mechanism mainly based on = control packet snooping(Section 10.1.1 in slaac-cps may contribute) = would be more lightweight and secure. =20 As described in RFC4862, DAD must be performed before assigning any = address. It=A1=AFs the reasonability basis of control packet snooping = only. For a savi-host port, it is rarely necessary for the savi device = to trigger a detection on behavior of the attached host, unless in the = case that detection packets are got lost(with an extremely little = possibility). In slaac-cps00, the savi device should snoop a wide scope of control = packet, to avoid dropping valid packet as much as possible. Will a host = send data packet directly without performing any resolution? Even in an extreme bad situation, the savi device can send probes = whenever a new address appears(but this function is turned off by = default.). Although this seems the same as FCFS, there is a benefit the = savi device can control the rate to prevent DoS attack. =20 The security aspect: (1) A clear entry number limit can be set for each host and avoid = binding entry exhaustion.(This limit can never be set on a port accessed = by a number of hosts.) (2) A rate limit of sending probes can be set to avoid DoS. (This limit = cannot be set on other types of ports, either.) (3) A more strict filtering policy(e.g., default dropping) can be set on = such port, to stop one packet attack and DoS against the savi device = itself. (Default dropping policy cannot be set on other kinds of ports.) (4) A host level granularity trace ability can be enabled. =20 1.3 Add a section to specify the procedure of check a packet(Section = 12 in slaac-cps can contribute). 1.4 Add a section to specify the procedure to remove a binding(Section = 11 in slaac-cps can contribute). 1.5 Add a section to clearly specify the details on special = situations(Section 13,14,15 in slaac-cps can contribute). 1.6 Add a section to specify the related constants, especially the = time related constants, e.g, TENT_LT. =20 2. Sections to be moved to framework =20 2.1, 2.2, 2.4, 2.5 These sections are great analysis work on SAVI solutions in common. They = should be moved to savi-framework or another informational draft for = clarity. =20 3. Open issues: =20 3.1 Whether to build a perimeter based on SAVI functions? Benefits:=20 1. An attacker cannot spoof any address in SAVI area; 2. Spoofing packets will be dropped on reaching the perimeter; 3. Spoofing packets from non-SAVI area will be filtered at a = =A1=B0anchor=A1=B1 level. Cost: 1. Control plane cost: A SAVI device will potentially keep a = record of all the addresses on the link. It is unconvinced that the = storage distribution mechanism will work indeed. More details of this = mechanism should be specified. 2. Additional communication cost: using NDP as a BDP to distribute = bindings; 3. Data plane cost: whenever check a packet, the SAVI device must = go through an extremely huge deny list. Possible error: 1. Whether is it reasonable to set up bindings for hosts out of = SAVI area based on FCFS? -The owner of an address is never necessary to send a packet first to = the SAVI area. Then another host can set up a binding before it and make = the perimeter to drop the traffic of the address owner. =20 Alterative:=20 Make it an optional function, or use mature techniques: -Separate the prefix scope of SAVI area and non-SAVI area. = Using ingress filter the perform prefix level check. This is sure to work. ------=_NextPart_001_0471_01CA598E.AD80D4D0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Dear Erik=A3=ACMarcelo, and = Eric,

Below is=20 our revision suggestion towards final = draft-ietf-slaac-00.
Thanks,
Jun Bi

A merge proposal based on = FCFS-02 and=20 slaac-cps-00(as attachments):

 

Basic frame: = FCFS-02.

 

1.      =20 Sections to = Add

 

1.1   = Add a section for IPv4(Section 10.1.2 in slaac-cps may=20 contribute)

 

Add a section to handle IPv4 address using the similar = mechanism.=20 This section specifies the procedure to set up binding for manually=20 configured(but not static) IPv4 address, as described in [RFC5227].=20

This mechanism can handle the situation in which users can = configure=20 their address manually so long as the address belongs to an allowed=20 prefix.

This situation is different from that any interface can = only=20 configure a fixed address, and manually configuration on the SAVI device = wouldn=A1=AFt handle it.

 

1.2   = Add a port type: host port, as a complement of=20 port-validation

 

For a port directly attached to a single host, mechanism = mainly based=20 on control packet snooping(Section 10.1.1 in slaac-cps may contribute) = would be=20 more lightweight and secure.

 

As described in RFC4862, DAD must be performed before = assigning any=20 address. It=A1=AFs the reasonability basis of control packet snooping = only. For a=20 savi-host port, it is rarely necessary for the savi device to trigger a=20 detection on behavior of the attached host, unless in the case that = detection=20 packets are got lost(with an extremely little=20 possibility).

In slaac-cps00, the savi device should snoop a wide scope = of control=20 packet, to avoid dropping valid packet as much as possible. Will a host = send=20 data packet directly without performing any = resolution?

Even in an extreme bad situation, the savi device can send = probes=20 whenever a new address appears(but this function is turned off by = default.).=20 Although this seems the same as FCFS, there is a benefit the savi device = can=20 control the rate to prevent DoS attack.

 

The security aspect:

(1) A clear entry number limit can be set for each host and = avoid=20 binding entry exhaustion.(This limit can never be set on a port accessed = by a=20 number of hosts.)

(2) A rate limit of sending probes can be set to avoid DoS. = (This=20 limit cannot be set on other types of ports, = either.)

(3) A more strict filtering policy(e.g., default dropping) = can be set=20 on such port, to stop one packet attack and DoS against the savi device = itself.=20 (Default dropping policy cannot be set on other kinds of=20 ports.)

(4) A host level granularity trace ability can be=20 enabled.

 

1.3   = Add a section to specify the procedure of check a = packet(Section 12=20 in slaac-cps can contribute).

1.4   = Add a section to specify the procedure to remove a = binding(Section 11=20 in slaac-cps can contribute).

1.5   = Add a section to clearly specify the details on special=20 situations(Section 13,14,15 in slaac-cps can = contribute).

1.6   = Add a section to specify the related constants, especially = the time=20 related constants, e.g, TENT_LT.

 

2.      =20 Sections to be moved to=20 framework

 

2.1, 2.2, 2.4, = 2.5

These sections are great = analysis work on=20 SAVI solutions in common. They should be moved to savi-framework or = another=20 informational draft for clarity.

 

3.      =20 Open = issues:

 

3.1   = Whether to build a perimeter based on SAVI=20 functions?

Benefits:

1. An attacker cannot = spoof any=20 address in SAVI area;

         2. = Spoofing=20 packets will be dropped on reaching the perimeter;

         3. = Spoofing=20 packets from non-SAVI area will be filtered at a =A1=B0anchor=A1=B1=20 level.

Cost:

1.      =20 Control plane cost: A SAVI = device will=20 potentially keep a record of all the addresses on the link. It is = unconvinced=20 that the storage distribution mechanism will work indeed. More details = of this=20 mechanism should be specified.

2.      =20 Additional communication cost: = using NDP=20 as a BDP to distribute bindings;

3.      =20 Data plane cost: whenever check = a packet,=20 the SAVI device must go through an extremely huge deny=20 list.

Possible error:

1.      =20 Whether is it reasonable to set = up=20 bindings for hosts out of SAVI area based on FCFS?

-The owner of = an address is=20 never necessary to send a packet first to the SAVI area. Then another = host can=20 set up a binding before it and make the perimeter to drop the traffic of = the=20 address owner.

 

Alterative:

          =  =20   Make it an optional function, or use mature=20 techniques:

          =  =20   -Separate the prefix scope of SAVI area and non-SAVI area. Using = ingress=20 filter the perform prefix level check.

          = This is=20 sure to work.

------=_NextPart_001_0471_01CA598E.AD80D4D0-- ------=_NextPart_000_0470_01CA598E.AD80D4D0 Content-Type: text/plain; name="draft-bi-slaac-cps-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-bi-slaac-cps-00.txt" SAVI =20 Internet Draft =20 Intended status: Standard Tracks =20 Expires: December 2009 =20 August 3, 2009 SAVI Solution for IPv6 SLAAC and IPv4 Manual Configuration draft-bi-slaac-cps-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on February 29, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Expires December 3,2009 [Page 1] =0C Internet-Draft Control Packet Snooping Based Binding August 2009 This document specifies a SAVI mechanism for IP version 4 manually configured addresses and IP version 6 stateless auto-configuration addresses. Table of Contents 1. Introduction ................................................ 3 2. Conventions used in this document............................ 3 3. Terminology ................................................. 3 4. Mechanism Overview .......................................... 3 5. Related Protocols ........................................... 4 6. Definition of Anchor......................................... 4 7. Conceptual Data Structures................................... 5 8. Scenarios ................................................... 6 8.1. Switch scenario......................................... 6 8.1.1. Port Attributes.................................... 6 8.1.1.1. SAVI-Host Attribute........................... 7 8.1.1.2. SAVI-SAVI Attribute........................... 7 8.1.1.3. SAVI-UCA (Uncontrollable area) Attribute...... 7 8.1.1.4. SAVI-DHCP-PD-Trust Attribute ................. 7 8.1.1.5. SAVI-RA-Trust Attribute ...................... 8 8.2. Wireless Scenario....................................... 8 9. Prefix Configuration......................................... 8 10. Binding Setup .............................................. 9 10.1. Address Assignment Protocol Snooping .................. 9 10.1.1. DAD Snooping...................................... 9 10.1.1.1. Process of DAD Snooping ..................... 9 10.1.1.2. State Machine of ND Snooping ............... 10 10.1.2. Gratuitous ARP Snooping.......................... 10 10.1.2.1. Process of Gratuitous ARP Snooping ......... 10 10.1.2.2. State Machine of Gratuitous ARP Snooping.... 11 10.2. Probe Trigger ........................................ 11 10.2.1. NDP/ARP Triggered DAD Probe and Binding ......... 11 10.2.2. Data Packet Triggered DAD Probe and Bindings..... 11 10.3. Other Considerations on Binding Setup ................ 12 10.4. Upper Bound and Minimum of Binding Number ............ 12 11. Clear Binding ............................................. 12 11.1. Clear-on-Query mode................................... 12 11.2. Clear-on-Demand mode.................................. 13 12. Filtering Specification.................................... 13 12.1. Filter Data Packet.................................... 13 12.2. Filter Control Packet................................. 13 13. Solution for Special Situations............................ 14 13.1. Multiple Interfaces................................... 14 13.2. Port Movement ........................................ 15 14. Considerations on Security Risks........................... 15 Expires February 29, 2010 [Page 2] =0C Internet-Draft Control Packet Snooping Based Binding August 2009 14.1. Operating system support.............................. 15 14.2. Malicious replier..................................... 16 14.3. Inactive node ........................................ 16 15. Incremental Deployment Suggestion.......................... 17 16. Constants ................................................. 17 17. Security Considerations.................................... 17 18. IANA Considerations........................................ 17 19. References ................................................ 18 19.1. Normative References.................................. 18 19.2. Informative References................................ 18 20. Acknowledgments ........................................... 18 Authors' Addresses ............................................ 19 1. Introduction This document specifies a SAVI mechanism for IP version 4 manually configured addresses and IP version 6 stateless auto-configuration addresses. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Terminology Anchor - The entity to bind source IP address with. SLAAC - Stateless Auto-configuration described in [RFC4862]. SAVI switch - A switch deployed this mechanism. Non-SAVI switch - A switch not deployed any SAVI mechanism. SAVI device - An unspecified device possesses SAVI function. Probe - The NS/ARP Request/NUD packet sent by SAVI device on the behavior of hosts. 4. Mechanism Overview This mechanism is designed to provide a host level source IP address validation granularity, as a supplement of BCP38. This mechanism is deployed on the access device (including access switch, wireless access point/controller, etc). It works in IPv6 SLAAC only scenario Expires February 29, 2010 [Page 3] =0C Internet-Draft Control Packet Snooping Based Binding August 2009 and IPv4 manual configuration scenarios. This mechanism requires no change on host, and no new protocol is designed. This document mainly focuses on 1: When and how to set up initial bindings; 2: When and how to remove bindings; 3: The filtering policy on access port of SAVI switch; 4: The policy on other kinds of ports. 5. Related Protocols Snooping address assignment related protocols is the main part of this mechanism. Duplicate address detection (DAD) - The procedure to detect whether an IPv6 address is duplicated before assigning it to an interface, described in [RFC4862]. DAD packets can be used to set up bindings. Gratuitous Address Resolution Protocol (Gratuitous ARP) - The procedure to detect whether an IPv4 address is duplicated. Gratuitous ARP packets can be used to set up bindings. Unsolicited Neighbor Advertisement (Unsolicited NA) - Unsolicited NA can be used to trigger the SAVI device to send DAD probes. Neighbor Solicitation (NS) - Neighbor Solicitation packets can be used to trigger the SAVI device to send DAD probes. ARP Request - ARP Request can be used to trigger the SAVI device to send ARP probes. ARP Response - ARP Response can be used to trigger the SAVI device to send ARP probes. 6. Definition of Anchor Anchor is an important concept for this mechanism. In this document, anchor is the entity to bind source address with. To make the binding secure, the anchor itself must be unspoofable. Generally, following entities can be used as anchor: Exclusive switch port - When a switch port is exclusive for a host, this port is unspoofable for other hosts. MAC address in 802.1ae/af and 802.11i - 802.1ae/af and 802.11i protect the security of MAC address. When such technology is deployed in the network, MAC address can be used as anchor. Expires February 29, 2010 [Page 4] =0C Internet-Draft Control Packet Snooping Based Binding August 2009 However, when strict secure anchor is not achievable in the network, loose secure anchor can be used. Generally, shared switch port and MAC address are loose secure anchors. Loose secure anchor may cause false negative and potential false positive, thus it is not recommended to use such kind of anchors. The work to specify which entities can be used as anchor, and how secure these anchors is beyond the scope of the document. 7. Conceptual Data Structures This section describes the possible conceptual data structures used in this mechanism. Two main data structures are used to record bindings and their states respectively. There are redundancy between the two structures, for the consideration of separation of data plane and control plane. Binding State Table (BST) - This table contains this state of binding between source address and anchor. Entries are keyed on the anchor and source IP address. Each entry has a lifetime item which records the remaining lifetime of this entry, an item which records the state of this binding and an item record other information. Whenever the lifetime expires, the entry should be deleted, except for the entries with DHCPv4_DETECTION/ DHCPv4_DETECTION/SAC_START/MANUALv4_START state. Filtering Table (FT) - This table contains the bindings between anchor and address, keyed on anchor. This table doesn't contain any state of the binding. This table is used to filter packet. Access Control List can be regarded as an instance of this table. The states of binding in Binding State Table are as follows: SAC_START A DAD NS has been sent by the host. The target address is neither got from DHCP nor static. SAC_BOUND The address has passed DAD and it is bound with anchor. Expires February 29, 2010 [Page 5] =0C Internet-Draft Control Packet Snooping Based Binding August 2009 SAC_QUERY The bound address is being queried by another node. If there is no response in a time constant, the binding should be deleted. MANUALv4_START A gratuitous ARP has been sent by the host. The target address is neither got from DHCP nor static. MANUALv4_BOUND The address has passed DAD and it is bound with anchor. MANUALv4_QUERY The bound address is being queried by another node. If there is no response in a time = constant, the binding should be deleted. 8. Scenarios This section specifies the deployment scenarios. Two basic scenarios are discussed here: switch scenario and wireless scenario. 8.1. Switch scenario Switch scenario means a switched network composed by a number of switches. This mechanism is deployed on one or more of them. In a switch scenario, always port is used as anchor. This section specifies the attributes of switch port, and the process on each kind. The method of distinguishing each kind of port in management is through manual configuration. The port attribute is just conceptual. 8.1.1. Port Attributes The attribute of port depends on the role of the port. A port on a SAVI switch can be set to have none or more of all the attributes. If a port has an attribute, the corresponding snooping and filtering policy will be used on this port. If a port has multiple attributes, all the corresponding policies will be used. Conflict attributes MUST not be set to the same port. Expires February 29, 2010 [Page 6] =0C Internet-Draft Control Packet Snooping Based Binding August 2009 8.1.1.1. SAVI-Host Attribute If a port is directly connected with a host, this port MUST be set to have SAVI-Host attribute. If a port is connected with a limited number of hosts, it MAY be set this attribute. If a port has SAVI-Host attribute, control packet snooping MUST be performed on this port to set up bindings and data packet triggered DAD SHOULD be performed on this port. Data packets from this port will be processed with different choices. 8.1.1.2. SAVI-SAVI Attribute If and only if a port is connected with port on another SAVI switch, it can be set to have this attribute. This attribute is a conflict attribute of SAVI-Host attribute and SAVI-UCA attribute. No packet snooping will be performed on port with this attribute. Packet from port with such attribute will be forwarded directly. 8.1.1.3. SAVI-UCA (Uncontrollable area) Attribute If a port is connected to an uncontrollable area with unspecified number of host, it SHOULD be set to have this attribute. This attribute is a conflict attribute of SAVI-Host attribute and SAVI- SAVI attribute. The network administrator SHOULD avoid using this attribute. It is SUGGESTED to use VLAN to reduce the scale of a single SAVI area and avoid using this attribute. The binding setup procedure and filtering policy are still not specified. It is SUGGESTED not to set up bindings on port with this attribute. The packet from this port SHOULD be checked whether conflict with current bindings. If bindings are set up on port with this attribute, it is SUGGESTED either the data packet MUST be used to trigger DAD, or using "default-forwarding" policy. 8.1.1.4. SAVI-DHCP-PD-Trust Attribute If and only if trustable DHCP-PD messages are received from a port, it can be set to have this attribute. Expires February 29, 2010 [Page 7] =0C Internet-Draft Control Packet Snooping Based Binding August 2009 In the situation DHCP-PD is used to configure prefix of the network, there must be a port configured to have this attribute. The switch should learn reliable DHCP-PD prefix from this port if DHCP-PD is configured. 8.1.1.5. SAVI-RA-Trust Attribute If and only if a port is directly connected with a trustable router, or is a trunk port from which the Router Advertisement should arrive, it can be set to have this attribute. When a port is configured to have a SAVI-RA-Trust attribute, the switch trusts the Router Advertisement messages from this port to learn the prefixes used on the link. There may be no SAVI-RA-Trust port in the network, even if only SLAAC is used to configure address. Router Advertisement received not from SAVI-RA-Trust port MUST be discarded. 8.2. Wireless Scenario In a wireless scenario, usually MAC address is used as anchor. Currently there is nothing to specify in wireless scenario. 9. Prefix Configuration Before setting up a host-level granularity binding table, it is important to configure correct prefixes on the SAVI device. At least two prefix scopes must be set: the IPv4 prefix and IPv6 prefixes. This document suggests set 3 prefix scopes: IPv4 Prefix: The allowed scope of any kind of IPv4 addresses. It can be set manually. IPv6 SLAAC Prefixes: The allowed scope of SLAAC and manually configured IPv6 addresses. It can be set through snooping RA message from port with SAVI-RA-Trust attribute, or manual configuration. FE80::/64 MUST be set to a feasible prefix. Expires February 29, 2010 [Page 8] =0C Internet-Draft Control Packet Snooping Based Binding August 2009 If some of the prefix scope is set to have non prefix, it implies corresponding address assignment method is not allowed in the network. There is no need to explicitly present these prefix scopes. But these restrictions MUST be used as premier check in binding set up. 10. Binding Setup This section specifies how to set up bindings. Currently bindings are only required to be set up on the ports with SAVI-Host attribute. The binding setup procedures have two main types: address assignment protocol snooping and probe trigger. 10.1. Address Assignment Protocol Snooping This section specifies how to set up bindings based on address assignment protocol snooping. It is composed by DAD snooping and gratuitous ARP snooping. 10.1.1. DAD Snooping 10.1.1.1. Process of DAD Snooping This process is designed for stateless auto-configuration assigned IPv6 address and manually configured IPv6 address. If SLAAC is enabled in the network, this procedure MUST be performed. Whenever a DAD NS is received from the host, if the address is not in BST and has a permitted prefix, generate a new entry in BST and set the state of the entry to be SAC_START. The lifetime of the entry is set to be MAX_DAD _DELAY. If an NA response for the address is received from other nodes, delete the entry. If the lifetime expires, set the state of the entry to be SAC_BOUND. The lifetime of this entry is set to MAX_SAC_LIFETIME. An entry is added into the Filter Table. If the lifetime of an entry with state SAC_BOUND expires, set the lifetime to be MAX_DAD_PREPARE_DELAY and send a NS for the address. If there is no response before the lifetime expires, delete the entry in BST and Filter Table. Else set the lifetime to be MAX_SAC_LIFETIME. Whenever a NS with target address set to one of the addresses with state SAC_BOUND, the state of the entry is set to SAC_QUERY, and the lifetime is set to MAX_DAD_PREPARE_DELAY. If there is no response Expires February 29, 2010 [Page 9] =0C Internet-Draft Control Packet Snooping Based Binding August 2009 from the host before the lifetime expires, delete the entry in BST and Filter Table. If a response is received from the host, set the lifetime of the corresponding entry to be MAX_SAC_LIFETIME. 10.1.1.2. State Machine of ND Snooping State Packet/Event Action Next State Start DAD NS Set up new entry SAC_START SAC_START Timeout Insert into FT SAC_BOUND SAC_START DAD NA RLY Remove entry Start 10.1.2. Gratuitous ARP Snooping 10.1.2.1. Process of Gratuitous ARP Snooping This process is designed for manually configured IPv4 address. = If manually configured IPv4 address is used in the network, this procedure MUST be performed. Whenever a gratuitous ARP is received from the host, if the address is not in BST and has a permitted prefix, generate a new entry in BST and set the state of the entry to be MANUALv4_START. The lifetime of the entry is set to be MAX_ARP_DELAY. If an ARP response for the address is received from other nodes, delete the entry. If the lifetime expires, set the state of the entry to be MANUALv4_BOUND. The lifetime of this entry is set to MAX_MANUAL_LIFETIME. An entry is added into the Filter Table. If the lifetime of an entry with state MANUALv4_BOUND expires, set the lifetime to be MAX_ARP_PREPARE_DELAY and send an ARP request for the address. If there is no response before the lifetime expires, delete the entry in BST and Filter Table. Else set the lifetime to be MAX_MANUAL_LIFETIME. Whenever an ARP response with target address set to one of the addresses with state ARP_BOUND, the state of the entry is set to MANUALv4_QUERY, and the lifetime is set to MAX_ARP_PREPARE_DELAY. If there is no response from the host before the lifetime expires, delete the entry in BST and Filter Table. If a response is received from the host, set the lifetime of the corresponding entry to be MAX_MANUAL_LIFETIME. Expires February 29, 2010 [Page 10] =0C Internet-Draft Control Packet Snooping Based Binding August 2009 10.1.2.2. State Machine of Gratuitous ARP Snooping State Packet/Event Action Next State Start Gra ARP REQ Set up new entry MANUALv4_START MANUALv4_START Timeout Insert into FT MANUALv4_BOUND MANUALv4_START Gra ARP RLY Remove entry = Start 10.2. Probe Trigger This section specifies how to set up bindings through sending probe packets. This kind of procedure is triggered by either control or data packet not matching current bindings in the Filtering Table. The procedures and state machines are much the same as the procedures described in section [10.1], except that the first DAD NS/Gratuitous ARP request is sent by the switch, not host itself. 10.2.1. NDP/ARP Triggered DAD Probe and Binding If SLAAC or manually configured IPv4 address is used, this procedure MUST be performed. This procedure performs snooping on unsolicited NA, NS and ARP Request, checks whether their source addresses are in reasonable scope, and send DAD or ARP probes for these source addresses. If there is no response for the probes from other ports, it will insert the corresponding binding into the Binding State Table and Filtering Table. The reasonableness of this procedure is relying on the fact that before sending data packet to a destination, the host will perform the resolve from layer 3 address to layer 2 address. Using these packets to trigger duplicate detection can eliminate (or reduce) the risk of DAD loss, and handle incompatible operating systems. 10.2.2. Data Packet Triggered DAD Probe and Bindings This procedure SHOULD be performed on SAVI-Host port. In this procedure, whenever the source address of a data packet isn't in the filtering table, the switch will send DAD/ARP probes to check whether this address is duplicated. If there is no response Expires February 29, 2010 [Page 11] =0C Internet-Draft Control Packet Snooping Based Binding August 2009 from other ports (or anchors), a binding will be inserted into the Binging State Table and Filtering Table. In this procedure, the rate of data packets to trigger binding is limited. This optional procedure is the most robust in some extreme situation. However, the overhead is relative high. 10.3. Other Considerations on Binding Setup If all the hosts in the link are complying with RFC4862 and RFC5227, and the DAD retransmit number is set to be no less than 2, actually basic binding is enough to handle all the situations(except for some extreme situations). The trigger of DAD probe has heavier cost than procedures without sending DAD probe. It is SUGGESTED to enforce this configuration instead of using probe trigger procedure. 10.4. Upper Bound and Minimum of Binding Number To avoid the storage of binding state table and filtering table exhausted by some malicious node, the upper bound binding number on a port MUST be set. And to avoid a host cannot possess enough binding entries, the minimum binding number of a port MUST also be set. 11. Clear Binding This section specifies when and how to clear bindings. Two modes can be used here: clear-on-query and clear-on-demand. 11.1. Clear-on-Query mode In this mode, the switch will send a NS or NUD or ARP request to detect whether a binding address is still in use every MAXIMUM_LIFETIME. If there is no response from the corresponding node, this binding MUST be deleted; or else, set to lifetime of this entry to be MAXIMUM_LIFETIME. Whenever a node is disconnected at link layer, the corresponding bindings in BST and Filtering Table will be remain for a FLAPPY_TIME. Expires February 29, 2010 [Page 12] =0C Internet-Draft Control Packet Snooping Based Binding August 2009 11.2. Clear-on-Demand mode In this mode, the switch would send any probe to detect whether an address is still in use; instead, it will perform snooping on NS/NUD/ARP request for the binding addresses, and decide whether to delete the corresponding entry. 12. Filtering Specification This section specifies how to use bindings to filtering packets on port with SAVI-Host attribute. Filtering will not be performed on port with SAVI-SAVI. The filtering on SAVI-UCA has not been defined yet. 12.1. Filter Data Packet In a switch scenario, if data packet is not enabled to trigger DAD probe, filtering on port with SAVI-Host attribute strictly complies with the Filtering Table set up on the port. If the source of the packet is in the binding table of the port, this packet will be forwarded; or else the packet MUST be discarded. In a switch scenario in which data packet is enabled to trigger DAD probe, if the source of the packet is in the binding table of the port, this packet will be forwarded; or else the packet will trigger the switch to perform data packet triggered DAD procedure. In a wireless scenario, all the filtering MUST be strictly complying with Filtering Table; or if optional procedure 3 is chosen, packet not match any binding will be process by that procedure. 12.2. Filter Control Packet The source address of the control packet is always all zero (IPv6 Stateless auto-configuration for link-local address) or unbound address (gratuitous ARP). Such packets don't have to pass the check on Filter Table. However, the source address of IPv6 DAD NS for global address must pass the check on Filter Table, for always a unique link-local address is used. All Router Advertisement packets MUST be from port with SAVI-RA- Trust attribute. Expires February 29, 2010 [Page 13] =0C Internet-Draft Control Packet Snooping Based Binding August 2009 The target address in all the Neighbor Advertisement packets and the sender's address in all ARP relies should also pass the checks on Filter Table. The Target address in Neighbor Advertisement packet MUST be in the corresponding prefix scope. If any check fails, the control packet triggered DAD probe procedure will be performed by switch. 13. Solution for Special Situations Two situations described in the charter of SAVI working group may cause this mechanism filter packets improperly: multiple interfaces and port movement. The following is the proper solution for each situation. 13.1. Multiple Interfaces If a host has multiple interfaces to the same LAN, generally this situation can be treated as multiple hosts with single interface because each interface will only use the address assigned to itself as source IP address. However, a host may configure the same address on multiple interfaces for the purpose of load balance. In this situation, the SAVI device may find an address bound with an anchor appears with another anchor, just as spoofing. This is the only multiple interfaces situation that troubles this mechanism. When this situation happens, the corresponding binding is seldom changed. Thus, manual configuration is enough for this situation. All the anchors with the host can be configured to be used by the same host and share the same entries in BST and Filtering Table. Other mechanisms can also be used to handle this situation, such as [SAVI-SeND] and [SAVI-HIP]. These mechanisms can be used to test whether two anchors are belonging to the same host and thus distinguish multiple interfaces from spoofing. However, all the mentioned mechanisms bring overhead to data packet process, and are not recommended. Currently, the only recommended mechanism is manual configuration. However, for the consideration that in the future, a host with multiple interfaces to the same network may become very common (for example, a host has a wired network interface and a wireless network interface attached to the same network, and they are configured to use the same address), an extension mechanism is still needed. The Expires February 29, 2010 [Page 14] =0C Internet-Draft Control Packet Snooping Based Binding August 2009 design of such mechanism is temporarily out of the scope of this document. 13.2. Port Movement For a stateless address, a duplicate detection must be performed when the interface is re-initialized, just as the process of address assignment. However, if an interface configured a static address changes port, because the corresponding is manually configured, this movement will conflict previous binding. The situation that a host with static address changes from one port to another can be handled through one of the following ways: - Manual configuration. If the host configured with static address seldom changes its port, the administrator can manually change the binding after each movement. - Changing anchor. If the anchor is not switch port, port movement will not cause any trouble. Thus an alternate way is choosing another entity as anchor, for example, the secure MAC address. - Access control mechanisms based on user account. Static address is always associated with specified user, thus the access control mechanism based on user account can be used to handle frequent port movements. 802.1x, PPPoE, and Portal are optional mechanisms. Whenever the user account is authenticated by there mechanisms, the corresponding address can be bound on the switch. The related protocol must be extended to enable such function. - Host identifier related mechanisms. [SAVI-SeND] and [SAVI-HIP] have a secure host identifier associated with the host, and this identifier can be used to handle port movement. The problem of such solutions is that they are based on immature techniques. 14. Considerations on Security Risks There is no security consideration currently. 14.1. Operating system support The duplicate detection for IPv4 address has been prescribed in [RFC5227], but currently not all the operating systems perform duplicate detection on IPv4 address. Because the number of available IPv4 addresses in a LAN is small, a simplest solution is that whenever a new IPv4 address appears, the deployed device can perform duplicate detection instead of the host. However, this function will Expires February 29, 2010 [Page 15] =0C Internet-Draft Control Packet Snooping Based Binding August 2009 take data packet into control panel and would bring additional cost. A suggestion for the network administrator is IPv4 address should be assigned through DHCP or static. The supported operating systems are listed in Appendix A. For the operating system that cannot be updated, it is suggested to only use static address and set up binding manually, or only DHCPv4 is allowed to assign address. The duplicate detection for IPv6 address has been prescribed in [RFC4862]. However, some operating systems not supporting IPv6 well will not perform DAD when assigning IPv6 address. It is suggested that the operating systems should be able to update to support [RFC5227] and [RFC4862]. For the operating system that cannot be updated, it is suggested to only use static address and set up binding manually, or only DHCPv6 is allowed to assign address. An optional mode, named Compatible Mode, is designed to handle these situations. 14.2. Malicious replier Another risk is that the detection packet can be replied by a malicious attacker, and the host will be prevented from getting a proper address. This problem cannot be easily handled for it is caused by non-deployed nodes. The deployed device must filter Neighbor Advertisement packets, not only by source address, but also by target address. The sender's address in ARP replies should also be checked. A practical solution for this problem is as follows: 1. Divide the address space of SAVI nodes and non-SAVI nodes; 2. Partition SAVI nodes and non-SAVI nodes to different VLANs. Then the SAVI nodes don't have to ask the non-SAVI nodes whether an address has been used by some of them. 14.3. Inactive node The false negative may be caused by the situation that the detection packet is not replied by the assigned node. This is a troublesome situation. It is reasonable for a node to get such address because it is in accordance with the standard, unless the address is a static address. A simple process is removing the previous binding and setting up new binding for the requesting node. A more tolerant Expires February 29, 2010 [Page 16] =0C Internet-Draft Control Packet Snooping Based Binding August 2009 process is the SAVI device can perform ARP/ND proxy for the inactive node, and reduce the lifetime of binding to 1/4. 15. Incremental Deployment Suggestion Because by default this mechanism doesn't set up bindings on trunk port, it may happen that a host connected to a downstream non-SAVI device can forge an address bound in SAVI area. To avoid this situation, it is suggested to separate SAVI area and non-SAVI areas into different VLANs, and assign different prefixes in these VLANs. Then the spoofing from non-SAVI area can be blocked through prefix check. And another way is to set the trunk ports to have SAVI-TRUNK- Snooping attribute. Then bindings can be set up on trunk port, and the bindings can be used to prevent spoofing from another trunk port. Because of the cost of this solution, it's better to carefully choose the trunk ports to be set this attribute. 16. Constants MAX_ARP_PREPARE_DELAY 1s MAX_ARP_DELAY 1s MAX_DAD_PREPARE_DELAY 1s MAX_DAD_DELAY 1s MAX_LIFETIME 2h MAX_MANUAL_LIFETIME 4h 17. Security Considerations There are no security considerations currently. 18. IANA Considerations There is no IANA consideration currently. Expires February 29, 2010 [Page 17] =0C Internet-Draft Control Packet Snooping Based Binding August 2009 19. References 19.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless Autoconfiguration", RFC4862, September, 2007. [RFC5227] S. Cheshire, "IPv4 Address Conflict Detection", RFC5227, July 2008. [SAVI-SeND] M. Bagnulo, draft-ietf-savi-send-00.txt. [SAVI-HIP] D. Kuptsov, A. Gurtov and J. Bi, draft-kuptsov-sava-hip- 01.txt. 19.2. Informative References 20. Acknowledgments Expires February 29, 2010 [Page 18] =0C Internet-Draft Control Packet Snooping Based Binding August 2009 Authors' Addresses Expires February 29, 2010 [Page 19] =0C ------=_NextPart_000_0470_01CA598E.AD80D4D0 Content-Type: text/plain; name="draft-ietf-savi-fcfs-02.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-savi-fcfs-02.txt" Network Working Group E. Nordmark Internet-Draft Sun Intended status: Standards Track M. Bagnulo Expires: April 29, 2010 UC3M E. Levy-Abegnoli Cisco Systems October 26, 2009 FCFS-SAVI: First-Come First-Serve Source-Address Validation for Locally Assigned Addresses draft-ietf-savi-fcfs-02 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 29, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Nordmark, et al. Expires April 29, 2010 [Page 1] =0C Internet-Draft FCFS SAVI October 2009 Abstract This memo describes FCFS SAVI a mechanism to provide source address validation for IPv6 networks using the First-Come First-Serve approach. The proposed mechanism is intended to complement ingress filtering techniques to provide a higher granularity on the control of the source addresses used. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Design considerations . . . . . . . . . . . . . . . . . . . . 3 2.1. Scope of FCFS SAVI . . . . . . . . . . . . . . . . . . . . 3 2.2. Constraints for FCFS SAVI . . . . . . . . . . . . . . . . 4 2.3. Address ownership proof . . . . . . . . . . . . . . . . . 4 2.4. Layer-2 Anchor considerations . . . . . . . . . . . . . . 5 2.5. Special cases . . . . . . . . . . . . . . . . . . . . . . 5 3. SAVI topology and port configuration . . . . . . . . . . . . . 5 3.1. SAVI enforcement perimeter . . . . . . . . . . . . . . . . 6 3.2. SAVI port configuration guidelines . . . . . . . . . . . . 9 3.3. VLAN support . . . . . . . . . . . . . . . . . . . . . . . 10 4. FCFS SAVI specification . . . . . . . . . . . . . . . . . . . 10 4.1. FCFS SAVI Data structures . . . . . . . . . . . . . . . . 10 4.2. FCFS SAVI algorithm . . . . . . . . . . . . . . . . . . . 10 4.2.1. Processing of transit traffic . . . . . . . . . . . . 10 4.2.2. Processing of local traffic. . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 8. Normative References . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Nordmark, et al. Expires April 29, 2010 [Page 2] =0C Internet-Draft FCFS SAVI October 2009 1. Introduction This memo describes FCFS SAVI, a mechanism to provide source address validation for IPv6 networks using the First-Come First-Serve approach. The proposed mechanism is intended to complement ingress filtering techniques to provide a higher granularity on the control of the source addresses used. 2. Design considerations 2.1. Scope of FCFS SAVI The application scenario for FCFS SAVI is limited to the local-link. This means that the goal of FCFS SAVI is verify that the source address of the packets generated by the hosts attached to the local link have not been spoofed. In any link there usually are hosts and routers attached. Hosts generate packets with their own address as the source address. This is the so-called local traffic. while routers send packets containing a source address other than their own, since they are forwarding packets generated by other hosts (usually located in a different link). This what the so-called transit traffic. The applicability of FCFS SAVI is limited to the local traffic i.e. to verify if the traffic generated by the hosts attached to the local link contains a valid source address. The verification of the source address of the transit traffic is out of the scope of FCFS SAVI. Other techniques, like ingress filtering [RFC2827], are recommended to validate transit traffic. In that sense, FCFS SAVI complements ingress filtering, since it relies on ingress filtering to validate transit traffic but is provides validation of local traffic, which is not provided by ingress filtering. Hence, the security level is increased by using these two techniques. In addition, FCFS SAVI is designed to be used with locally assigned addresses, in particular with address configured through stateless address autoconfiguration [RFC4862]. Manually configured addresses can be supported by FCFS SAVI, but manual configuration of the binding on the SAVI device provides higher security and seems compatible with manual address management. Additional considerations about how to use FCFS SAVI depending on the type of address management used and the nature of the addresses is discussed in the framework document (add reference when available). Nordmark, et al. Expires April 29, 2010 [Page 3] =0C Internet-Draft FCFS SAVI October 2009 2.2. Constraints for FCFS SAVI FCFS SAVI is designed to be deployed in existing networks requiring a minimum set of changes. For that reason, FCFS SAVI does not require any changes in the hosts which source address is to be verified. Any verification must solely rely in the usage of already available protocols. This means that FCFS SAVI cannot define a new protocol nor define any new message on existing protocols nor require that a host uses an existent protocol message in a different way. In other words, the requirement is no host changes. FCFS SAVI validation is performed by the FSFC SAVI function. Such function can be placed in different type of devices, including a router or a layer-2 bridge. The basic idea is that the FCFS SAVI function is located in the points of the topology that can enforce the correct usage of source address by dropping the non-compliant packets. 2.3. Address ownership proof The main function performed by FCFS SAVI is to verify that the source address used in data packets actually belongs to the originator of the packet. Since FCFS SAVI scope is limited to the local link, the originator of the packet is attached to the local link. In order to define any source address validation solution, we need to define some address ownership proof concept i.e. what it means to be able to proof that a given host owns a given address in the sense that the host is entitled to send packet with that source address. Since no host changes are acceptable, we need to find the means to proof address ownership without requiring a new protocol. In FCFS SAVI the address ownership proof is based in the First-Come first Serve approach. This means that the first host that claims a given source address is the owner of the address until further notice. More precisely, whenever a source address is used for the first time, a state is created in the device that is performing the FCFS SAVI function binding the source address to the layer-2 information that the FCFS SAVI box has available (e.g. the port in a switched LAN). Following data packets containing that IP source address must use the same layer-2 information in order to be compliant. There are however additional considerations to be taken into account. For instance, consider the case of a host that moves from one segment of a LAN to another segment of the same subnetwork and it keeps the same IP address. In this case, the host is still the owner of the IP address, but the associated layer-2 information has changed. In order to cope with this case, the defined FCFS SAVI behaviour implies the verification whether the host is still reachable using the Nordmark, et al. Expires April 29, 2010 [Page 4] =0C Internet-Draft FCFS SAVI October 2009 previous layer-2 information. In order to do that FCFS SAVI uses ND protocol. If the host is no longer reachable at the previously recorded layer-2 information, FCFS SAVI assumes that the new location is valid and creates a new binding using the new layer-2 information. In case the host is still reachable using the previously recorded information, the packets coming from the new layer-2 information are dropped. Note that this only applies to local traffic. Transit traffic generated by a router would be verified using alternative techniques, such as ingress filtering. SAVI checks would not be fulfilled by the transit traffic, since the router is not the owner of the source address contained in the packets. 2.4. Layer-2 Anchor considerations Any SAVI solution is not stronger than the Layer-2 anchor it uses. If the Layer-2 anchor is easily spoofable (e.g. a MAC address), then the resulting solution will be weak. The treatment of non-compliant packets needs to be tuned accordingly. In particular, if the Layer-2 anchor is easily spoofable and the SAVI device is configured to drop no compliant packets, then the usage of SAVI may open a new vector of Denial of Service attacks, based on spoofed Layer-2 anchors. For that reason, in this document, we assume that the Layer-2 anchors used by the SAVI solution are not easily spoofable (e.g. ports of a switched network) and that the SAVI device MAY be configured to drop non- compliant packets. If the SAVI solution proposed in this document is to be used with weaker Layer-2 anchors (such as MAC addresses), logging is RECOMMENDED instead of dropping non-compliant packets. For the rest of the document, we will assume that the Layer-2 anchors are ports of a switched network. 2.5. Special cases The following special cases that need to be considered o Hosts with multiple physical interfaces connected to the same link. o Anycast i.e. multiple hosts using the same source address to send packets. o Proxy ND i.e. host sending packets on behalf of other, in a layer-3 transparent manner. 3. SAVI topology and port configuration Nordmark, et al. Expires April 29, 2010 [Page 5] =0C Internet-Draft FCFS SAVI October 2009 3.1. SAVI enforcement perimeter SAVI provides perimetrical security. This means that the SAVI devices form what can be called a SAVI enforcement perimeter and they verify that any packet that crosses the perimeter is compliant (i.e. the source address related information is validated). Once the packet is inside the perimeter, no further validations are performed to the packet. This model has implications both on how SAVI devices are deployed in the topology and on the configuration of the SAVI boxes. The implication of this perimetrical security approach, is that there is part of the topology that is inside the perimeter and part of the topology that is outside the perimeter. This means that while packets coming from interfaces connected to the external part of the topology need to be validated by the SAVI device, packets coming from interfaces connected to the the internal part of the topology do not need to be validated. This significantly reduces the processing requirements of the SAVI device. It also implies that each SAVI device that is part of the perimeter, must be able to verify the source addresses of the packets coming from the interfaces connected to the external part of the perimeter. In order to do so, the SAVI device binds the source address to a layer-2 anchor. One possible approach would be for every SAVI device to store binding information about every source addresses in the subnetwork This means that every SAVI device would store binding for each source address to the local layer-2 anchor through packets with that source address can be received through. The problem with this approach is that it imposes significant memory burden on the SAVI devices. In order to reduce the memory requirements imposed to each device, the SAVI solution described in this specification distributes the storage of SAVI binding information among the multiple SAVI devices of a subnetwork. The SAVI binding state is distributed across the SAVI devices according to the following criteria: each SAVI device will store binding information about the source addresses bound to layer-2 anchors corresponding to the interfaces that connect to the part of the topology that is outside of the SAVI enforcement perimeter. Since all the untrusted packet sources are by definition in the external part of the perimeter, this means that the packets generated by each of the untrusted sources will reach the perimeter through one interface of a SAVI device. The binding information for that particular source address will be stored in this first SAVI device the packet reaches to. This means the SAVI binding information will be distributed across multiple devices. In order to provide proper source address validation, it is critical that the information distributed among the Nordmark, et al. Expires April 29, 2010 [Page 6] =0C Internet-Draft FCFS SAVI October 2009 different SAVI devices is coherent. In particular, it is important to avoid that the same source address is bound to different layer-2 anchors in different SAVI devices. Should that occur, then it would mean that two hosts are allowed to send packets with the same source address, which is what we are trying to prevent. In order to preserve the coherency of the SAVI bindings distributed among the SAVI devices within a realm, the Neighbour Discovery (ND) protocol is used, in particular the Neighbour Solicitation (NSOL) and Neighbour Advertisement (NADV) messages. Before creating a SAVI binding in the local SAVI database, the SAVI device will send a NSOL message querying for the address involved. Should any host reply to that message with a NADV message, the SAVI device that sent the NADV will infer that a binding for that address exists in another SAVI device and will not create a local binding for it. If no NADV message is received as a reply to the NSOL, then the local SAVI device will infer that no binding for that address exists in other SAVI device and will create the local SAVI binding for that address. (NOTE that the description included here is overly simplified to illustrate the mechanism used to preserve the coherency of the binding databases of the different SAVI devices. The actual SAVI mechanism as described below varies in the fact that in some cases it is the SAVI device that generates the NSOL while in other cases it simply forwards the NSOL generated by the end host, and that the SAVI device will send multiple copies of the NSOL in order to improve the reliability of the message exchange). So, summarizing, the proposed SAVI approach relies on the following design choices: o SAVI provides perimetrical security, so some interfaces of a SAVI device will connect to the internal (trusted) part of the topology and other interfaces will connect to the external (untrusted) part of the topology. o A SAVI device only verifies packets coming though one interface connected to the untrusted part of the topology. o A SAVI device only stores binding information for the source addresses that are bound to layer-2 anchors that correspond to interfaces that connect to the untrusted part of the topology. o SAVI uses the NSOL and NADV messages to preserve the coherency of the SAVI binding state distributed among the SAVI devices within a realm. So, in a link that is constituted of multiple L2 devices, some of which are SAVI capable and some of which are not, the SAVI capable devices SHOULD be deployed forming a connected perimeter (i.e. that no data packet can get inside the perimeter without passing through a SAVI device). Packets that cross the perimeter will be validated while packets that do no cross the perimeter are not validated (hence SAVI protection is not provided for these packets). Consider the Nordmark, et al. Expires April 29, 2010 [Page 7] =0C Internet-Draft FCFS SAVI October 2009 deployment of SAVI in the topology depicted in the following picture: +--+ +--+ +--+ +--+ |H1| |H2| |H3| |R1| +--+ +--+ +--+ +--+ | | | | +-------------SAVI-ENFORCEMENT-PERIMETER--------------+ | | | | | | | +-1-----2-+ +-1-----2-+ | | | SAVI1 | | SAVI2 | | | +-3--4----+ +--3------+ | | | | +--------------+ | | | | +----------| |--------+ | | | | SWITCH-A | | | | +----------| |--------+ | | | | +--------------+ | | | +-1--2----+ +--1------+ | | | SAVI3 | | SAVI4 | | | +-3---4---+ +----4----+ | | | | | | +-------------SAVI-ENFORCEMENT-PERIMETER--------------+ | | | +--+ +--+ +---------+ |R2| |H4| |SWICTH-B | +--+ +--+ +---------+ | | +--+ +--+ |H5| |H6| +--+ +--+ In the figure above, the SAVI enforcement perimeter is provided by 4 SAVI devices, namely SAVI1, SAVI2, SAVI3 and SAVI4. These devices verify information related to the source address both in data and in ND packets and filter packets accordingly. SAVI devices then have two types of ports: trusted ports and validating ports. o Validating ports (VPs) are those in which SAVI processing is performed. This means that when a packet is received through one of the validating ports, the SAVI processing and filtering will be executed. o Trusted ports (TPs) are those in which SAVI processing is not performed. So, packets received through trusted ports are not validated and no SAVI processing is performed in them. Trusted ports are used for connections with trusted infrastructure, including the communication between SAVI devices, the communication Nordmark, et al. Expires April 29, 2010 [Page 8] =0C Internet-Draft FCFS SAVI October 2009 with routers and the communication of other switches that while they are not SAVI devices, they only connect to trusted infrastructure (i.e. other SAVI devices, routers or other trusted nodes). So, in the figure above, Port 3 of SAVI1 and port 1 of SAVI3 are trusted because the connect two SAVI devices. Port 4 of SAVI1, port 3 of SAVI2, port 2 of SAVI3 and port 1 of SAVI4 are trusted because the connect to SWITCH-A to which only trusted nodes are connected. In the figure above, port 2 of SAVI2 and port 3 of SAVI3 are trusted ports because they connect to routers. Validating ports are used for connection with non-trusted infrastructure. In particular, hosts are normally connected to validating ports. Non-SAVI switches that are outside of the SAVI enforcement perimeter also are connected through validating port. In particular, non-SAVI devices that connect directly to hosts or that have no SAVI capable device between themselves and the hosts are connected through a validating port. So, in the figure above, ports 1 and 2 of SAVI1, port 1 of SAVI2, port 4 of SAVI 3 are validating ports because they connect to hosts. Port 4 of SAVI4 is also a validating port because it is connected to SWITCH-B which is a non- SAVI capable switch which is connected to hosts H5 and H6. 3.2. SAVI port configuration guidelines The guidelines for port configuration in SAVI devices are: o Ports that are connected to another SAVI device SHOULD be configured as Trusted ports. Not doing so will at least significantly increase the memory consumption in the SAVI devices. o Ports connected to hosts SHOULD be configured as Validating ports. Not doing so will allow the host connected to that port to send packets with spoofed source address. o Ports connected to routers SHOULD be configured as Trusted ports. Configuring them as Validating ports would increase the signaling due to SAVI. The implication is that a router can generate traffic with any source address as they are assumed to be part of the trusted infrastructure. o Ports connected to a chain of one or more legacy switches that have hosts connected SHOULD be configured as Validating ports. Not doing so will allow the host connected to any of these switches to send packets with spoofed source address. o Ports connected to a chain of one or more legacy switches that have other SAVI devices and/or routers connected but had no hosts attached to them SHOULD be configured as Trusted ports. Not doing so will at least significantly increase the memory consumption in the SAVI devices and increase the signaling traffic due to SAVI validation. Nordmark, et al. Expires April 29, 2010 [Page 9] =0C Internet-Draft FCFS SAVI October 2009 o Ports connected to a chain of one or more legacy switches that have a mix of SAVI devices and/or routers with hosts, SHOULD be configured as Validating ports. Not doing so will allow the host connected to that port to send packets with spoofed source address. Nevertheless, this topology will result in increased SAVI signaling and memory consumption compared to a topology where SAVI-hosts communications and inter SAVI communications are kept through different legacy switches. 3.3. VLAN support In the case the SAVI device is a switch that supports VLANs, the SAVI implementation will behave as if there was one SAVI process per VLAN. The SAVI process of each VLAN will store the binding information corresponding the the nodes attached to that particular VLAN. 4. FCFS SAVI specification 4.1. FCFS SAVI Data structures FCFS SAVI function relies on state information binding the source address used in data packets to the layer-2 information that contained the first packet that used that source IP address. Such information is stored in FCFS SAVI Data Base (DB). The FCFS SAVI DB will contain a set of entries about the currently used IP source addresses. So each entry will contain the following information: o IP source address o Layer-2 information, such as Layer-2 address, port through which the packet was received, etc o Lifetime o Status:either tentative or valid o Creation time: the value of the local clock when the entry was firstly created In addition to this, FCFS SAVI need to know what are the prefixes that are directly connected, so it maintains a data structure called the the FCFS SAVI prefix list, which contains: o Prefix o Interface where prefix is directly connected 4.2. FCFS SAVI algorithm 4.2.1. Processing of transit traffic The FCFS SAVI function is located in a forwarding device, such as a router or a layer-2 bridge. The following processing is performed depending on the type of port the packet has been received through: Nordmark, et al. Expires April 29, 2010 [Page 10] =0C Internet-Draft FCFS SAVI October 2009 o If the data packet is received through a Trusted port, the data packet is forwarded and no SAVI processing performed to the packet. o If the data packet is received through a Validating port, then the SAVI function checks whether the received data packet is local traffic or transit traffic. It does so by verifying if the source address of the packet belongs to one of the directly connected prefixes available in the receiving interface. It does so by searching the FCFS SAVI Prefix List. * If the IP source address does not belong to one of the local prefixes of the receiving interface, this means that the dat packet is transit traffic and the packet SHOULD be discarded. The FCFS SAVI function MAY send an ICMP Destination Unreachable Error back to the source address of the data packet. (ICMPv6, code 5 (Source address failed ingress/egress policy) should be used). * If the source address of the packet does belong to one of the prefixes available in the the receiving port, then the SAVI local traffic validation processes is executed as described below. 4.2.2. Processing of local traffic. We describe next how the local traffic, including both control and data packets are processed by the SAVI device using a state machine approach. The state machine described is for the binding of a given source IP address in a given SAVI device. So this means that all the packets described as inputs in the state machine above refer to that given IP address. The key attribute is the IP address. The full state information is: o IP ADDRESS: IPAddr o LAYER_2 ANCHOR: P o LIFETIME: LT The possible states are: o NO_BIND o TENTATIVE o VALID o TESTING_TP o TESTING_VP o TESTING_LIFETIME We will use VP for Validating Port and TP for Trusted Port. After bootstrapping (when no binding exists), the state for all source IP address is NO-BIND i.e. there is no binding for the IP Nordmark, et al. Expires April 29, 2010 [Page 11] =0C Internet-Draft FCFS SAVI October 2009 address to any Layer-2 anchor. NO_BIND: The binding for a source IP address entry is in this state when it does not have any binding to a Layer 2 anchor. All addresses are in this state by default after bootstrapping, unless bindings were created for it. TENTATIVE: The binding for a source address is in this state during the waiting period during which the DAD procedure is being executed (either directly by the host itself or by the SAVI device on its behalf). VALID: The binding for the source address has been verified, it is valid and usable for filtering traffic. TESTING_TP: A binding for a source address enters in this sate when a DAD_NSOL has been received through a Trusted port. this implies that another host is performing the DAD procedure for that source address in another switch. this may due to an attack or to the fact that the host may have moved. The binding in this state is then being tested to determine which is the situation. TESTING_TP: A binding for a source address enters in this sate when a DAD_NSOL or a data packet has been received through a Validating port. this implies that another host is performing the DAD procedure for that source address in another switch. this may due to an attack or to the fact that the host may have moved. The binding in this state is then being tested to determine which is the situation. TESTING_LIFETIME: A binding for a source address is in this state cause the lifetime of the entry is about to expire. this is due to the fact that no packets has been seen by the SAVI device for the LIFETIME period. this may be due to the host simply being silent or because the host has left the location. In order to determine which is the case, a test is performed, in order to determine if the binding information should be discarded. We describe next how the different inputs are processed depending on the state of the binding of the IP address. A simplified figure of the state machine can be found at http://www.it.uc3m.es/~marcelo/SAVI_state_machine.pdf NO_BIND o Upon the reception through a Validating Port (VP) of a Neighbour Solicitation (NSOL) generated by the Duplicate Address Detection (DAD) procedure (hereafter named DAD_NSOL) containing Target Nordmark, et al. Expires April 29, 2010 [Page 12] =0C Internet-Draft FCFS SAVI October 2009 Address IPAddr, or after the reception of a DATA packet containing IPAddr as the source address, the SAVI device will execute the process of sending Neighbour Solicitation (NSOL) messages of the Duplicate Address Detection process as described in section 5.4.2 of [RFC4862] for the IPAddr using the following default parameters: DupAddrDetectTransmits set to 2 (i.e. 2 Neighbour Solicitation messages for that address will be sent by the SAVI device) and RetransTimer set to 500 milliseconds (i.e. the time between two Neighbour Solicitation messages is 500 millisecs and also the wait time for replies in the form of Neighbour Advertisement for the queried address). The NSOL messages are not sent through any of the ports configured as Validating Ports. The NSOL messages are sent through the proper Trusted Ports (as defined by the switch behaviour that will depend on whether it performs MLD snooping or not) The SAVI device MAY discard the data packet while the DAD procedure is being executed. * EDITOR NOTE: We need to rate limit the emission of NSOL of the SAVI device as a whole. * EDITOR NOTE 2: should we send the NSOL through the port the packet was received through? The state is moved to TENTATIVE. The LIFETIME is set to TENT_LT (i.e. LT=3D=3DTENT_LT) and the LAYER_2 ANCHOR is set to VP (i.e. P=3D=3DVP) o Data packets containing IPAddr as the source address received through Trusted ports are processed and forwarded as usual (i.e. no special SAVI processing) o DAD_NSOL packets containing IPAddr as the target address received through a Trusted port are NOT forwarded through any of the Validating ports but they are sent through the proper Trusted Ports (as defined by the switch behaviour that will depend on whether it performs MLD snooping or not) o Neighbor Advertisement packets sent to all nodes as a reply to the DAD_NSOL (hereafter called DAD_NADV) containing IPAddr as the target address coming through a Validating port are discarded. o Other signaling packets are processed and forwarded as usual (i.e. no SAVI processing) TENTATIVE o If the LIFETIME times out, the state is moved to VALID. The LIFETIME is set to DEFAULT_LT (i.e. LT=3D=3D DEFAULT_LT). Stored data packets are forwarded (if any). o If a Neighbour Advertisement (NADV) is received through a Trusted Port with Target Address set to IPAddr, then state is set to NO_BIND and the LAYER_2 ANCHOR and the LIFETIME are cleared. Data packets stored corresponding to this binding are discarded. Nordmark, et al. Expires April 29, 2010 [Page 13] =0C Internet-Draft FCFS SAVI October 2009 o If a NADV is received through a Validating Port with Target Address set to IPAddr, the NADV packet is discarded o If a data packet with source address IPAddr is received with Layer_2 anchor equal to P, then the packet is either stored or discarded. * EDITOR NOTE: we need to define a maximum storage space for the data packets. Having a single default value may be hard since it will heavily depend on the capability of the device. Maybe it would be enough that the device has a maximum and that the value can be configured? o If a data packet with source address IPAddr is received through a Trusted port, the data packet is forwarded. the state is unchanged. ( waiting for the NADV?) o If a data packet with source address IPAddr is received through a Validating port other than P, the data packet is discarded. o Other signaling packets are processed and forwarded as usual (i.e. no SAVI processing) * EDITOR NOTE: this may need more thought VALID o If a data packet containing IPAddr as a source address arrives from Validating port P, then the LIFETIME is set to DEFAULT_LT and the packet is forwarded as usual. * EDITOR NOTE: Is this feasible? i.e. to reset a timer each time a data packet arrives? We could just have a long lifetime and actively check for the host when the lifetime is about to expire. o If a DAD_NSOL is received from a Trusted port, then the DAD_NSOL message is forwarded to port P and it is also forwarded to the proper Trusted Ports (as defined by the switch behaviour that will depend on whether it performs MLD snooping or not). The state is changed to TESTING_TP. The LIFETIME is set to TENT_LT. o If a data packet containing source address IPAddr or a DAD_NSOL packet with target address set to IPAddr is received through a Validating port P' other than P, then the SAVI device will execute the process of sending DAD_NSOL messages as described in section 5.4.2 of [RFC4862] for the IPAddr using the following default parameters: DupAddrDetectTransmits set to 2 (i.e. 2 NSOL messages for that address will be sent by the SAVI device) and RetransTimer set to 500 milliseconds (i.e. the time between two NSOL messages is 500 millisecs and also the wait time for replies in the form of Neighbour Advertisement for the queried address). The DAD_NSOL message will be forwarded to the port P. * EDITOR NOTE: should we also forward it though the TP? Theoretically, there shouldn't be another binding in any other SAVI device, so there should not be a need for this. The state is moved to TESTING_VP. The LIFETIME is set to TENT_LT. Nordmark, et al. Expires April 29, 2010 [Page 14] =0C Internet-Draft FCFS SAVI October 2009 The SAVI device MAY discard the data packet while the DAD procedure is being executed. o If the LIFETIME expires, then the SAVI device will execute the process of sending DAD_NSOL messages as described in section 5.4.2 of [RFC4862] for the IPAddr using the following default parameters: DupAddrDetectTransmits set to 2 (i.e. 2 NSOL messages for that address will be sent by the SAVI device) and RetransTimer set to 500 milliseconds (i.e. the time between two NSOL messages is 500 millisecs and also the wait time for replies in the form of Neighbour Advertisement for the queried address). The DAD_NSOL messages will be forwarded to the port P. The state is changed to TESTING_LIFETIME and the LIFETIME is set to TENT_LT. o If a data packet containing IPAddr as a source address arrives from Trusted port, the packet is discarded. * EDITOR NOTE: receiving such a packet means that another SAVI device has created a binding for this address, or that the perimeter has been breached. This should be logged? o Other signaling packets are processed and forwarded as usual (i.e. no SAVI processing). In particular DAD_NADV containing IPAddr as the target address are forwarded as usual. TESTING_TP o If the LIFETIME expires, the LAYER_2 ANCHOR is cleared and the state is changed to NO_BIND o If a NADV message containing the IPAddr as target address is received through the Validating port P as a reply to the DAD_NSOL message, then the NADV is forwarded as usual and the state is changed to VALID. The LIFETIME is set to DEFAULT_LT o If a data packet containing IPAddr as the source address is received through port P, then the packet is forwarded. * EDITOR NOTE: should we move back to VALID? o If a data packet is received through a port that is other than port P, then the packet is discarded. TESTING_VP o If the LIFETIME expires, the LAYER_2 ANCHOR set to P' (i.e. P=3D=3DP'), the LIFETIME is set to DEFAULT_LT and the state is = changed to VALID. Data packet stored coming from P' are forwarded. o If a NADV message containing the IPAddr as target address is received through the Validating port P as a reply to the DAD_NSOL message, then the NADV is forwarded as usual and the state is changed to VALID. The LIFETIME is set to DEFAULT_LT o If a data packet containing IPAddr as the source address is received through port P, then the packet is forwarded. Nordmark, et al. Expires April 29, 2010 [Page 15] =0C Internet-Draft FCFS SAVI October 2009 * EDITOR NOTE: should we move back to VALID? o If a data packet is received through a port that is other than port P, then the packet is discarded. TESTING_LIFETIME o If the LIFETIME expires, the LAYER_2 ANCHOR is cleared and the state is changed to NO_BIND o If a NADV message containing the IPAddr as target address is received through the Validating port P as a reply to the DAD_NSOL message, then the NADV is forwarded as usual and the state is changed to VALID. The LIFETIME is set to DEFAULT_LT o If a data packet containing IPAddr as the source address is received through port P, then the packet is forwarded and the state is changed to VALID. The LIFETIME is set to DEFAULT_LT Rate limiting of messages: TBD MLD considerations The SAVI device must join the Solicited Node Multicast group for all the addresses which state is other than NO_BIND. this is needed to make sure that the SAVI device will receive the DAD_NSOL for those addresses. Please note that it may not be enough to relay on the host behind the Validating port doing so, since the node may move and after a while, the packets for that particular solicited node multicast group will no longer be forwarded to the SAVI device. So, the SAVI device SHOULD join the solicited node multicast groups for all the addresses that are in a state other than NO_BIND 5. Security Considerations First of all, it should be noted that any SAVI solution will be as strong as the lower layer anchor that it uses. In particular, if the lower layer anchor is forgeable, then the resulting SAVI solution will be weak. For example, if the lower layer anchor is a MAC address that can be easily spoofed, then the resulting SAVI will not be stronger than that. On the other hand, if we use switch ports as lower layer anchors (and there is only one host connected to each port) it is likely that the resulting SAVI solution will be considerably more secure. Denial of service attacks There are two types of DoS attacks that can be envisaged in a SAVI environment. On one hand, we can envision attacks against the SAVI device resources. On the other hand, we can envision DoS attacks Nordmark, et al. Expires April 29, 2010 [Page 16] =0C Internet-Draft FCFS SAVI October 2009 against the hosts connected to the network where SAVI is running. The attacks against the SAVI device basically consist on making the SAVI device to consume its resource until it runs out of them. For instance, a possible attack would be to send packets with different source addresses, making the SAVI device to create state for each of the addresses and waste memory. At some point the SAVI device runs out of memory and it needs to decide how to react in this situation. The result is that some form of garbage collection is needed to prune the entries. It is recommended that when the SAVI device runs out of the memory allocated for the SAVI DB, it creates new entries by deleting the entries which Creation Time is higher. This implies that older entries are preserved and newer entries overwrite each other. In an attack scenario where the attacker sends a batch of data packets with different source address, each new source address is likely to rewrite another source address created by the attack itself. It should be noted that entries are also garbage collected using the LIFETIME, which is updated using data packets. The result is that in order for an attacker to actually fill the SAVI DB with false source addresses, it needs to continuously send data packets for all the different source addresses, in order for the entries to grow old and compete with the legitimate entries. The result is that the cost of the attack for the attacker is highly increased. The other type of attack is when an attacker manages to create state in the SAVI device that will result in blocking the data packets sent by the legitimate owner of the address. In IPv6 these attacks are not an issue thanks to the 2^64 addresses available in each link. Compare with Threat analysis and identify residual threats: TBD 6. Contributors Jun Bi CERNET Network Research Center, Tsinghua University Beijing 100084 China Email: junbi@cernet.edu.cn Guang Yao CERNET Network Research Center, Tsinghua University Beijing 100084 China Nordmark, et al. Expires April 29, 2010 [Page 17] =0C Internet-Draft FCFS SAVI October 2009 Email: yaog@netarchlab.tsinghua.edu.cn Fred Baker Cisco Systems Email: fred@cisco.com Alberto Garcia Martinez University Carlos III of Madrid Email: alberto@it.uc3m.es 7. Acknowledgments This draft benefited from the input from: Christian Vogt, Dong Zhang, Frank Xia and Lin Tao. Marcelo Bagnulo is partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program. 8. Normative References [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. Authors' Addresses Erik Nordmark Sun Microsystems, Inc. 17 Network Circle Menlo Park, CA 94025 USA Phone: +1 650 786 2921 Email: Erik.Nordmark@Sun.COM Nordmark, et al. Expires April 29, 2010 [Page 18] =0C Internet-Draft FCFS SAVI October 2009 Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6248814 Email: marcelo@it.uc3m.es URI: http://www.it.uc3m.es Eric Levy-Abegnoli Cisco Systems Village d'Entreprises Green Side - 400, Avenue Roumanille Biot-Sophia Antipolis - 06410 France Email: elevyabe@cisco.com Nordmark, et al. Expires April 29, 2010 [Page 19] =0C ------=_NextPart_000_0470_01CA598E.AD80D4D0-- From alberto@it.uc3m.es Fri Oct 30 04:49: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 289713A68F0 for ; Fri, 30 Oct 2009 04:49:57 -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.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 6EPw0F6uaqEd for ; Fri, 30 Oct 2009 04:49:56 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id BC2443A68A8 for ; Fri, 30 Oct 2009 04:49:55 -0700 (PDT) Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) by smtp01.uc3m.es (Postfix) with ESMTP id 1AAD3BA5964; Fri, 30 Oct 2009 12:50:11 +0100 (CET) From: =?iso-8859-15?Q?Alberto_Garc=EDa?= To: "'marcelo bagnulo braun'" , "'Christian Vogt'" References: <871D15B0-6B49-49F4-AD94-88AC7523044C@ericsson.com><200910231045135108459@huaweisymantec.com><5FDC3979-13E4-480A-A1F6-334B95E2ED66@ericsson.com><200910291035478406365@huaweisymantec.com><4540D1DA-94A6-4DC9-B5B9-E9C0E32D127B@ericsson.com><4AE93B2C.7060906@it.uc3m.es><210BBA32-43EB-49EC-B9BB-0C5B9AE7C4EA@ericsson.com> <4AEA9ADF.4030901@it.uc3m.es> Date: Fri, 30 Oct 2009 12:50:10 +0100 Message-ID: <27AAEE66178E4BD2A9D01BAC7E916A1E@bombo> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcpZNbneq6aAFlslS0G+wHqJ3G+u5QAGoz8g In-Reply-To: <4AEA9ADF.4030901@it.uc3m.es> X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16978.006 Cc: 'SAVI Mailing List' Subject: Re: [savi] A few comments on draft-vogt-savi-framework 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, 30 Oct 2009 11:49:57 -0000 Hi | -----Mensaje original----- | De: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] En nombre de marcelo | bagnulo braun | Enviado el: viernes, 30 de octubre de 2009 8:51 | Para: Christian Vogt | CC: SAVI Mailing List; Alberto Garc=EDa | Asunto: Re: [savi] A few comments on draft-vogt-savi-framework | =20 | Christian Vogt escribi=F3: | > Alberto - | > | > As a member of the working group, not as its chair: You are right | > that co-existence scenarios need to be handled. But I'm not sure = that | > coexistence requires /special/ behavior. As long as the behavior | > desired for coexistence scenarios does not preclude the behavior | > desired for non-coexistence scenarios, I think coexistence should = be | > covered by the /regular/ behavior of the various SAVI protocol | > specifications. That is, in the particular case of SLAAC/SEND co- | > existence, I think we should strive for a SAVI SEND protocol that = can | > handle non-SEND-capable SAVI devices. | > | > Does this make sense? | > | yes, but the question is what do we do with the slaac send in the | presence of send capable hosts. | =20 | If we want to support them, then all slaac savi devices need to | implement the send savi, which seems an overkill for a the send = protocol | which deployment is non existent afaict | If we allow sllac savi only devices, then plugging a send host would = not | work well (in particular, the send node can be filtered by the savi | device in some cases, making the deployment of send even harder later | on. So this is a tough call imho I agree that requiring SEND implementations in all SAVI devices maybe overkill. However, I don't see many functional problems with SEND hosts interacting in a SLAAC-only environment (i.e. apart of not being able to prioritize SEND bindings over SLAAC, which is natural if switches don't recognize SEND).=20 The case in which SEND hosts could have some trouble is in the DAD procedure, since they behave different than SLAAC hosts if there is an address collision in the second try with a non-SEND device. SEND hosts = would configure the address, but the SLAAC SAVI device would filter all = packets from the SEND host. While this is true, we have to consider that for this to occur, the = SLAAC host with the address colliding with the SEND device must have = (according to FCFS SAVI spec) the address configured BEFORE the SEND host issues its = DAD NSOL (or SAVI would filter its DAD NADV).=20 If a SEND host tries a first address, and fails, where do the second address is coming from? If the new address was not known for the rest of = the network (eg. because it has just generated dynamically after the failure = of the first), then this event would be a real (unlikely) collision, and = not an attack. Do you think this is a functional issue? I would say no, but... So maybe a SLAAC-only mode for SAVI could provide support for SEND = hosts, although, of course, the result would be better if SAVI devices are = aware of SEND. Regards, Alberto | =20 | Regards, marcelo | =20 | =20 | > - Christian | > | > | > | > On Oct 29, 2009, at 3:04, Alberto Garc=EDa wrote: | > | > | >> My opinion is that priorization is not enough. | >> I think we need to define "operation modes" (SEND-only, = SLAAC-only, | >> SEND-SLAAC-compatible...) and describe the state machine for each = one. | >> | >> To support the idea of why we need a new state machine for = SEND-SLAAC | >> compatibility, i.e. for a domain in which both SEND hosts and non- | >> SEND hosts | >> coexist, just consider what a node should do (extending naturally = the | >> current FCFS and SEND proposals) if a SAVI device is in NO_BIND | >> state, and a | >> data packet (not DAD NSOL) is received, from a Validating port VP. | >> In this | >> case, the SEND SAVI device should send | >> - 2 (unsecured) NSOL messages through Trusted ports (according to | >> FCFS SAVI) | >> - and a secured NUD NSOL message through the Validating Port | >> (according to SEND SAVI | >> And The state is moved to TENTATIVE. | >> | >> In the TENTATIVE state, the SAVI device should maybe wait long | >> enough (a | >> RetransTimer, which is the waiting time for NUD operation) for a | >> secured NUD | >> NADV even if an unsecured DAD NSOL is received from a trusted port | >> in the | >> meanwhile, to assure that SEND validated addresses have priority = over | >> non-SEND addresses. [Note that this may occur if a SEND host has = one | >> collision when performing DAD for an address, and it is not | >> withdrawing the | >> second address if an unsecured DAD NSOL is received for it, as RFC | >> 3971 | >> says]. | >> Different states should be defined (VALID_SEND, VALID_NON_SEND), = with | >> different behavior when the valid_timeout expires. | >> | >> | >> So I don't think this is just "ships in the night", but different | >> modes | >> should be defined to integrate all the possible combinations of | >> address | >> configuration mechanisms. Maybe one of these modes should be the | >> default | >> one, but the administrator could set the SAVI devices to the | >> appropriate | >> mode (well, they also have to define which ports are trusted or | >> not...). | >> | >> Does this make sense? | >> Regards, | >> Alberto | >> | > | > | > | > | > | =20 | _______________________________________________ | savi mailing list | savi@ietf.org | https://www.ietf.org/mailman/listinfo/savi From alberto@it.uc3m.es Fri Oct 30 05:21:29 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 3162D3A6A9D for ; Fri, 30 Oct 2009 05:21:29 -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.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 yI+3vJwl7drW for ; Fri, 30 Oct 2009 05:21:28 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 1302F3A6A9B for ; Fri, 30 Oct 2009 05:21:27 -0700 (PDT) Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) by smtp01.uc3m.es (Postfix) with ESMTP id 3E6AFBA84E4; Fri, 30 Oct 2009 12:50:11 +0100 (CET) From: =?iso-8859-15?Q?Alberto_Garc=EDa?= To: "'Christian Vogt'" , "'Marcelo Bagnulo Braun'" References: <871D15B0-6B49-49F4-AD94-88AC7523044C@ericsson.com><200910231045135108459@huaweisymantec.com><5FDC3979-13E4-480A-A1F6-334B95E2ED66@ericsson.com><200910291035478406365@huaweisymantec.com><4540D1DA-94A6-4DC9-B5B9-E9C0E32D127B@ericsson.com><4AE93B2C.7060906@it.uc3m.es> <633E8B21-3B7C-4E17-B661-2E56AA1DB635@ericsson.com> Date: Fri, 30 Oct 2009 12:50:10 +0100 Message-ID: <6EBBF696092A4BE698D0567E62C42547@bombo> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcpY1akNHT4Sapl0SniAQnJtvBVtqwAeiMhg In-Reply-To: <633E8B21-3B7C-4E17-B661-2E56AA1DB635@ericsson.com> X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16978.006 Cc: 'SAVI Mailing List' Subject: Re: [savi] A few comments on draft-vogt-savi-framework 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, 30 Oct 2009 12:21:29 -0000 Hi | -----Mensaje original----- | De: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] En nombre de | Christian Vogt | Enviado el: jueves, 29 de octubre de 2009 21:24 | Para: Marcelo Bagnulo Braun | CC: SAVI Mailing List | Asunto: Re: [savi] A few comments on draft-vogt-savi-framework | | | On Oct 28, 2009, marcelo bagnulo braun wrote: | | >> For this case, we need a prioritization of which address assignment | >> methods take precedence over which other address assignment methods. | >> And you are right that the definition of this prioritization will | >> require care. | >> | > | > yes, moreover, we need to figure if it is enough with a prioritazation | > or we need to change the mechanisms in order to interact properly. | > As i | > stated earlier (and eric noted before me), we certainly need to update | > send savi to properly interact with the slaac savi (at least, haven't | > doen the analysis for dhcp savi yet) | | Correct; the prioritization may affect the protocol specifications | (SLAAC, DHCP, SEND) just as well as it affects the framework document. | | My suggestion -- as a working group member, not as a chair -- is that | the framework document should talk about the prioritization | conceptually, whereas the protocol specifications need to include the | details that implement the prioritization. Thoughts? Fully agree. It should be stated which is preferred over what, and a good place for this is the framework document. And I still believe that there is much more to detail after the general scheme of prioritization has been stated. In particular, for SEND and SLAAC interaction (maybe not for DHCP, this should be studied). Regards, Alberto | | - Christian | | | _______________________________________________ | savi mailing list | savi@ietf.org | https://www.ietf.org/mailman/listinfo/savi From christian.vogt@ericsson.com Fri Oct 30 13:30:55 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 6765B3A67BD for ; Fri, 30 Oct 2009 13:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.43 X-Spam-Level: X-Spam-Status: No, score=-6.43 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 i2ir7cr3Cuk0 for ; Fri, 30 Oct 2009 13:30:54 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 648513A6778 for ; Fri, 30 Oct 2009 13:30:54 -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 n9UKV3Zt011109; Fri, 30 Oct 2009 15:31:06 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 15:30:37 -0500 Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 15:30:33 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.35]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 30 Oct 2009 16:30:33 -0400 From: Christian Vogt To: Marcelo Bagnulo Braun , =?iso-8859-1?Q?Alberto_Garc=EDa?= , SAVI Mailing List Date: Fri, 30 Oct 2009 16:31:13 -0400 Thread-Topic: SLAAC/SEND Co-Existence Thread-Index: AcpZn9Rw3DBk7d4cSsimRNIN5sQj1Q== Message-ID: <5992D79E-571D-4D31-A711-7A24B8181B79@ericsson.com> References: <871D15B0-6B49-49F4-AD94-88AC7523044C@ericsson.com> <200910231045135108459@huaweisymantec.com> <5FDC3979-13E4-480A-A1F6-334B95E2ED66@ericsson.com> <200910291035478406365@huaweisymantec.com><4540D1DA-94A6-4DC9-B5B9-E9C0E32D127B@ericsson.com> <4AE93B2C.7060906@it.uc3m.es> <210BBA32-43EB-49EC-B9BB-0C5B9AE7C4EA@ericsson.com> <4AEA9ADF.4030901@it.uc3m.es> In-Reply-To: <4AEA9ADF.4030901@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Oct 2009 20:30:33.0964 (UTC) FILETIME=[D4E092C0:01CA599F] Subject: Re: [savi] SLAAC/SEND Co-Existence 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, 30 Oct 2009 20:30:55 -0000 Forked from thread "A few comments on draft-vogt-savi-framework". On Oct 30, 2009, marcelo bagnulo braun wrote: >> As a member of the working group, not as its chair: You are right >> that co-existence scenarios need to be handled. But I'm not sure =20 >> that >> coexistence requires /special/ behavior. As long as the behavior >> desired for coexistence scenarios does not preclude the behavior >> desired for non-coexistence scenarios, I think coexistence should be >> covered by the /regular/ behavior of the various SAVI protocol >> specifications. That is, in the particular case of SLAAC/SEND co- >> existence, I think we should strive for a SAVI SEND protocol that can >> handle non-SEND-capable SAVI devices. >> >> Does this make sense? >> > > yes, but the question is what do we do with the slaac send in the > presence of send capable hosts. For the record: s/slaac send/slaac savi/ Absolutely. In my opinion, the optimal solution would include separate SAVI SLAAC and SAVI SEND protocols, both designed for co-existence, but with minimal functionality specific to the respective other protocol. In particular, the SAVI SLAAC protocol should avoid complex SEND-specific functionality. An optimal solution would also allow non-SEND hosts to attach to SAVI SEND switches, and SEND hosts to attach to SAVI SLAAC switches. Such "interworking" may lead to sub-optimal protectiveness of SAVI, as Alberto notes, but it should not interfere with the hosts. Assuming we succeed in engineering this optimal solution, we would minimize the cost of SAVI SLAAC switches, while still enabling the incremental deployment of SAVI SEND switches in a network with SAVI SLAAC switches. Also, the use of SAVI SLAAC switches would not hinder the deployment of SEND, as SAVI SLAAC switches would simply provide less protectiveness compared to what was possible with SAVI SEND switches. Is this a reasonable goal? Any concerns, changes, or additions? - Christian From christian.vogt@ericsson.com Fri Oct 30 13:52: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 CDF2C3A6885 for ; Fri, 30 Oct 2009 13:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.416 X-Spam-Level: X-Spam-Status: No, score=-6.416 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 jtVy7GEE+OAD for ; Fri, 30 Oct 2009 13:52:21 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 17A083A6820 for ; Fri, 30 Oct 2009 13:52: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 n9UKqXpf017346; Fri, 30 Oct 2009 15:52:37 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 15:51:22 -0500 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 15:51:22 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.35]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 30 Oct 2009 16:51:21 -0400 From: Christian Vogt To: =?iso-8859-1?Q?Alberto_Garc=EDa?= Date: Fri, 30 Oct 2009 16:52:01 -0400 Thread-Topic: [savi] A few comments on draft-vogt-savi-framework Thread-Index: AcpZorxvHS+Wxj28Sny5C4bYelVz5Q== Message-ID: <72D57621-3CEF-4DCB-950F-079E14F7B37C@ericsson.com> References: <871D15B0-6B49-49F4-AD94-88AC7523044C@ericsson.com><200910231045135108459@huaweisymantec.com><5FDC3979-13E4-480A-A1F6-334B95E2ED66@ericsson.com><200910291035478406365@huaweisymantec.com><4540D1DA-94A6-4DC9-B5B9-E9C0E32D127B@ericsson.com><4AE93B2C.7060906@it.uc3m.es><210BBA32-43EB-49EC-B9BB-0C5B9AE7C4EA@ericsson.com> <4AEA9ADF.4030901@it.uc3m.es> <27AAEE66178E4BD2A9D01BAC7E916A1E@bombo> In-Reply-To: <27AAEE66178E4BD2A9D01BAC7E916A1E@bombo> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Oct 2009 20:51:22.0373 (UTC) FILETIME=[BCFCAB50:01CA59A2] Cc: SAVI Mailing List Subject: Re: [savi] A few comments on draft-vogt-savi-framework 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, 30 Oct 2009 20:52:21 -0000 On Oct 30, 2009, Alberto Garc=EDa wrote: > The case in which SEND hosts could have some trouble is in the DAD > procedure, since they behave different than SLAAC hosts if there is an > address collision in the second try with a non-SEND device. SEND hosts > would configure the address, but the SLAAC SAVI device would filter =20 > all > packets from the SEND host. A good observation indeed. I personally (not as a working group chair) agree with you that this issue is minor, given the low probability for it to happen -- assuming, as you say, that the attacker is behind a SAVI device. Yet, co-existence issues like this one should be carefully documented. Perhaps every SAVI protocol specification should include a section on co-existence with SAVI protocol instances for other address assignment methods? - Christian