From christian.vogt@nomadiclab.com Wed May 28 23:57:16 2008 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 E131A3A6914 for ; Wed, 28 May 2008 23:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 xuSr5bWbREOx for ; Wed, 28 May 2008 23:57:16 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 04C133A686B for ; Wed, 28 May 2008 23:57:13 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 3913F1F747C; Thu, 29 May 2008 09:57:11 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id F2ECB1F747B; Thu, 29 May 2008 09:57:10 +0300 (EEST) Message-Id: <99BC6517-C406-45F0-8188-7647E9A1D195@nomadiclab.com> From: Christian Vogt To: SAVI Mailing List , savi@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 29 May 2008 09:57:10 +0300 X-Mailer: Apple Mail (2.919.2) X-Virus-Scanned: ClamAV using ClamSMTP Subject: [savi] New SAVI Mailing List 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 May 2008 06:57:16 -0000 Dear folks, we now have a new, official IETF mailing list for SAVI, to which we are now migrating. I have subscribed you, the members of the original mailing list, to the new mailing list. You should have received a confirmation. Those of you who had selected digest mode on the old list will also receive digests on the new list. To post a message on the new SAVI mailing list, send it to: savi@ietf.org For mailing list information and account management, go to: https://www.ietf.org/mailman/listinfo/savi And to access the archives, go to: http://www.ietf.org/mail-archive/web/savi The archives from the original mailing list have been copied to this new archive. Best regards, - Christian From christian.vogt@nomadiclab.com Thu May 29 00:17:51 2008 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 AA2013A6972 for ; Thu, 29 May 2008 00:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 8DZA0-JWMY3L for ; Thu, 29 May 2008 00:17:47 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 4F1B73A6B38 for ; Thu, 29 May 2008 00:17:23 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5C1CA1F752F; Thu, 29 May 2008 10:17:22 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 251CA1F752E; Thu, 29 May 2008 10:17:22 +0300 (EEST) Message-Id: <68219BC0-5C7F-491E-A4AD-FF9110CE4824@nomadiclab.com> From: Christian Vogt To: SAVI Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 29 May 2008 10:17:21 +0300 X-Mailer: Apple Mail (2.919.2) X-Virus-Scanned: ClamAV using ClamSMTP Subject: [savi] Acknowledgment 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 May 2008 07:17:51 -0000 Now that the new SAVI working group has been established, I would like to say thank you to our area director, who has done a great job in pushing for this working group, both in IESG and IAB, not to mention the plethora of administrative tasks that precede and go along with a working group formation, such as scheduling meetings, reserving rooms, having new mailing lists be set up... Thanks a lot, Jari! - Christian From junbi@cernet.edu.cn Thu May 29 04:07:08 2008 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 E7D0328C241 for ; Thu, 29 May 2008 04:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.7 X-Spam-Level: ** X-Spam-Status: No, score=2.7 tagged_above=-999 required=5 tests=[FH_HAS_XAIMC=2.699, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MyuJsu0z2xJ for ; Thu, 29 May 2008 04:07:05 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 18BFF28C23C for ; Thu, 29 May 2008 04:07:02 -0700 (PDT) Received: from userPC([59.66.24.101]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm2a483ecfcd; Thu, 29 May 2008 19:06:54 +0800 Message-ID: From: "Jun Bi" To: "Christian Vogt" , "SAVI Mailing List" , References: <99BC6517-C406-45F0-8188-7647E9A1D195@nomadiclab.com> In-Reply-To: <99BC6517-C406-45F0-8188-7647E9A1D195@nomadiclab.com> Date: Thu, 29 May 2008 19:06:39 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: 1qKyfBUB Subject: Re: [savi] [SAVA] New SAVI Mailing List 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 May 2008 11:07:09 -0000 Dear folks, I am happy that we have this new official mailing-list to replace the old mailing-list which served from July 2006. Let's work together to make this WG successful. Best Regards, Jun Bi ----- Original Message ----- From: "Christian Vogt" To: "SAVI Mailing List" ; Sent: Thursday, May 29, 2008 2:57 PM Subject: [SAVA] New SAVI Mailing List > Dear folks, > > we now have a new, official IETF mailing list for SAVI, to which > we are now migrating. I have subscribed you, the members of the > original mailing list, to the new mailing list. You should have > received a confirmation. Those of you who had selected digest > mode on the old list will also receive digests on the new list. > > To post a message on the new SAVI mailing list, send it to: > > savi@ietf.org > > For mailing list information and account management, go to: > > https://www.ietf.org/mailman/listinfo/savi > > And to access the archives, go to: > > http://www.ietf.org/mail-archive/web/savi > > The archives from the original mailing list have been copied to > this new archive. > > Best regards, > - Christian > > > > _______________________________________________ > SAVA mailing list > SAVA@mail.nrc.tsinghua.edu.cn > http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava > > From fred@cisco.com Thu May 29 07:52:04 2008 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 8D2DB3A6803 for ; Thu, 29 May 2008 07:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XGpt2hRvPTW for ; Thu, 29 May 2008 07:51:59 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id DF7173A6851 for ; Thu, 29 May 2008 07:51:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,561,1204531200"; d="scan'208";a="73611751" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 29 May 2008 07:51:59 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m4TEpxSZ028787; Thu, 29 May 2008 07:51:59 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4TEpxD2001512; Thu, 29 May 2008 14:51:59 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 May 2008 07:51:58 -0700 Received: from [10.2.9.7] ([10.21.122.42]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 May 2008 07:51:58 -0700 In-Reply-To: <68219BC0-5C7F-491E-A4AD-FF9110CE4824@nomadiclab.com> References: <68219BC0-5C7F-491E-A4AD-FF9110CE4824@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v753) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <22078948-6961-4579-9DA8-DD16ECC269B5@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Thu, 29 May 2008 07:51:57 -0700 To: Jari Arkko X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 29 May 2008 14:51:58.0718 (UTC) FILETIME=[8BA7C9E0:01C8C19B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=662; t=1212072719; x=1212936719; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[savi]=20Acknowledgment |Sender:=20; bh=2DLJjbmvte2oNfTZlMFbKX3WvwCjvbVRlrKiEsI+muc=; b=FF0o1T4LTuDUmePYO4wI8SsDGL/TjjYd9yA8D0x6Nw8hOnAawF5F38jf3O Xb3PprHNMaw5da7sZOOlpbM6WWPp/OM+4qxBRnSQ/luotCgfyOwhHk/PdnxX E6ckYmf+9X; Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: SAVI Mailing List Subject: Re: [savi] Acknowledgment 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 May 2008 14:52:04 -0000 Yes. Thanks On May 29, 2008, at 12:17 AM, Christian Vogt wrote: > Now that the new SAVI working group has been established, I > would like to say thank you to our area director, who has done > a great job in pushing for this working group, both in IESG > and IAB, not to mention the plethora of administrative tasks > that precede and go along with a working group formation, such > as scheduling meetings, reserving rooms, having new mailing > lists be set up... > > Thanks a lot, Jari! > > - Christian > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From christian.vogt@nomadiclab.com Thu May 29 08:52:05 2008 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 B42CB3A6B9F for ; Thu, 29 May 2008 08:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 m3dQXo1hyfjl for ; Thu, 29 May 2008 08:52:04 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id BBFE93A6B8A for ; Thu, 29 May 2008 08:52:04 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 640841F7DF8; Thu, 29 May 2008 18:52:03 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 293901F7DF7; Thu, 29 May 2008 18:52:03 +0300 (EEST) From: Christian Vogt To: Jun Bi In-Reply-To: X-Priority: 3 References: <99BC6517-C406-45F0-8188-7647E9A1D195@nomadiclab.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 29 May 2008 18:52:02 +0300 X-Mailer: Apple Mail (2.919.2) X-Virus-Scanned: ClamAV using ClamSMTP Cc: SAVI Mailing List , SAVI Mailing List Subject: Re: [savi] New SAVI Mailing List 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 May 2008 15:52:05 -0000 On May 29, 2008, at 14:06, Jun Bi wrote: > I am happy that we have this new official mailing-list to > replace the old mailing-list which served from July 2006. The old mailing list was indeed a great help. Thank you, Jun, and your fellows at Tsinghua, for hosting this, and for always being very responsive administrators. - Christian From junbi@tsinghua.edu.cn Thu May 29 09:10:56 2008 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 AA0063A6ACD for ; Thu, 29 May 2008 09:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CYTBX8PPAQg for ; Thu, 29 May 2008 09:10:51 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id E7ED13A6974 for ; Thu, 29 May 2008 09:10:50 -0700 (PDT) Received: from [59.66.53.135] (helo=userPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.63) (envelope-from ) id 1K1kjD-0003ef-TM; Fri, 30 May 2008 00:11:48 +0800 Message-ID: <85B3ED5CAF1049A08EC2D89C1BA4E52E@userPC> From: "Jun Bi" To: "Christian Vogt" References: <99BC6517-C406-45F0-8188-7647E9A1D195@nomadiclab.com> In-Reply-To: Date: Fri, 30 May 2008 00:10:28 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 Cc: SAVI Mailing List , SAVI Mailing List Subject: Re: [savi] New SAVI Mailing List X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jun Bi List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2008 16:10:56 -0000 You are welcome, it's my pleasure administrated the old mailing-list. Without efforts of all members in the mailing-list, we can not have the SAVI WG created. Jun Bi ----- Original Message ----- From: "Christian Vogt" To: "Jun Bi" Cc: "SAVI Mailing List" ; "SAVI Mailing List" Sent: Thursday, May 29, 2008 11:52 PM Subject: Re: [savi] New SAVI Mailing List > > On May 29, 2008, at 14:06, Jun Bi wrote: > >> I am happy that we have this new official mailing-list to >> replace the old mailing-list which served from July 2006. > > The old mailing list was indeed a great help. Thank you, > Jun, and your fellows at Tsinghua, for hosting this, and > for always being very responsive administrators. > > - Christian > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > > From junbi@tsinghua.edu.cn Thu May 29 09:10:56 2008 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 B12873A6974 for ; Thu, 29 May 2008 09:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACTkb8x6Hdl7 for ; Thu, 29 May 2008 09:10:51 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id E80543A6ACC for ; Thu, 29 May 2008 09:10:50 -0700 (PDT) Received: from [59.66.53.135] (helo=userPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.63) (envelope-from ) id 1K1kiZ-0002Si-Ni; Fri, 30 May 2008 00:11:07 +0800 Message-ID: <06A067524CFD44D6947C24A3538660BB@userPC> From: "Jun Bi" To: "Christian Vogt" References: <99BC6517-C406-45F0-8188-7647E9A1D195@nomadiclab.com> In-Reply-To: Date: Fri, 30 May 2008 00:09:46 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 Cc: SAVI Mailing List , SAVI Mailing List Subject: Re: [savi] New SAVI Mailing List X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jun Bi List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2008 16:10:56 -0000 You are welcome, it's my pleasure administrated the old mailing-list. Without efforts of all members in the mailing-list, we can not have the SAVI WG created. Jun Bi ----- Original Message ----- From: "Christian Vogt" To: "Jun Bi" Cc: "SAVI Mailing List" ; "SAVI Mailing List" Sent: Thursday, May 29, 2008 11:52 PM Subject: Re: [savi] New SAVI Mailing List > > On May 29, 2008, at 14:06, Jun Bi wrote: > >> I am happy that we have this new official mailing-list to >> replace the old mailing-list which served from July 2006. > > The old mailing list was indeed a great help. Thank you, > Jun, and your fellows at Tsinghua, for hosting this, and > for always being very responsive administrators. > > - Christian > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > > From christian.vogt@nomadiclab.com Wed Jul 9 05:59:10 2008 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 A2B2E28C0FF for ; Wed, 9 Jul 2008 05:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id im3rIPeGVRl0 for ; Wed, 9 Jul 2008 05:59:09 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 2998828C123 for ; Wed, 9 Jul 2008 05:59:06 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id CFCC21EF864; Wed, 9 Jul 2008 15:59:16 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 605F01EF320; Wed, 9 Jul 2008 15:59:16 +0300 (EEST) Message-Id: <6471B9F8-4D59-46F9-951B-0B4581608476@nomadiclab.com> From: Christian Vogt To: SAVI Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 9 Jul 2008 15:59:16 +0300 X-Mailer: Apple Mail (2.926) X-Virus-Scanned: ClamAV using ClamSMTP Subject: [savi] Call for SAVI Solution Proposals X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2008 12:59:10 -0000 Folks, with the acceptance of the SAVI charter by the IESG, the Do's and Don'ts for our working group have been set out. We know that a SAVI solution should be operated on the same IP link as a to-be-verified node; that it should be based on observing user traffic, or based on observing or using existing signaling protocols; that it should do with minimal manual configuration; and that it should not require host changes. Within these boundaries, the charter leaves us considerable design liberties. Reason enough to start an exploration of the solution space. We already have one solution proposal [1] from Fred, which goes into the right direction. Are there other proposals? Or perhaps proposals for modifications to Fred's? If you have a solution proposal in your mind, please sketch it, briefly and at a conceptual level, and send it to this mailing list. In order to maximize comparability of the solution proposals, I have prepared a solution space taxonomy and analysis [2] based on an earlier analysis by Jari Arkko. This includes: - a taxonomy of concept that I expect most SAVI solution proposals will have equivalents for, - degrees of freedom for designing a protocol implementing those concepts, - a list of non-trivial scenarios that SAVI solutions should preferably be able to deal with, - an analysis of how different design trade-offs affect the ability of a SAVI solution to handle these non-trivial scenarios. If you can map your favorite SAVI solution onto these concepts, and if you can describe the design decisions you made in terms of these degrees of freedom, then this will help the working group in discussing your proposal and compare it to other proposals. Overall, therefore, I am asking you for two things: (1) Your feedback on the taxonomy and analysis in [2]. Do you think it is correct? Is it complete? (2) A brief, conceptual-level description of your favorite SAVI solution proposal, if you have one. Please send your input by Friday, July 18, at least a preliminary version. I know this call is on short notice, but we need you input soon to give other folks time to read it prior to the Dublin meeting. - Christian [1] http://tools.ietf.org/id/draft-baker-sava-implementation [2] http://users.piuha.net/chvogt/pub/2008/vogt-2008-savi-solution-space.pdf From christian.vogt@nomadiclab.com Fri Jul 18 12:34:13 2008 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 34BD03A6A40 for ; Fri, 18 Jul 2008 12:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, J_CHICKENPOX_102=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjwRRPpj4pNM for ; Fri, 18 Jul 2008 12:34:10 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id E25103A67D9 for ; Fri, 18 Jul 2008 12:34:05 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id D363E1EF803; Fri, 18 Jul 2008 22:34:37 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 3D63A1EF800; Fri, 18 Jul 2008 22:34:37 +0300 (EEST) Message-Id: <3E27B09A-9FCB-4E9D-A8E4-5CDFFBDCD56E@nomadiclab.com> From: Christian Vogt To: SAVI Mailing List Content-Type: multipart/mixed; boundary=Apple-Mail-6--268207904 Mime-Version: 1.0 (Apple Message framework v926) X-Priority: 3 Date: Fri, 18 Jul 2008 22:34:36 +0300 References: <74216AB8-6350-479B-9653-C059E34EA335@nomadiclab.com> X-Mailer: Apple Mail (2.926) X-Virus-Scanned: ClamAV using ClamSMTP Cc: Guang Yao Subject: [savi] SAVI solution proposal from Jun Bi et al. 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, 18 Jul 2008 19:34:13 -0000 --Apple-Mail-6--268207904 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I am forwarding to you a SAVI solution proposal from Jun Bi et al., as well as a first review of this proposal from myself. Reviews and comments from other folks are very welcome, of course. Kind regards, - Christian Begin forwarded message: > From: Christian Vogt > Date: July 18, 2008 15:36:08 GMT+03:00 > To: Jun Bi , Jianping Wu > , > Guang Yao > Cc: Bill Fenner , Jari Arkko > Subject: Comments on Your SAVI Proposal > > Jun, Jianping, and Guang, > > thanks for working so quickly on this proposal. You should definitely > present it at the SAVI session in Dublin. I have put you on the > agenda. > > I must note, though, that the proposal is not fully compliant with the > SAVI charter in two ways: (i) It requires host changes, which the > SAVI charter prohibits, and (ii) it performs host authentication, > which also goes beyond the SAVI charter. This means that there will > likely be skeptical comments at the microphone to which you should be > prepared. The prospective SAVI solution will have to affect a > compromise between effectiveness (security) and non-intrusiveness (no > false packet drops, backwards compatibility, small configuration > overhead). Your proposal errs on the side of security in this > trade-off space, Fred's proposal, for one, errs on the side > of non-intrusiveness. I believe the prospective SAVI solution will > lie between the two. In any case, it will have to lie within the > charter limits. > > A comment of technical nature: Your proposal supports different > address configuration methods (autonomous, DHCP, privacy, CGA, > manual). In one of them, the DHCP case, you require a cryptographic > binding between the initial address generation and the registration of > this address with the SAVI enforcement point. You are doing this even > at the cost of changing the DHCP protocol. Why is such a binding > required in the DHCP case, and why not in other cases? Considered > homogenizing this? > > - Christian > > > > On Jul 17, 2008, at 9:06, Jun Bi wrote: > >> Dear Jari and Christian, >> >> This is a draft we want to submit. Please give us some advice. >> >> Best Regards, Jun Bi --Apple-Mail-6--268207904 Content-Disposition: attachment; filename=csa.txt Content-Type: text/plain; x-unix-mode=0644; name="csa.txt" Content-Transfer-Encoding: quoted-printable Network Working Group J. Bi Internet-Draft J. Wu Intended status: Experimental G. Yao Expires: November 2, 2008 CERNET May 2008 A First-Hop IPv6 Source Address Authorization and Authentication Method draft-sava-solution-ipv6-firsthop-authentication-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 November 2, 2008. Bi, et al. Expires November 2, 2008 [Page 1] =0C Internet-Draft ipv6-firsthop-authentication May 2008 Abstract This document describes a method to authorize and authenticate the address of a node in IPv6 network. Except for "Host Change", this method satisfies all the requirements in the Charter of SAVI. The modification on a host can be regarded as the extension of SeND and IPSec. Table of Contents 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Address Authorization . . . . . . . . . . . . . . . . . . . . 5 3.1. Address Preparation . . . . . . . . . . . . . . . . . . . 5 3.2. Identifier Generation . . . . . . . . . . . . . . . . . . 7 3.3. Address Request . . . . . . . . . . . . . . . . . . . . . 8 3.4. Gateway Authorizing Address . . . . . . . . . . . . . . . 10 3.5. Address Assignment . . . . . . . . . . . . . . . . . . . . 13 4. Address Authentication . . . . . . . . . . . . . . . . . . . . 14 4.1. Signature Generation . . . . . . . . . . . . . . . . . . . 14 4.2. Signature Adding . . . . . . . . . . . . . . . . . . . . . 14 4.3. Sending packet . . . . . . . . . . . . . . . . . . . . . . 15 4.4. Router checking packet . . . . . . . . . . . . . . . . . . 15 4.5. Router transmiting packet . . . . . . . . . . . . . . . . 15 5. Some Consideration . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Updating of the mapping table . . . . . . . . . . . . . . 16 5.2. Cooperating with SEND . . . . . . . . . . . . . . . . . . 16 5.3. Deployment not on first-hop router . . . . . . . . . . . . 16 5.4. Anti-Spoofing Ability . . . . . . . . . . . . . . . . . . 16 5.5. Keep-alive . . . . . . . . . . . . . . . . . . . . . . . . 17 5.6. Other consideration . . . . . . . . . . . . . . . . . . . 17 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Bi, et al. Expires November 2, 2008 [Page 2] =0C Internet-Draft ipv6-firsthop-authentication May 2008 1. Requirements Language 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 RFC 2119 [RFC2119]. Bi, et al. Expires November 2, 2008 [Page 3] =0C Internet-Draft ipv6-firsthop-authentication May 2008 2. Introduction In this method, a node must request the use right of an address from the first-hop gateway(either layer 2 gateway or layer 3 gateway). Th first-hop gateway makes a decision on whether address can be used by the node, according to current address allocation method. And then a secret is exchanged between the node and the gateway. Whenever the node wants to send a packet via the gateway, a signature MUST be added into the packet if required by the gateway. The signaure is generated on the shared secret and both of the gateway and the node know the generating algorithm. The gateway checks the signature to find whether the packet is from the owner of the source address. An identifier called "CGA identifier" is used to help in the address ownership determination. This method is designed to suit in the situation that the administrator can not perform filtering on the port of switch, so it is complex and the overhead is high. However, if part of the switches can be updated, this mechanism can be simplified. This mechanism is composed by two main parts: Address authorization process and address authentication process. Bi, et al. Expires November 2, 2008 [Page 4] =0C Internet-Draft ipv6-firsthop-authentication May 2008 3. Address Authorization This process is shown in the Fig.1. Node Gateway | | | Request Addr A | Address |---------------->| Request | Identifier=3DIA | | Pub Key=3DPk | | | | | | |Address Use Right Check | |Binding(IA,Pk,A,Seed) | | Address | Comfirm Addr A | Assignment |<----------------| | Signature Seed | | Encypted by Pk | | | Figure 1: Address authorization process 3.1. Address Preparation We emphasize the manner of address assignement for we think the meaning of IP spoofing is a user/host/interface is using an/many addresses which are not assigned to it by the appointed allocation method, or the configuration of allocation is wrong. IP spoofing caused by wrong configuration is always not malicious and can be corrected easily once the error is detected. Moreover, if the allocation mechanism is wrongly configured, the spoof filtering mechanism has no reason to run correctly for the infomation used in filtering is also wrong. Thus we only deal with the using of address not allocated to the user/host/interface by the allocation method. In this stage, if the node is a host, it MUST prepare an address. The address MUST be got according to current address allocation method. This means: Manually: the address MUST be got from the network administrator. This means the address is allocated to the host/user/interface by the administrator previously. DHCP(either stateless or stateful): The address MUST be got from the DHCP server[DHCP,stateful,stateless]. To help affirm which host gets Bi, et al. Expires November 2, 2008 [Page 5] =0C Internet-Draft ipv6-firsthop-authentication May 2008 the ownership of the returned address of the DHCP server, the request message must be changed to contain an unspoofable identifier of the host. We choose CGA[CGA] to play as the role of the identifier and to avoid the using of PKI. The procedure of DHCP allocation is changed as follows: The node MUST use a CGA address as the source address to request an address from the DHCP server. The CGA address MUST be generated using the procedure described in [CGA]. The corresponding CGA option and signature MUST be contained in the packet. The request packet MUST contain a random nounce to prevent replay attack. The first-hop layer-3 gateway MUST have the ability of obtaining the request message and the response message of the DHCP server. The DHCP server MAY be placed out of local network and so the gateway will forward both kinds of messages. Or these packets MAY be changed to multicast packets to reach the gateway. Or other methods may be chosen here. The gateway MUST check the correctness of signaure and address portion of the request packet, and drop wrong packets. The gateway MUST record the CGA address in the validated request packet, and wait for the response packet from the DHCP server. Once a response message arrives, the gateway will check which address is allocated to the applicant and bind the CGA address of the applicant to the allocated address. The advertised address in the response packet is the address allocated to the host. If there is any DHCP relay point, the source address of the request packet MUST be unchanged before it reaches the gateway. Stateless Auto Configuration: the address MUST be got using NDP and there MUST be no duplication[SAC]. Privacy: the address MUST be got using NDP and there MUST be no duplication[Privacy]. This mechanism doesn't guarantee the privacy requirement of node. Node MUST using its own policy to achieve privacy. [Privacy]. CGA: the address MUST be generated according to CGA generation algorithm[CGA]. The Sec value is decided according to the requirement of administrator. Arbitrarily generated address will not be regarded as illegal address unless it offends against the forbidden rules of the appointed address allocation method. For example, if a node uses any other address in manually configuration case, it is spoofing. However, if in SAC situation, a host can use other addresses as long as they are not being used by others, even no DAD has been performed. The address preparation stage MAY be combined with the other stages to simplify the whole procedure. For example, the DHCP address MAY be got together with the signature seed described in the next section. Bi, et al. Expires November 2, 2008 [Page 6] =0C Internet-Draft ipv6-firsthop-authentication May 2008 If the node is a NAT box, it prepares one or more addresses. Always the addresses are allocated by administrator manually. If the node is a DHCP-PD router, it prepares one or more prefixs instead of one address. The prefixes are got by DHCP-PD protocol. Always these prefixes have been configured by the adminitrator previously. If the node is an IPv4 node, the only different case is DHCP. The node cannot use a CGA address to send DHCP solicition. It can be solved by using the address as an identifier, but not an address. The CGA address in contained in the packet as an option, and the host id of the IPv4 address is the hash of the CGA address. And the signature is computed on the whole packet. Except for DHCP, there is nothing different from normal address allocation method in this stage. In manually allocation, we already know which address has been allocated to whom. So the validation of the ownership of the address must be based on some existing and fixed knowledge, but not a stateless CGA identifier. In SAC and similar mechanisms, because there is actually no "allocation" procedure, a node can get the ownership of any address not being used. We don't care who is using the address. In some case we do care who is using an address, but this problem is actually out of the scope of preventing IP spoofing. The solution of tracing the user of an address requires change on the SAC protocol. The address preparation procdure in DHCP can be simplified if the layer-3 gateway is a switch and there is only one host connected to one port. The port number can be used as an unspoofable identifer of the host. Then the host doesn't have to generate an identifer and the gateway just remember which address has been allocated to which port. 3.2. Identifier Generation After preparing an address, a node must request the use right of the address from the first-hop layer-3 gateway. It tells the gateway "who I am, and which address I want to use". So there must be a field in the request packet to show the identity of the applicant, and the value of the field must be unspoofable. Again we choose CGA to help generate an identifier of the applicant. In DHCP and SAC cases, CGA works well. However, in manully configuration case, the identifier must be stateful and contain fixed infomation of the applicant, because the applicant must tell the gateway that he is the very person who owns the address, but not a random person. Then stateless CGA generation is not appropriate. We choose using a shared secret to authenticate the identity of a node in all manually Bi, et al. Expires November 2, 2008 [Page 7] =0C Internet-Draft ipv6-firsthop-authentication May 2008 cases. This means if one knows a correct shared secret, it will get the ownership of the corresponding address. So the shared secret must be protected in message change and must avoid replay attack. Adding state into CGA generation is one possible way of solving the problem. For example, the shared secret between the applicant and the gateway is combined with the public key and a random nonce to generate an address. Then the shared secret will not be leaked, and the gateway can recompute the address to find whether the secret is correct. Using CGA as identifer actually wastes the left-most 64 bits. However, the form of a CGA address is kept and it can be used in other purposes. For example, this mechanism can cooperate with SEND protocol using the CGA identifier. The whole procedule of identifier generation is described as follows: The node MUST generate an identifier. The identifier is a CGA address whose left-most 64 bits is the network prefix and the right- most 64 bits is generated according to [CGA] except for any address allocation method using manually configuration . In case of the address is configured manually, a share secret MUST be allocated between the node and the gateway previously. The shared secret is a bit string longer than 256 bits(this number is to be decided in the future). The node MUST generate a random number of 128 bits as a nonce. Then the right-most 64 bits of the identifier is computed by combining the public key, the shared secret, the nonce and auxiliary parameters. The shared secret MUST be allocated manually, but not using any key exchange protocol, for the source address of the applicant has not been authorized. If a node wants to use another address, it CAN use another public key and identifier or an existing identifer. The security of the identifier MUST be guaranteed by the node itself, which means the public key pair MUST not be leaked. IP spoofing caused by purposive leak will not be stopped by this mechanism. There MUST be no public key duplication in the same network. The uniqueness will be checked by the gateway. Once a duplicate public key is found to generate an identifier, the gateway will return an error and ask the applicant to use another public key. 3.3. Address Request After preparing the address and the identifier, a node MUST send a request packet to the gateway. This packet is an ICMP packet, named Bi, et al. Expires November 2, 2008 [Page 8] =0C Internet-Draft ipv6-firsthop-authentication May 2008 Seed Solicitation. Its format is shown in Fig.2. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum = | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Allocation Method | Prefix Length = | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | = | + = + | Nonce = | + = + | = | + = + | = | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | = | + = + | = | + CGA Identifier = + | = | + = + | = | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | = | . = . . CGA Option = . . = . | = | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | = | . = . . RSA Signature Option = . . = . | = | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: The format of Seed Solicitation message IP Fields: Source Address: The address prepared in the first stage. Destination Address: This portion MUST be filled with the IP address of the first-hop layer-3 gateway. Bi, et al. Expires November 2, 2008 [Page 9] =0C Internet-Draft ipv6-firsthop-authentication May 2008 Hop Limit: 1 or more. Generally 1 is enough, but there may be some externsion in the future. For example, the gateway is not one hop away from the node, but several hops. ICMP Fields: Type: TBD Code: TBD Checksum: The ICMP checksum. Address Allocation Method: Index of address allocation method, which shows by which method the applicant gets the address. Now: 1: Manually 2: DHCP 3: SAC 4: CGA 5: NAT 6: DHCP-PD Prefix Length: Only used in DHCP-PD case. It helps to get the request prefix. Nonce: A random number that is used to anti-replay. CGA Identifier: The identifier generated in the phase of "Identifier Generation". Options: CGA Option: Described in [SeND]. RSA Signature Option: Described in [SeND]. Used to anthenticate the whole message. The destination address in the packet is got through RA message from the router. If the RA message is forged by some other node deliberately, the node will get deceived. This may cause information leak and the node may be not able to send any packet out. So the security of NDP SHOULD be protected. However, even SeND can't ensure that the sender of a RA message is actually a router. But we think the first-hop gateway has enough information to know the address of the first-hop router, and it SHOULD filter forged RA message and prevent forged RA message reach any node on local link. 3.4. Gateway Authorizing Address In this phase, the gateway checks whether the applicant has the right to use the request address. This validation is based on the knowledge of address allocation. If the address is able to be used Bi, et al. Expires November 2, 2008 [Page 10] =0C Internet-Draft ipv6-firsthop-authentication May 2008 by the applicant, a bit string named "signature seed" will be returned to he applicant. Whenever the gateway receives a SS packet, firstly it performs following checks: o Check if the CGA identifier of the packet is a valid CGA identifier corresponding to the CGA option. If not, drop it. If the address allocation method is manually configure, the gateway gets the share serect of the request address, and recomputes the identifier to check whether it is correct. o Check if the signature in RSA signature option is correct. If not, drop it. o Check if the public key and the CGA identifier is duplicate to already registered public keys and CGA identifiers. If only the public key is duplicate, return an ICMP message to ask the applicant to generate another key pair. If both are duplicate, check if the nonce is different from the previous entry. If yes, drop the packet; if no, this may happen for a multi-homing node, or a node requesting a former address. This situation will be discussed in the future. Then the gateway will check whether the applicant has the right to use the request address. In different address allocation methods, the gateway checks different things. o Manually allocation: Once the packet passes the former check on CGA identifier, the share secret has already been validated. So no more check is needed here. o DHCP: The address MUST be the one that the DHCP server has allocated to the applicant owning the same CGA identifier in the packet. This means the gateway has to perform DHCP snooping to know the association of address and identifier. This knowledge has been got in the first phase. o Stateless Auto Configuration: The address MUST have not been registered in the gateway. This means no one has the right to use this address yet. o Privacy: The address MUST have not been registered in the gateway. o CGA: The address MUST be unique and generated following the algorithm in [CGA]. If there are other restrictions on generating a CGA, e.g. the Sec value, they MUST be satisfied. Bi, et al. Expires November 2, 2008 [Page 11] =0C Internet-Draft ipv6-firsthop-authentication May 2008 Once the address is found to be able to be used by the applicant, the gateway will generate a random number called "signature seed". It is a bit string of 384 bits and MUST not be the same as any former signature seed. Then the gateway SHOULD keep an entry in a record table, which has following elements: Address, signature seed, CGA identifier, public key, Sec value, nonce. The "signature seed" is used to perform a lightweight authentication in the future. Then, a packet will be returned to the applicant. This packet is called Seed Advertisement(SA) message, and has following format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum = | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | = | | = | . = . . Signature Seed = . . = . | = | | = | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | = | + = + | = | + CGA Identifier = + | = | + = + | = | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | = | . = . . CGA Option = . . = . | = | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | = | . = . . RSA Signature Option = . . = . | = | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: The format of Seed Advertisement message Bi, et al. Expires November 2, 2008 [Page 12] =0C Internet-Draft ipv6-firsthop-authentication May 2008 IP Fields: Source Address: The address of the router. Destination Address: The address requested by the node. Hop Limit: 1 or more. ICMP Fields: Type: TBD Code: TBD Checksum: The ICMP checksum. Signature Seed: The signature seed generated by the gateway. This seed MUST be encrypted by the public key of the request node. CGA identifier: The CGA identifier of the gateway. Options: CGA Option: Described in [SeND]. RSA Signature Option: Described in [SeND]. Used to anthenticate the message. 3.5. Address Assignment A node MUST receive any Seed Advertisement packet whose destination is the address which it has requested, though the address is not being used by the node. When a node receives a Seed Advertisement message, firstly it checks whether the CGA identifier and the RSA signature are correct. If either of them is incorrect, drop the packet. Once the node gets a valid Seed Advertisement message from the gateway, it can use the request address. Then the node decrypts the signature seed field to get the signature seed, using its private key generated in the phase of "identifier generation". Bi, et al. Expires November 2, 2008 [Page 13] =0C Internet-Draft ipv6-firsthop-authentication May 2008 4. Address Authentication In the former stage, a node can get authorized to use an address and a share secret "signature seed" has been exchanged between the gateway and the node. Then normal packet communication will start. To authenticate normal packets, a signature must be added into the packets, and the gateway checks the signature. After the node gets the signature seed for the request address, all the packets sent out MUST be added a signature, and this signature MUST be checked by the gateway. 4.1. Signature Generation The host generates signatures from the signature-seed to sign packet. Here we propose three candidate method to generate a signature. o HMAC o Pseudo Random Number Generation HMAC is a mature algorithm and has been tested in many authentication mechanisms, such as IPSec. HMAC is robust for it is stateless, but it computes on each packet, which will limit the forward performance of the router. Though there have been some commercial products which use Pseudo Random Number Generation to generate one-time key, the dependability of this algorithm used in packet authentication must be tested generally. It is stateful so it fears packets out of order and packet dropping. But in perfect network condition, it is more effective than HMAC for it doesn't compute on packets and the signatures can be generated in advance. Other signature generation methods can also be used here. The only requirement is that the signature must change with each packet, to prevent sniffer and replay attack. NAT and DHCP-PD router MUST generate the signature for any packets they sent out. 4.2. Signature Adding The signature can be added into the packet in three ways: 1 IPSec Authentication Header: It is mature but may conflict with an existing AH. 2 A new option header: The signature is added as a new destination option header, or a new hop-by-hop option header. We have done Bi, et al. Expires November 2, 2008 [Page 14] =0C Internet-Draft ipv6-firsthop-authentication May 2008 similar work when implementing a prototype of SPM. 3 Address Rewrite: This is a new method that has been proposed by us recently and it may be a wrong method. In this method, signature is not added into the packet as an IP extension header, but used to mark the source IP address field. We propose this method for we found that the overhead of signature add and signature remove is the bottle-neck of an authentication method. These two operation require memory copy and memory copy is a dirty work. Morever, the location of signature also costs a lot for the head of IPv6 is chaining- structured. However, change on some fixed bits costs less. Because any field of an IP head has its meaning, the most safe way is changing the source address, for it is only used when the receiver wants to reply. The gateway can set up an inverse index table which maps signature to address, and if the signature contained in source address field is existing in the table, it rewrites the source address into the packet. The rationality of this method is based on a spatial and dynamic signature space. NAT and DHCP-PD router MUST add the signature for any packets they sent out. 4.3. Sending packet After inserting the signature extension header, the node send it out with the source address set to the applied address. 4.4. Router checking packet Whenever the router gets a packet, it will check whether the source address has been applied and whether the signature is correct. Because the router keeps mapping table from the address to the seed, it is very easy to verifying the signature. 4.5. Router transmiting packet If the signature in the packet is found to be correct, the router will remove the Access Network Authentication Header in the packet and then tranmit it. If the signature is inserted by rewriting the source address, it will fill the source address field with corresponding address. Bi, et al. Expires November 2, 2008 [Page 15] =0C Internet-Draft ipv6-firsthop-authentication May 2008 5. Some Consideration 5.1. Updating of the mapping table The mapping table of address and signature-seed should be updated regularly to prevent brute-force attack. The router should periodically send a notification to the host to ask them to update the signature-seed and generate new signatures. Older signature can pass the validation for a short time, but after that, only new signature is thought to be right. In APPA, update is not needed, because no brute-force attack would take effect, and also it is hard to keep synchronization of the signature if the signature-seed changes. 5.2. Cooperating with SEND SEND is of great importance to maintain a safe environment between the host and the router. Without SEND, the host and the router would be cheated at the very beginning and all the following steps would not be safe.Morever, the seed exchange process can be designed as an extension of SEND. 5.3. Deployment not on first-hop router It happens that some first-hop routers can not be update to perform this validation. This mechanism can also be deployed on a far gateway. The host should know the address of the gateway first, and then use the same method to get a !osignature-seed!+/- from the gateway. The basic mechanism is much the same. However, some details are needed to be thought through here. For example, the track of DHCP message on the far gateway may be not possible, and the gateway must communicate with the DHCP server. 5.4. Anti-Spoofing Ability The basic ability is that an attacker can not use any address that has been applied by others. This address can be allocated by any method. This mechanism can not prevent a host from using a lot of "reasonable" addresses. Because this behavior does not differ much from normal behavior. But we can limit the applying frequency of a link layer address. However, we can not trace to the host after knowing the address used by an attacker. Other mechanisms may be added to enhance the trace Bi, et al. Expires November 2, 2008 [Page 16] =0C Internet-Draft ipv6-firsthop-authentication May 2008 ability. Maybe a log of link layer address of the Seed Solicitation message will be kept in router. But link layer address can also be forged, we have to design a more effective mechanism. 5.5. Keep-alive The router MUST send keep-alive message to ensure that the address is still in use. If the addressb is not used by any host, the entry in the mapping table will be cleaned. This message can be authenticated by using the seed already exchanged. Details will be designed in the future document. 5.6. Other consideration Another problem in an access network is that a host can pretend another host to receive packets. There are two situations. The first one is that all the hosts are in a collision area, and a host can sniff packets sent to others. Encrypting the packet to the host is the only way to prevent such sniffing and our mechanism has provided good basics for such encrypting. Because the worst behavior of an attacker is sniffing, stopping sniffing is enough. The other situation is that all the hosts are in different collision areas. An attacker can send spoofed ND message to the router in order to get packets form another host. Using SEND is a good choice to prevent such attack. Attacks in such situation are more serious for the victim can not communicate normally and its IP could be used by others without any awareness. Bi, et al. Expires November 2, 2008 [Page 17] =0C Internet-Draft ipv6-firsthop-authentication May 2008 6. Acknowledgements The authors would like to acknowledge the contributors who provided helpful inputs on earlier versions of this document and Mark Williams who provided editorial support. The author gratefully acknowledges the contributions of Fred Baker, Jari Arkko, Christian Vogt, Xing Li, Pekka Savola, Lixia Zhang, Yan Shen, Lizhong Xie. Bi, et al. Expires November 2, 2008 [Page 18] =0C Internet-Draft ipv6-firsthop-authentication May 2008 7. References [CGA] "RFC 3972: Crystographically Generated Addresses(CGA)", March 2005. [Privacy] IBM, "RFC 3041: Privacy Extensions for Stateless Address Autoconfiguration in IPv6", January 2001. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [SAC] "RFC 2462: IP Address Autoconfiguration", December 1999. [SEND] Ericsson, "RFC 3971: SEcure Neighbor Discovery", March 2005. [Stateful DHCP] Cisco, "RFC 3315: Dynamic Host Configuration for IPv6", 2003. [Stateless DHCP] Cisco, "RFC 3716: Stateless Dynamic Host Configuration Protocol(DHCP) service for IPv6", 2004. Bi, et al. Expires November 2, 2008 [Page 19] =0C Internet-Draft ipv6-firsthop-authentication May 2008 Authors' Addresses Jun Bi CERNET Network Center, Tsinghua University Beijing 100084 China Email: junbi@cernet.edu.cn Jianping Wu CERNET Network Center, Tsinghua University Beijing 100084 China Email: jianping@cernet.edu.cn Guang Yao CERNET Network Center, Tsinghua University Beijing 100084 China Email: yaog@netarchlab.tsinghua.edu.cn Bi, et al. Expires November 2, 2008 [Page 20] =0C Internet-Draft ipv6-firsthop-authentication May 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Bi, et al. Expires November 2, 2008 [Page 21] =0C --Apple-Mail-6--268207904-- From fred@cisco.com Fri Jul 18 12:45:25 2008 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 809933A6AD6 for ; Fri, 18 Jul 2008 12:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.479 X-Spam-Level: X-Spam-Status: No, score=-106.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cko+ZLFfPXDw for ; Fri, 18 Jul 2008 12:45:18 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 9D21928C1FF for ; Fri, 18 Jul 2008 12:45:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,211,1215388800"; d="scan'208";a="67075735" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 18 Jul 2008 19:45:47 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m6IJjleJ028494; Fri, 18 Jul 2008 12:45:47 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6IJjlBJ013563; Fri, 18 Jul 2008 19:45:47 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jul 2008 12:45:47 -0700 Received: from stealth-10-32-244-218.cisco.com ([10.32.244.218]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jul 2008 12:45:47 -0700 From: Fred Baker To: Christian Vogt In-Reply-To: <3E27B09A-9FCB-4E9D-A8E4-5CDFFBDCD56E@nomadiclab.com> X-Priority: 3 References: <74216AB8-6350-479B-9653-C059E34EA335@nomadiclab.com> <3E27B09A-9FCB-4E9D-A8E4-5CDFFBDCD56E@nomadiclab.com> Message-Id: <2F18A2B5-88E7-4A14-A912-2CE92EC3DB9B@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 18 Jul 2008 12:45:40 -0700 X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 18 Jul 2008 19:45:47.0441 (UTC) FILETIME=[DFD8F210:01C8E90E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2727; t=1216410347; x=1217274347; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[savi]=20SAVI=20solution=20proposal=20f rom=20Jun=20Bi=20et=20al. |Sender:=20; bh=upa08UXt2tXODXmYgZCKlWCZywnC8sGaYPqnysc6Fg8=; b=YCgFuVIoja3+ECEojS1NTUzawLR+RcdPriLU4yXL5jZRe1Dn3+XwY6BQbO J/86qv5nHQXRP925Kjfs3wZU0DjQe1B8oN1nOvDoGDOoLBJjbZXUVAppwiqf MoXDdaVVVO; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Guang Yao , SAVI Mailing List Subject: Re: [savi] SAVI solution proposal from Jun Bi et al. 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, 18 Jul 2008 19:45:25 -0000 Gee. Could we get these things posted as internet drafts? On Jul 18, 2008, at 12:34 PM, Christian Vogt wrote: > I am forwarding to you a SAVI solution proposal from Jun Bi et > al., as well as a first review of this proposal from myself. > Reviews and comments from other folks are very welcome, of course. > > Kind regards, > - Christian > > > > Begin forwarded message: > >> From: Christian Vogt >> Date: July 18, 2008 15:36:08 GMT+03:00 >> To: Jun Bi , Jianping Wu >> , >> Guang Yao >> Cc: Bill Fenner , Jari Arkko >> >> Subject: Comments on Your SAVI Proposal >> >> Jun, Jianping, and Guang, >> >> thanks for working so quickly on this proposal. You should >> definitely >> present it at the SAVI session in Dublin. I have put you on the >> agenda. >> >> I must note, though, that the proposal is not fully compliant with >> the >> SAVI charter in two ways: (i) It requires host changes, which the >> SAVI charter prohibits, and (ii) it performs host authentication, >> which also goes beyond the SAVI charter. This means that there will >> likely be skeptical comments at the microphone to which you should be >> prepared. The prospective SAVI solution will have to affect a >> compromise between effectiveness (security) and non-intrusiveness (no >> false packet drops, backwards compatibility, small configuration >> overhead). Your proposal errs on the side of security in this >> trade-off space, Fred's proposal, for one, errs on the side >> of non-intrusiveness. I believe the prospective SAVI solution will >> lie between the two. In any case, it will have to lie within the >> charter limits. >> >> A comment of technical nature: Your proposal supports different >> address configuration methods (autonomous, DHCP, privacy, CGA, >> manual). In one of them, the DHCP case, you require a cryptographic >> binding between the initial address generation and the registration >> of >> this address with the SAVI enforcement point. You are doing this >> even >> at the cost of changing the DHCP protocol. Why is such a binding >> required in the DHCP case, and why not in other cases? Considered >> homogenizing this? >> >> - Christian >> >> >> >> On Jul 17, 2008, at 9:06, Jun Bi wrote: >> >>> Dear Jari and Christian, >>> >>> This is a draft we want to submit. Please give us some advice. >>> >>> Best Regards, Jun Bi > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From junbi@tsinghua.edu.cn Fri Jul 18 12:50:55 2008 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 529503A6A56 for ; Fri, 18 Jul 2008 12:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5ebnrwSVxcg for ; Fri, 18 Jul 2008 12:50:54 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id E62C43A6A40 for ; Fri, 18 Jul 2008 12:50:53 -0700 (PDT) Received: from [59.66.53.132] (helo=userPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.63) (envelope-from ) id 1KJvzS-0002XT-LH; Sat, 19 Jul 2008 03:51:42 +0800 Message-ID: From: "Jun Bi" To: "Christian Vogt" , "SAVI Mailing List" References: <74216AB8-6350-479B-9653-C059E34EA335@nomadiclab.com> <3E27B09A-9FCB-4E9D-A8E4-5CDFFBDCD56E@nomadiclab.com> In-Reply-To: <3E27B09A-9FCB-4E9D-A8E4-5CDFFBDCD56E@nomadiclab.com> Date: Sat, 19 Jul 2008 03:51:14 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 Cc: Guang Yao Subject: Re: [savi] SAVI solution proposal from Jun Bi et al. X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jun Bi List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2008 19:50:55 -0000 Dear Christian, First thank you for the comments. We worked about one year on this draft, including implementing the code in Linux and doing experiments. A paper that described this method is accepted by IEEE LCN 2008 (local computer network conference). We are enhancing the method, so we welcome comments. 1 For the case that user is able to control the first layer2 hop equipment (e.g upgrading ALL Ethernet Switches), we have another solution draft: http://www3.ietf.org/proceedings/staging/draft-wu-sava-solution-firsthop-eap-01.txt. (Gang Ren plans to present this EAP draft). 2 For other cases (e.g. for a big campus network like Tsinghua U. some Ethernet switches are owned by different department and the total number of switches is huge. It's hard to upgrade all switches quickly), we propose this draft. We are designing this protocol as an extension of SeND. So if you think SeND could be considered as part of SAVI (not host change, not "authentication"),then this draft should be within the charter scope. 3 The solution will be deployed at the first layer3 hop equipment, so it won't conflict with the solutions for the first layer2 hop which is either Fred's proposal or the EAP extention draft above for IPv6. The user can enable one of them or enable both. 4 To meet all kinds of address allocation methods is reuqired by the charter. In the DHCP case, we need to know that exactly who applyed and got the assigned address. In the stateless cases, we just need to know the address is being used. In the manual case, the address is binded with the share key with the address is allocated. That's why we consider to have different ways. thank you again, Jun Bi ----- Original Message ----- From: "Christian Vogt" To: "SAVI Mailing List" Cc: "Guang Yao" Sent: Saturday, July 19, 2008 3:34 AM Subject: [savi] SAVI solution proposal from Jun Bi et al. >I am forwarding to you a SAVI solution proposal from Jun Bi et > al., as well as a first review of this proposal from myself. > Reviews and comments from other folks are very welcome, of course. > > Kind regards, > - Christian > > > > Begin forwarded message: > >> From: Christian Vogt >> Date: July 18, 2008 15:36:08 GMT+03:00 >> To: Jun Bi , Jianping Wu >> , >> Guang Yao >> Cc: Bill Fenner , Jari Arkko >> Subject: Comments on Your SAVI Proposal >> >> Jun, Jianping, and Guang, >> >> thanks for working so quickly on this proposal. You should definitely >> present it at the SAVI session in Dublin. I have put you on the >> agenda. >> >> I must note, though, that the proposal is not fully compliant with the >> SAVI charter in two ways: (i) It requires host changes, which the >> SAVI charter prohibits, and (ii) it performs host authentication, >> which also goes beyond the SAVI charter. This means that there will >> likely be skeptical comments at the microphone to which you should be >> prepared. The prospective SAVI solution will have to affect a >> compromise between effectiveness (security) and non-intrusiveness (no >> false packet drops, backwards compatibility, small configuration >> overhead). Your proposal errs on the side of security in this >> trade-off space, Fred's proposal, for one, errs on the side >> of non-intrusiveness. I believe the prospective SAVI solution will >> lie between the two. In any case, it will have to lie within the >> charter limits. >> >> A comment of technical nature: Your proposal supports different >> address configuration methods (autonomous, DHCP, privacy, CGA, >> manual). In one of them, the DHCP case, you require a cryptographic >> binding between the initial address generation and the registration of >> this address with the SAVI enforcement point. You are doing this even >> at the cost of changing the DHCP protocol. Why is such a binding >> required in the DHCP case, and why not in other cases? Considered >> homogenizing this? >> >> - Christian >> >> >> >> On Jul 17, 2008, at 9:06, Jun Bi wrote: >> >>> Dear Jari and Christian, >>> >>> This is a draft we want to submit. Please give us some advice. >>> >>> Best Regards, Jun Bi > > > -------------------------------------------------------------------------------- > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From junbi@cernet.edu.cn Mon Jul 21 05:32:00 2008 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 EFDDC28C0E9 for ; Mon, 21 Jul 2008 05:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.698 X-Spam-Level: ** X-Spam-Status: No, score=2.698 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 Xs1jK+YHYfDN for ; Mon, 21 Jul 2008 05:32:00 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id AEBE428C0E7 for ; Mon, 21 Jul 2008 05:31:59 -0700 (PDT) Received: from userPC([59.66.24.198]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm10488489de; Mon, 21 Jul 2008 20:32:35 +0800 Message-ID: <1B2A875DE4CB4E2A929E5755E952D864@userPC> From: "Jun Bi" To: Date: Mon, 21 Jul 2008 20:32:28 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0153_01C8EB70.E4CA8040" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: xQJ9uUUB Subject: [savi] SAVI meeting at IETF 72 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, 21 Jul 2008 12:32:01 -0000 ÕâÊÇ MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_0153_01C8EB70.E4CA8040 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,All, As you might already know, the SAVI meeting is scheduled on July 28 = Monday afternoon 17:40-19:50. The WG is seeking for the second notes taker (an English native speaker = would be better). If anybody is interested, please let us know. Best Regards, Jun Bi ------=_NextPart_000_0153_01C8EB70.E4CA8040 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,All,
 
As you might already know, the SAVI meeting is = scheduled on=20 July 28 Monday afternoon 17:40-19:50.
The WG is seeking for the second notes taker (an = English=20 native speaker would be better).
If anybody is interested, please let us = know.
 
Best Regards,
Jun Bi
 
 
 
------=_NextPart_000_0153_01C8EB70.E4CA8040-- From jari.arkko@piuha.net Thu Jul 24 15:18:26 2008 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 240783A6A38 for ; Thu, 24 Jul 2008 15:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFlNu2s7J6ER for ; Thu, 24 Jul 2008 15:18:25 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 73B3A3A6A74 for ; Thu, 24 Jul 2008 15:18:24 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 22D0D198723; Fri, 25 Jul 2008 01:18:23 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id AD8DC1986D6; Fri, 25 Jul 2008 01:18:22 +0300 (EEST) Message-ID: <4888FFC4.9050102@piuha.net> Date: Fri, 25 Jul 2008 01:18:44 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: savi@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Christian Vogt Subject: [savi] WG created 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, 24 Jul 2008 22:18:26 -0000 FYI -- the WG has now been officially created. Please find information about chairs, advisors and secretaries below. Thank you Bill, Christian, Jianping, and Jun for agreeing to be a part of the team to run the WG! The group will meet in Dublin. Christian and Bill -- please send out the agenda that I know you have. Jari Source Address Validation Improvements (SAVI) --------------------------------------------------- Last modified: 2008-07-12 Co-chairs Christian Vogt Bill Fenner Internet Area Directors: Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Technical Advisor(s): Jianping WU Secretary(ies): Jun Bi Mailing Lists: https://www.ietf.org/mailman/listinfo/savi While ingress filtering [RFC 2827, BCP 38] provides a way to validate IP source addresses at an aggregated level, there is not yet a standardized mechanism for IP source address validation at a finer granularity. Having a finer granularity would be helpful in a number of situations, including filtering traffic from customer interfaces implemented as ports in a layer 3 aware bridge or a router, general improvements in filtering accuracy in enterprise networks, etc. Depending on the situation, there may be a requirement for blocking spoofed packets or merely logging packets that appear to be spoofed. Partial solutions exist to prevent nodes from spoofing the IP source address of another node in the same IP link (e.g., the "IP source guard"), but are proprietary. The purpose of the proposed "Source Address Validation Improvements" working group is to standardize mechanisms that prevent nodes attached to the same IP link from spoofing each other's IP addresses. The scope of the WG is as follows: - The working group considers only solutions implemented on systems located on the same IP link as a to-be-verified node. The goal of the working group is the LAN environment and solutions running in routers or layer 3 aware Ethernet bridges. - Both IPv4 and IPv6 need to be covered. - The first goal of the working group is on unicast traffic, but using the same mechanisms to police multicast traffic is also within the scope. - All address assignment mechanisms need to be supported, including stateless, stateful, and manual configuration; as well as privacy and cryptographically generated addresses. - Solutions are preferably based on observing user traffic, or on observing or using existing signaling protocols. Examples of protocols that can be useful to observe/use are ARP, Neighbor Discovery, DHCP, and DHCP Prefix Delegation protocols. Observing addresses in IP headers can also be useful. The gathered information is used to determine what IP source addresses in packets are appropriate. Where automatic operation is impossible or would lead to sub-optimal validation results, solutions may require manual configuration. - Interdomain scenarios (across Autonomous Systems) that require information from routing protocols like BGP are out of scope. Nevertheless, solution may observe routing protocol signaling to detect that a device is a router. - Tracking other protocols is not within the scope of the WG. - No changes to hosts are allowed. - The WG is prohibited from creating its own protocols or extensions/modifications of current protocols. These limitations in the scope may be relaxed through later rechartering. For instance, solutions tailored for PPP links and specific environments may be added later, or solutions involving co-operation of the nodes on the link may be developed once the baseline solutions have been completed. However, the WG is already chartered to work also on a solution for Ethernet-based broadband access networks that are used in DSL environments. This work is a specialization of the working group's primary LAN-based solution. In order to reach a result that is widely usable and unlikely to disturb existing network practices, the working group needs to take into account - nodes that use static addresses, - nodes with multiple IP addresses on the same interface, - nodes that use multiple link-layer addresses on the same interface, - nodes that have multiple interfaces to the same link, - attachment of another bridge at a bridge port, - presence of routers, NATs, and other similar devices on the same link, including their distinction from hosts with multiple interfaces or hosts with multiple IP addresses on a single interface, - use of SEcure Neighbor Discovery in some networks, - nodes that move to another port on the same link, and - hosts with anycast addresses. However, should such wide applicability turn out to be impossible, the working group will document the limitations of the solutions in due manner. In particular, it is likely that anycast addressing and nodes that employ multiple interfaces for load balancing at link layer are indistinguishable from an actual spoofing attack. There may also be a difference in the applicability between blocking and merely logging spoofed packets. In any case, the solutions may require to be explicitly turned on for each network or interface where they are applicable. For background information, the working group will also develop a threats analysis document that describes what threats the solutions from the WG protect against. This document also contrasts SAVI to existing solutions. Milestones: Jul 08 WG approval Aug 08 First WG draft on threats document Oct 08 First WG draft on IPv4 solution Oct 08 First WG draft on IPv6 solution Oct 08 Submit document on threats to IESG for Informational RFC Feb 09 First WG draft on solution for Ethernet-based broadband access network Mar 09 Submit IPv4 solution to IESG for Proposed Standard May 09 Submit IPv6 solution to IESG for Proposed Standard Oct 09 Submit Ethernet-based broadband access network solution to IESG for Proposed Standard From christian.vogt@nomadiclab.com Fri Jul 25 07:48:18 2008 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 B0A453A6A33 for ; Fri, 25 Jul 2008 07:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLTAPNK5E1-p for ; Fri, 25 Jul 2008 07:48:18 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id B89E33A6838 for ; Fri, 25 Jul 2008 07:48:14 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0C0E31EF24F; Fri, 25 Jul 2008 17:48:15 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id C8F4D1EF24E; Fri, 25 Jul 2008 17:48:14 +0300 (EEST) Message-Id: <61A920E3-088B-4B87-979B-099AF6F8B989@nomadiclab.com> From: Christian Vogt To: SAVI Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 25 Jul 2008 17:48:14 +0300 X-Mailer: Apple Mail (2.926) X-Virus-Scanned: ClamAV using ClamSMTP Subject: [savi] Agenda for SAVI Meeting at IETF 72, Dublin 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, 25 Jul 2008 14:48:18 -0000 Folks, the agenda of our upcoming SAVI working group meeting: Charter and goals of the SAVI working group 10 min=0B Christian Vogt, Bill Fenner Design taxonomy for SAVI solutions 15 min=0B Christian Vogt, Bill Fenner Switch-based source address validation 15 min=0B Fred Baker, draft-baker-sava-implementation-00 Host-to-host source address validation 15 min=0B Fred Baker, draft-baker-sava-implementation-00 First-hop source address authorization and authentication 15 min Jun Bi, draft-sava-solution-ipv6-firsthop-authentication-00 Source address validation in local subnet environment 15 min=0B Gang Ren, draft-wu-sava-solution-firsthop-eap-01 Recommendations for SAVI 15 min=0B Erik Nordmark Discussion 30 min The meeting will take place on Monday, July 28, 2008, 17:40 - 19:50, in Ballroom 1 at the Citywest Hotel, Saggart, Co Dublin. Presenters should limit their talks to 10 min, if possible, to leave room for questions. - Christian From wwwrun@core3.amsl.com Fri Jul 25 04:16:56 2008 Return-Path: X-Original-To: savi@ietf.org Delivered-To: savi@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id BB6E43A6A9F; Fri, 25 Jul 2008 04:16:56 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20080725111656.BB6E43A6A9F@core3.amsl.com> Date: Fri, 25 Jul 2008 04:16:56 -0700 (PDT) X-Mailman-Approved-At: Fri, 25 Jul 2008 08:08:31 -0700 Cc: fenner@research.att.com, savi@ietf.org, christian.vogt@ericsson.com Subject: [savi] WG Action: Source Address Validation Improvements (savi) X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2008 11:16:56 -0000 A new IETF working group has been formed in the Internet Area. For additional information, please contact the Area Directors or the WG Chairs. Source Address Validation Improvements (savi) ----------------------------------------------------------- Last Modified: 2008-07-25 Chair(s): Christian Vogt [christian.vogt@ericsson.com] Bill Fenner [fenner@research.att.com] Internet Area Director(s): Jari Arkko [jari.arkko@piuha.net] Mark Townsley [townsley@cisco.com] Internet Area Advisor: Jari Arkko [jari.arkko@piuha.net] Technical Advisor(s): Jianping Wu [jianping@cernet.edu.cn] Secretary(ies): Jun Bi [junbi@cernet.edu.cn] Mailing Lists: General Discussion: savi@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/savi Archive: http://www.ietf.org/mail-archive/web/savi/current/maillist.html Description of Working Group: While ingress filtering [RFC 2827, BCP 38] provides a way to validate IP source addresses at an aggregated level, there is not yet a standardized mechanism for IP source address validation at a finer granularity. Having a finer granularity would be helpful in a number of situations, including filtering traffic from customer interfaces implemented as ports in a layer 3 aware bridge or a router, general improvements in filtering accuracy in enterprise networks, etc. Depending on the situation, there may be a requirement for blocking spoofed packets or merely logging packets that appear to be spoofed. Partial solutions exist to prevent nodes from spoofing the IP source address of another node in the same IP link (e.g., the "IP source guard"), but are proprietary. The purpose of the proposed "Source Address Validation Improvements" working group is to standardize mechanisms that prevent nodes attached to the same IP link from spoofing each other's IP addresses. The scope of the WG is as follows: - The working group considers only solutions implemented on systems located on the same IP link as a to-be-verified node. The goal of the working group is the LAN environment and solutions running in routers or layer 3 aware Ethernet bridges. - Both IPv4 and IPv6 need to be covered. - The first goal of the working group is on unicast traffic, but using the same mechanisms to police multicast traffic is also within the scope. - All address assignment mechanisms need to be supported, including stateless, stateful, and manual configuration; as well as privacy and cryptographically generated addresses. - Solutions are preferably based on observing user traffic, or on observing or using existing signaling protocols. Examples of protocols that can be useful to observe/use are ARP, Neighbor Discovery, DHCP, and DHCP Prefix Delegation protocols. Observing addresses in IP headers can also be useful. The gathered information is used to determine what IP source addresses in packets are appropriate. Where automatic operation is impossible or would lead to sub-optimal validation results, solutions may require manual configuration. - Interdomain scenarios (across Autonomous Systems) that require information from routing protocols like BGP are out of scope. Nevertheless, solution may observe routing protocol signaling to detect that a device is a router. - Tracking other protocols is not within the scope of the WG. - No changes to hosts are allowed. - The WG is prohibited from creating its own protocols or extensions/modifications of current protocols. These limitations in the scope may be relaxed through later rechartering. For instance, solutions tailored for PPP links and specific environments may be added later, or solutions involving co-operation of the nodes on the link may be developed once the baseline solutions have been completed. However, the WG is already chartered to work also on a solution for Ethernet-based broadband access networks that are used in DSL environments. This work is a specialization of the working group's primary LAN-based solution. In order to reach a result that is widely usable and unlikely to disturb existing network practices, the working group needs to take into account - nodes that use static addresses, - nodes with multiple IP addresses on the same interface, - nodes that use multiple link-layer addresses on the same interface, - nodes that have multiple interfaces to the same link, - attachment of another bridge at a bridge port, - presence of routers, NATs, and other similar devices on the same link, including their distinction from hosts with multiple interfaces or hosts with multiple IP addresses on a single interface, - use of SEcure Neighbor Discovery in some networks, - nodes that move to another port on the same link, and - hosts with anycast addresses. However, should such wide applicability turn out to be impossible, the working group will document the limitations of the solutions in due manner. In particular, it is likely that anycast addressing and nodes that employ multiple interfaces for load balancing at link layer are indistinguishable from an actual spoofing attack. There may also be a difference in the applicability between blocking and merely logging spoofed packets. In any case, the solutions may require to be explicitly turned on for each network or interface where they are applicable. For background information, the working group will also develop a threats analysis document that describes what threats the solutions from the WG protect against. This document also contrasts SAVI to existing solutions. Goals and Milestones: Jul 2008 WG approval Aug 2008 First WG draft on threats document Oct 2008 First WG draft on IPv4 solution Oct 2008 First WG draft on IPv6 solution Oct 2008 Submit document on threats to IESG for Informational RFC Feb 2009 First WG draft on solution for Ethernet-based broadband access network Mar 2009 Submit IPv4 solution to IESG for Proposed Standard May 2009 Submit IPv6 solution to IESG for Proposed Standard Oct 2009 Submit Ethernet-based broadband access network solution to IESG for Proposed Standard From junbi@cernet.edu.cn Sun Jul 27 15:15:35 2008 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 5E15F3A6A04 for ; Sun, 27 Jul 2008 15:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.057 X-Spam-Level: ** X-Spam-Status: No, score=2.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 xHMcPKXTJQMH for ; Sun, 27 Jul 2008 15:15:34 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id DE5863A6809 for ; Sun, 27 Jul 2008 15:15:30 -0700 (PDT) Received: from userPC([130.129.64.64]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jmb488d5876; Mon, 28 Jul 2008 06:15:36 +0800 Message-ID: <8AD38A9345F641A4A2D967730C19E659@userPC> From: "Jun Bi" To: "Fred Baker" , "Christian Vogt" References: <74216AB8-6350-479B-9653-C059E34EA335@nomadiclab.com><3E27B09A-9FCB-4E9D-A8E4-5CDFFBDCD56E@nomadiclab.com> <2F18A2B5-88E7-4A14-A912-2CE92EC3DB9B@cisco.com> In-Reply-To: <2F18A2B5-88E7-4A14-A912-2CE92EC3DB9B@cisco.com> Date: Sun, 27 Jul 2008 23:15:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: lae6OXUB Cc: Guang Yao , SAVI Mailing List Subject: Re: [savi] SAVI solution proposal from Jun Bi et al. X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2008 22:15:35 -0000 Hi All, This is the latest version of the proposal, which I will present tomorrow: http://www.ietf.org/internet-drafts/draft-bi-savi-csa-00.txt Please give us your valuable comments. Thank you! Best Regards, Jun bi ----- Original Message ----- From: "Fred Baker" To: "Christian Vogt" Cc: "Guang Yao" ; "SAVI Mailing List" Sent: Friday, July 18, 2008 8:45 PM Subject: Re: [savi] SAVI solution proposal from Jun Bi et al. > Gee. Could we get these things posted as internet drafts? > > On Jul 18, 2008, at 12:34 PM, Christian Vogt wrote: > >> I am forwarding to you a SAVI solution proposal from Jun Bi et >> al., as well as a first review of this proposal from myself. >> Reviews and comments from other folks are very welcome, of course. >> >> Kind regards, >> - Christian >> >> >> >> Begin forwarded message: >> >>> From: Christian Vogt >>> Date: July 18, 2008 15:36:08 GMT+03:00 >>> To: Jun Bi , Jianping Wu , >>> Guang Yao >>> Cc: Bill Fenner , Jari Arkko >>> Subject: Comments on Your SAVI Proposal >>> >>> Jun, Jianping, and Guang, >>> >>> thanks for working so quickly on this proposal. You should definitely >>> present it at the SAVI session in Dublin. I have put you on the >>> agenda. >>> >>> I must note, though, that the proposal is not fully compliant with the >>> SAVI charter in two ways: (i) It requires host changes, which the >>> SAVI charter prohibits, and (ii) it performs host authentication, >>> which also goes beyond the SAVI charter. This means that there will >>> likely be skeptical comments at the microphone to which you should be >>> prepared. The prospective SAVI solution will have to affect a >>> compromise between effectiveness (security) and non-intrusiveness (no >>> false packet drops, backwards compatibility, small configuration >>> overhead). Your proposal errs on the side of security in this >>> trade-off space, Fred's proposal, for one, errs on the side >>> of non-intrusiveness. I believe the prospective SAVI solution will >>> lie between the two. In any case, it will have to lie within the >>> charter limits. >>> >>> A comment of technical nature: Your proposal supports different >>> address configuration methods (autonomous, DHCP, privacy, CGA, >>> manual). In one of them, the DHCP case, you require a cryptographic >>> binding between the initial address generation and the registration of >>> this address with the SAVI enforcement point. You are doing this even >>> at the cost of changing the DHCP protocol. Why is such a binding >>> required in the DHCP case, and why not in other cases? Considered >>> homogenizing this? >>> >>> - Christian >>> >>> >>> >>> On Jul 17, 2008, at 9:06, Jun Bi wrote: >>> >>>> Dear Jari and Christian, >>>> >>>> This is a draft we want to submit. Please give us some advice. >>>> >>>> Best Regards, Jun Bi >> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > > From christian.vogt@nomadiclab.com Mon Jul 28 04:20:47 2008 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 443823A67E6 for ; Mon, 28 Jul 2008 04:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 X33AGwjCM5dC for ; Mon, 28 Jul 2008 04:20:46 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 5AFB53A67BD for ; Mon, 28 Jul 2008 04:20:46 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 3F2E81EF131; Mon, 28 Jul 2008 14:20:54 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id D5D061EF123; Mon, 28 Jul 2008 14:20:53 +0300 (EEST) Message-Id: From: Christian Vogt To: SAVI Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 28 Jul 2008 12:20:53 +0100 X-Mailer: Apple Mail (2.926) X-Virus-Scanned: ClamAV using ClamSMTP Subject: [savi] Update: Agenda for SAVI Meeting at IETF 72, Dublin 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, 28 Jul 2008 11:20:47 -0000 Agenda for SAVI Meeting at IETF 72, Dublin ------------------------------------------ Agenda bashing 5 min Charter and goals of the SAVI working group 10 min=0B Christian Vogt, Bill Fenner Design taxonomy and analysis for SAVI solutions 10 min=0B Christian Vogt, Jari Arkko Switch-based source address validation 15 min=0B Fred Baker, draft-baker-sava-implementation-00 Host-to-host source address validation 15 min=0B Fred Baker, draft-baker-sava-implementation-00 First-hop source address authorization and authentication 15 min Jun Bi, draft-bi-savi-csa-00 Source address validation in local subnet environment 15 min=0B Gang Ren, draft-wu-sava-solution-firsthop-eap-01 Recommendations for SAVI 15 min=0B Erik Nordmark Discussion 30 min The meeting will take place on Monday, July 28, 2008, 17:40-19:50, in Ballroom 1 at the Citywest Hotel. Presenters, please send me your slides if you haven't done so already. Thanks! - Christian From fred@cisco.com Mon Jul 28 09:18:57 2008 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 A977B28C1F0 for ; Mon, 28 Jul 2008 09:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.336 X-Spam-Level: X-Spam-Status: No, score=-106.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIZWkRAQ16gp for ; Mon, 28 Jul 2008 09:18:52 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 479EE28C1ED for ; Mon, 28 Jul 2008 09:18:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,266,1215388800"; d="scan'208";a="15613016" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 28 Jul 2008 16:19:01 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6SGJ1dg006844; Mon, 28 Jul 2008 18:19:01 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6SGJ1YU002253; Mon, 28 Jul 2008 16:19:01 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jul 2008 18:19:00 +0200 Received: from macs-computer.meeting.ietf.org ([10.61.97.179]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jul 2008 18:19:00 +0200 Message-Id: <76AF0532-CB72-498F-8923-9EFBC0288F0B@cisco.com> From: Fred Baker To: savi-chairs@tools.ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 28 Jul 2008 17:18:59 +0100 X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 28 Jul 2008 16:19:00.0378 (UTC) FILETIME=[A4CADFA0:01C8F0CD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=98; t=1217261941; x=1218125941; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Slides=20for=20IETF=2072 |Sender:=20; bh=wPJEtinZzTHvi4iH7mmANPeacZyetlqk/6+doWo+cQc=; b=owlm9J6MvUaNCDP197I293WovVUyXNExIbElvme5DpOnw29SZO6tZiRHUl 7WeUH28Mw0ZaTtec35xxj3Rx4M4JBDe6oBXqtUZERZFWwQLmxoxvYqM7FNw4 T7Ks9rmehC; Authentication-Results: ams-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: SAVI Mailing List Subject: [savi] Slides for IETF 72 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, 28 Jul 2008 16:18:57 -0000 You may find my slides for today at ftp://ftpeng.cisco.com/fred/savi/SAVI-Guard-IETF72.ppt From pekkas@netcore.fi Fri Aug 1 03:27:36 2008 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 0162528C3EE for ; Fri, 1 Aug 2008 03:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 nm3ydLwtHUAP for ; Fri, 1 Aug 2008 03:27:35 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 83EB128C3EC for ; Fri, 1 Aug 2008 03:27:34 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m71ARpPw014097 for ; Fri, 1 Aug 2008 13:27:51 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m71ARob5014093 for ; Fri, 1 Aug 2008 13:27:51 +0300 Date: Fri, 1 Aug 2008 13:27:50 +0300 (EEST) From: Pekka Savola To: savi@ietf.org Message-ID: User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.93.1/7903/Thu Jul 31 21:51:18 2008 on otso.netcore.fi X-Virus-Status: Clean Subject: [savi] DNS-spoofing (fwd) 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, 01 Aug 2008 10:27:36 -0000 This may be of interest here -- if the enterprise or ISP provides a DNS resolver on the same link as hosts, current anti-spoofing solutions won't work (however, the DNS server's host firewall could have some ACL on the interface), and a SAVI solution could be useful. ---------- Forwarded message ---------- Date: Thu, 31 Jul 2008 20:47:12 +0200 From: Patrik Wallstrom To: namedroppers@ops.ietf.org Subject: DNS-spoofing John Dickinson demonstrated on the dnsext wg meeting today that you can spoof a local DNS reslover in 95ms. The resolver had a fixed source port. -- patrik_wallstrom->foodfight->pawal@blipp.com->+46-733173956 From sean@donelan.com Sat Aug 2 20:33:51 2008 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 7624B3A6830 for ; Sat, 2 Aug 2008 20:33:51 -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 Xa7EX+pQDx3f for ; Sat, 2 Aug 2008 20:33:50 -0700 (PDT) Received: from clifden.donelan.com (clifden.donelan.com [208.72.84.6]) by core3.amsl.com (Postfix) with ESMTP id BB9843A695D for ; Sat, 2 Aug 2008 20:33:50 -0700 (PDT) Received: from sean (helo=localhost) by clifden.donelan.com with local-esmtp (Exim 4.69) (envelope-from ) id 1KPUMH-0000kj-SZ; Sat, 02 Aug 2008 23:34:13 -0400 Date: Sat, 2 Aug 2008 23:34:13 -0400 (EDT) From: Sean Donelan To: Pekka Savola In-Reply-To: Message-ID: <200808022315050.32BF5B92.2857@clifden.donelan.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: savi@ietf.org Subject: Re: [savi] DNS-spoofing (fwd) X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2008 03:33:51 -0000 On Fri, 1 Aug 2008, Pekka Savola wrote: > This may be of interest here -- if the enterprise or ISP provides a DNS > resolver on the same link as hosts, current anti-spoofing solutions won't > work (however, the DNS server's host firewall could have some ACL on the > interface), and a SAVI solution could be useful. There are current (although not always standardized) anti-spoofing solutions for most types of local network technology. Some ISPs already prevent other customers from any spoofing addresses on the same link, and enterprises can use similar technology to prevent internal hosts on the same network from spoofing external (and hopefully other internal) addresses. Default settings and painful configuration means they aren't always used. You are correct some local networks, i.e. the traditional thick-coax ethernet, probably will always be vulnerable to local spoofing without some other controls. But if you are on a shared thick-coax ethernet, you can already use promiscious sniffing, and could already generate the poisoned DNS reply with one packet. That's one of the reasons why ISPs in the 1990's (after a couple of newsworthy incidents) changed their network architectures, and (should) avoid hosts connected to shared data link networks with customer traffic. From fergdawg@netzero.net Sat Aug 2 20:54:36 2008 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 232B13A687A for ; Sat, 2 Aug 2008 20:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 hDd-Yize4byt for ; Sat, 2 Aug 2008 20:54:35 -0700 (PDT) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 47E243A67DA for ; Sat, 2 Aug 2008 20:54:35 -0700 (PDT) Received: from outbound-bu1.vgs.untd.com (webmail04.vgs.untd.com [10.181.12.144]) by smtpout01.vgs.untd.com with SMTP id AABEKLL9GARC9RGJ for (sender ); Sat, 2 Aug 2008 20:54:14 -0700 (PDT) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPY4JTTQHXKwTltxkCoJc6W2v3C3M2ds/DA== Received: (from fergdawg@netzero.net) by webmail04.vgs.untd.com (jqueuemail) id NRMZ8Z6Y; Sat, 02 Aug 2008 20:53:31 PDT Received: from [76.103.61.74] by webmail04.vgs.untd.com with HTTP: Sun, 3 Aug 2008 03:52:59 GMT X-Originating-IP: [76.103.61.74] Mime-Version: 1.0 From: "Paul Ferguson" Date: Sun, 3 Aug 2008 03:52:59 GMT To: sean@donelan.com X-Mailer: Webmail Version 4.0 Message-Id: <20080802.205259.13696.0@webmail04.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 18:9:1388330983 X-MAIL-INFO: 2dea8bae8b0f8ec79eae0f9e0fe76ebb5e5e4a97d35e6adbe71a8ac3636bf3f3c76fcaea8b X-UNTD-Peer-Info: 10.181.12.144|webmail04.vgs.untd.com|outbound-bu1.vgs.untd.com|fergdawg@netzero.net Cc: savi@ietf.org Subject: Re: [savi] DNS-spoofing (fwd) X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2008 03:54:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Sean Donelan wrote: >On Fri, 1 Aug 2008, Pekka Savola wrote: >> This may be of interest here -- if the enterprise or ISP provides a D= NS = >> resolver on the same link as hosts, current anti-spoofing solutions >> won't work (however, the DNS server's host firewall could have some = ACL >> on the interface), and a SAVI solution could be useful. > >There are current (although not always standardized) anti-spoofing = solutions for most types of local network technology. Some ISPs already= = prevent other customers from any spoofing addresses on the same link, an= d = enterprises can use similar technology to prevent internal hosts on the = = same network from spoofing external (and hopefully other internal) = addresses. Default settings and painful configuration means they aren't= always used. > >You are correct some local networks, i.e. the traditional thick-coax = ethernet, probably will always be vulnerable to local spoofing without = some other controls. But if you are on a shared thick-coax ethernet, you can already use promiscious sniffing, and could already generate the= = poisoned DNS reply with one packet. That's one of the reasons why ISPs in the 1990's (after a couple of newsworthy incidents) changed their network architectures, and (should) avoid hosts connected to shared = data link networks with customer traffic. > So I'm not really sure what your point is here, Sean... Are you arguing that source-address validation is somehow unneeded, or perhaps that existing technologies already exist to fix the problem? If so, then I think that the SAVI WG is indeed correct in stating that "While ingress filtering [RFC 2827, BCP 38] provides a way to validateIP source addresses at an aggregated level, there is not yet a standardized mechanism for IP source address validation at a finer granularity." I think that SAVI is beneficial in the case of DNS spoofing issues, too. If you don't agree, I think you may be in the minority here. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIlSuYq1pz9mNUZTMRAvNeAKCoaU6E0FmA+wlNg199L276cm1ZMACdEtTN 02EZx7N3brWDnFP2IRvwgR8=3D =3Dfvlh -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ From sean@donelan.com Sat Aug 2 22:11:20 2008 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 BF96A3A6B31 for ; Sat, 2 Aug 2008 22:11:20 -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 FyJ3q92BZsAF for ; Sat, 2 Aug 2008 22:11:20 -0700 (PDT) Received: from clifden.donelan.com (clifden.donelan.com [208.72.84.6]) by core3.amsl.com (Postfix) with ESMTP id 18DB73A6B2E for ; Sat, 2 Aug 2008 22:11:20 -0700 (PDT) Received: from sean (helo=localhost) by clifden.donelan.com with local-esmtp (Exim 4.69) (envelope-from ) id 1KPVsT-0000nM-Jy; Sun, 03 Aug 2008 01:11:33 -0400 Date: Sun, 3 Aug 2008 01:11:33 -0400 (EDT) From: Sean Donelan To: Paul Ferguson In-Reply-To: <20080802.205259.13696.0@webmail04.vgs.untd.com> Message-ID: <200808030105450.32BF5B92.3055@clifden.donelan.com> References: <20080802.205259.13696.0@webmail04.vgs.untd.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: savi@ietf.org Subject: Re: [savi] DNS-spoofing (fwd) X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2008 05:11:20 -0000 On Sun, 3 Aug 2008, Paul Ferguson wrote: > Are you arguing that source-address validation is somehow unneeded, > or perhaps that existing technologies already exist to fix the > problem? If so, then I think that the SAVI WG is indeed correct > in stating that "While ingress filtering [RFC 2827, BCP 38] provides > a way to validateIP source addresses at an aggregated level, there > is not yet a standardized mechanism for IP source address validation > at a finer granularity." > > I think that SAVI is beneficial in the case of DNS spoofing issues, > too. > > If you don't agree, I think you may be in the minority here. You have re-stated exactly what I said. There is not a standardized method. Lack of a standard doesn't mean you should wait to do something now. SAVI will be useful in the future. In the mean time, please don't wait to read the vendor manuals and use whatever non-standardized tools exist. From dkong@bbn.com Tue Aug 12 10:14:25 2008 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 449BC3A67FE for ; Tue, 12 Aug 2008 10:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 fx2vfYif-1dF for ; Tue, 12 Aug 2008 10:14:24 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 941FA3A69E3 for ; Tue, 12 Aug 2008 10:14:24 -0700 (PDT) Received: from dhcp89-089-075.bbn.com ([128.89.89.75]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1KSxRM-0007yd-D9 for savi@ietf.org; Tue, 12 Aug 2008 13:13:48 -0400 Mime-Version: 1.0 (Apple Message framework v753.1) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: savi@ietf.org From: Derrick Kong Date: Tue, 12 Aug 2008 13:13:47 -0400 X-Mailer: Apple Mail (2.753.1) Subject: [savi] Minutes/summary of SAVI session at IETF? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 17:14:25 -0000 Hello, Does anyone have a summary/minutes of the SAVI session at IETF? There doesn't seem to be an audio archive of session available sadly. Derrick Kong dkong@bbn.com From shanna@juniper.net Wed Aug 13 11:48:53 2008 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 F212B3A6B66 for ; Wed, 13 Aug 2008 11:48:52 -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 9Y9-A+pXPCAO for ; Wed, 13 Aug 2008 11:48:51 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 3661C3A6A44 for ; Wed, 13 Aug 2008 11:48:50 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Wed, 13 Aug 2008 11:48:37 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 11:47:55 -0700 Received: from antipi.jnpr.net ([10.10.2.34]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 11:47:55 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Aug 2008 14:47:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Aug 2008 14:47:53 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [savi] Minutes/summary of SAVI session at IETF? Thread-Index: Acj8nuMY2SqLDOihQXWpzuMWmAWQJgAwhc+Q References: From: "Stephen Hanna" To: "Derrick Kong" , X-OriginalArrivalTime: 13 Aug 2008 18:47:53.0878 (UTC) FILETIME=[182ECB60:01C8FD75] Subject: Re: [savi] Minutes/summary of SAVI session at IETF? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 18:48:53 -0000 Derrick Kong wrote: > Does anyone have a summary/minutes of the SAVI session at IETF? =20 > There doesn't seem to be an audio archive of session available sadly. Yes, I was disappointed to find SAVI missing from the audio archive. Here's a WG summary that I wrote up this week. Thanks, Steve ----------- SAVI WG Report, IETF 72 Christian Vogt and Bill Fenner co-chaired the first meeting of the SAVI WG. Slides and agenda for this meeting are available from https://datatracker.ietf.org/meeting/72/materials.html Minutes should be available from there soon. The audio recording did not seem to work. Here is a brief summary of the meeting. Christian started by summarizing the charter and goals of the SAVI WG. IP source address spoofing is used for various unpleasant purposes: DDOS, circumventing access controls, etc. Source address validation can eliminate or reduce these problems. Three source address validation technologies exist but are not ideal. Ingress filtering and unicast Reverse Path Forwarding (RPF) are very coarse. Cisco's IPv4 Source Guard is not standardized. SAVI aims to provide source address validation on a single link (i.e. before the first-hop router). Broader scopes can be addressed with different technologies. The SAVI charter dictates certain requirements and constraints. For instance, SAVI cannot require host changes and must work by observing existing protocols. Christian then presented a framework and taxonomy of SAVI solutions. The framework is that a SAVI solution maintains a database of bindings. A binding is a linkage between a source IP address and a binding anchor (a switch port or lower-layer address). The lifecycle of a binding is: 1) SAVI solution establishes binding 2) SAVI solution verifies binding 3) SAVI solution enforces binding (if conflicts detected) The taxonomy has the following axes: Which binding anchor? A) Switch port B) Link layer address How are bindings verified? A) Check sending host (direct) B) Ask other hosts (indirect) How are binding conflicts handled? A) Drop packets that clash with binding B) Reverify binding Christian's slides lay out a list of challenges (e.g. host mobility across switch ports with the same source IP address) and analyzes whether the various options handle these challenges. Questions were raised about whether this framework and taxonomy span all the possible solutions to this problem. Fred Baker described the solutions laid out in his draft, draft-baker-sava-implementation-00.txt. These mainly involve snooping DHCP for IPv4 and Neighbor Discovery for IPv6. Erik Nordmark pointed out that an attacker who spoofs MAC and IP on a non-switched LAN can't be detected. Fred agreed. Gang Ren described the solution laid out in his draft, draft-wu-sava-solution-firsthop-eap-01.txt. He suggests having the RADIUS server send the IP address in the Access-Accept. He admitted this only works for 802.1X but still thinks it's good. Others asked why change protocols? The same thing can be accomplished with DHCP snooping at the switch. Jun Bi described the solution laid out in his draft, draft-sava-solution-ipv6-firsthop-authentication-00.txt. Hosts sign packets using AH or a new option header. If Cryptographically Generated Addresses (CGA) are used (with IPv6), this can establish the host's right to use the address. Concerns were raised that this requires changes to the hosts and protocols. Erik Nordmark gave a presentation. He admitted that there are lots of tricky issues and situations here. We must make a tradeoff between complexity and features. Erik suggested a simple system (described in his slides) where switches would watch which port uses a source IP address. Whoever uses it first gets to keep it as long as they respond to pings. See his slides for more details. Someone pointed out that many endpoints don't respond to pings these days. Erik said use ARP. Someone else said this doesn't span switches. Erik said that could be added. Someone pointed out this isn't very secure. True, said Erik. We could make it more secure but then it will be more complex. Steve Hanna mentioned that IF-MAP (to be discussed during SAAG) will provide a central database that can be used to manage source IP address assignments and relate those to ports, MAC addresses, and user identity. In the discussion at the end, questions were raised about the purpose of the group. Should we protect against spoofing by off-link parties? Some thought yes, some no. From christian.vogt@nomadiclab.com Fri Aug 15 12:57:51 2008 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 2CB003A69B5 for ; Fri, 15 Aug 2008 12:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35] 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 4LRgrdeylCke for ; Fri, 15 Aug 2008 12:57:50 -0700 (PDT) Received: from mo-p05-ob.rzone.de (mo-p05-ob.rzone.de [81.169.146.180]) by core3.amsl.com (Postfix) with ESMTP id 0BF953A6818 for ; Fri, 15 Aug 2008 12:57:49 -0700 (PDT) X-RZG-CLASS-ID: mo05 X-RZG-AUTH: :IW0NeQWrc+lwhhNjh1Z2K6NdlYX3YUP3q0u9XxCmBv0JYNpM/EzGTpIl Received: from 12-187-208-235.att-inc.com ([12.187.208.235]) by post.webmailer.de (fruni mo61) (RZmta 16.47) with ESMTP id o01335k7FIHbWN ; Fri, 15 Aug 2008 21:57:46 +0200 (MEST) (envelope-from: ) Message-Id: <036F052D-7C8E-478D-8FF9-64DCC42C8738@nomadiclab.com> From: Christian Vogt To: Stephen Hanna In-Reply-To: Content-Type: multipart/mixed; boundary=Apple-Mail-4-4896306 Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 15 Aug 2008 12:57:44 -0700 References: X-Mailer: Apple Mail (2.926) Cc: Derrick Kong , SAVI Mailing List Subject: Re: [savi] Minutes/summary of SAVI session at IETF? 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, 15 Aug 2008 19:57:51 -0000 --Apple-Mail-4-4896306 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Aug 13, 2008, Stephen Hanna wrote: > Here's a WG summary that I wrote up this week. Attached are further meeting minutes by Jun Bi. Thank you, Stephen and Jun, for your help! - Christian --Apple-Mail-4-4896306 Content-Disposition: attachment; filename="Minutes of SAVI Meeting at IETF 72" Content-Type: application/octet-stream; x-mac-creator=21526368; x-unix-mode=0644; x-mac-type=54455854; name="Minutes of SAVI Meeting at IETF 72" Content-Transfer-Encoding: quoted-printable SAVI=20Meeting=20at=20IETF=2072,=20Dublin=0D=0A= -------------------------------=0D=0A=0D=0AMonday,=20July=2028,=202008,=20= 17:40-19:50,=0D=0Ain=20Ballroom=201=20at=20the=20Citywest=20Hotel.=0D=0A=0D= =0A=0D=0ACharter=20and=20goals=20of=20SAVI=20WG=0D=0AChristian=20Vogt=20= and=20Bill=20Fenner=0D=0A=0D=0AChristian=20Vogt=20introduces=20the=20= agenda=20and=20WG=20formation.=0D=0AChristian=20Vogt:=0D=0A1=20why=20we=20= need=20SAVI=0D=0A2=20current=20solution=20are=20not=20sufficient=0D=0A3=20= possible=20solution=20scopes=0D=0A4=20SAVI=20goals=20and=20requirements=0D= =0A5=20challenges=0D=0A6=20deliverables=0D=0A=20=0D=0ADave:=20why=20= broadband=20solution=20is=20in=20addition=20to=20ipv4/IPv6=20solutions=0D= =0AJari=20Arkko:=20DSL=20has=20different=20technologies=20may=20require=20= different=20solutions.=0D=0ADave:=20Need=20a=20problem=20statement=0D=0A= Bill:=20need=20feedback=20on=20what=20deployment=20is=20different.=20= Maybe=20do=20it=20later.=0D=0A=20=0D=0A=0D=0ADesign=20taxonomy=20and=20= analysis=20for=20SAVI=20solutions=20=20=20=20=0D=0AChristian=20Vogt,=20= Jari=20Arkko=0D=0A=20=0D=0AYoshihiro,=20Toshiba:=20address=20may=20be=20= updated=20after=20the=20initial=20validation=0D=0A=20=0D=0A=0D=0ASAVI=20= source=20guard=20=20=20=20=20=20=20=20=20=20=20=20=20=0D=0AFred=20Baker,=20= draft-baker-sava-implementation-00=0D=0A=0D=0A1=20for=20switched=20LAN=0D= =0A2=20for=20non-switched=20LAN=0D=0A3=20value=20of=20source=20address=20= versification=0D=0A4=20security=20consideration=0D=0A=0D=0AFred=20Baker:=20= Like=20what=20I=20presented=20in=20the=20BoF,=20here=20I=20am=20going=20= to=20show=20there=20is=20one=20possible=20solution=20somebody:=20which=20= threat=20to=20be=20handled?=20If=20somebody=20spoof=20with=20the=20same=20= MAC=20and=20IP,=20you=20can't=20tell=20where=20the=20packet=20came=20= from.=0D=0AFred=20Baker:=20Looking=20for=20adding=20some=20other=20= security.=0D=0A=0D=0A=0D=0ASource=20address=20validation=20in=20first=20= hop=20local=20subnet=20environment=20=20=20=20=20=20=20=0D=0AGang=20Ren,=20= draft-wu-sava-solution-firsthop-eap-01=0D=0A=20=0D=0AErik=20Nordmark:=20= can=20it=20handle=20the=20host=20moving=20to=20different=20port=0D=0A= Gang:=20currently=20no,=20but=20will=20try=20to=20support=20in=20the=20= next=20version.=0D=0AErik=20Nordmark,=20Fred=20Baker,=20Jari:=20=20= Should=20support=20more=20address=20assign=20methods.=20Should=20= consider=20to=20minimize=20the=20protocol=20changes.=0D=0ASomebody:=20= too=20much=20enquiry,=20why=20not=20using=20existing=20protocol=20to=20= do=20some=20functions.=0D=0AGang=EF=BC=9AProtocol=20changes=20currently=20= are=20limited,=20and=20will=20make=20modification=20to=20follow=20the=20= advices.=0D=0A=0D=0A=0D=0AA=20CGA=20based=20source=20address=20= authorization=20and=20authentication=20for=20the=20first=20Layer-3=20hop=20= =20=0D=0AJun=20Bi,=20draft-bi-savi-csa-00=0D=0A=20=0D=0ABaker,=20Erick:=20= different=20user=20uses=20different=20address=20or=20same=20address?=0D=0A= Jun:=20It=20depends=20on=20what=20existing=20address=20assignment=20= method=20the=20administrator=20wants=20to=20use.=20The=20solution=20= supports=20both,=20so=20it's=20beyond=20the=20mechanism=20discussion.=0D=0A= =20=0D=0AFred=20Baker,=20Jari:=20Address=20rewrite=20may=20have=20= problem=0D=0AJun:=20not=20test=20it=20yet,=20will=20consider=20it=20will=20= work=20or=20it's=20wrong.=0D=0A=20=0D=0AChristian=20Vogt:=20in=20the=20= phase=201,=20may=20use=20SEND=20directly,=20without=20extension.=0D=0A= Jun:=20good=20suggestion,=20we=20are=20looking=20to=20minimize=20of=20= the=20protocol=20extension,=20will=20study=20it.=0D=0A=20=0D=0AChristian=20= Vogt:=20Regarding=20to=20the=20host=20change,=20it=20depends=20on=20how=20= much=20it=20will=20change.=20If=20we=20really=20need=20host=20change=20= to=20handle=20a=20specific=20scenario=20and=20the=20change=20is=20not=20= too=20much,=20then=20it=20will=20be=20acceptable.=0D=0A=20=0D=0A=0D=0A= SAVI=20thoughts=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=0D=0AErik=20Nordmark,=20no=20draft.=0D=0A=0D=0A= Somebody:=20Track=20what=20trust=20computing=20group=20do.=0D=0ABill=20= Fenner:=20the=20direction.=20Current=20charter=20prevent=20host=20A=20= using=20host=20B's=20address,=20do=20we=20need=20to=20deal=20with=20= off-link=20address,=20etc.=0D=0AFred=20Baker:=20to=20find=20the=20one=20= who=20is=20responsible=20for=20the=20address,=20then=20need=20to=20deal=20= any=20forged=20address.=0D=0AJari:=20I=20support=20to=20prevent=20using=20= off-link=20address,=20but=20need=20to=20consider=20what=20we=20can=20do.=0D= =0ASomebody:=20I=20am=20curious=20how=20much=20spoofing=20in=20the=20= DHCP=20case=20(?)=0D=0APascal:=20If=20can=20do=20the=20validation=20on=20= multicasting,=20it=20would=20be=20better.=0D=0ASomebody:=20only=20= authorized=20address=20would=20be=20used.=0D=0APekka:=20Assuming=20= router=20can=20only=20use=20uRPF=0D=0ASomebody:=20but=20the=20= granularity=20is=20only=20prefix=20based,=20which=20is=20not=20enough.=0D= =0ABill=20Fenner:=20the=20accountability=20is=20important.=0D=0A=20=0D=0A= Bill=20Fenner:=20thank=20you=20for=20attending,=20to=20follow=20the=20= discussion=20on=20the=20mailing=20list.=0D=0A=0D=0A= --Apple-Mail-4-4896306-- From zhangdong_rh@huaweisymantec.com Wed Aug 20 02:03:51 2008 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 4A86E3A69F1 for ; Wed, 20 Aug 2008 02:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.888 X-Spam-Level: * X-Spam-Status: No, score=1.888 tagged_above=-999 required=5 tests=[AWL=1.887, BAYES_50=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 oYUEI-B8JSOK for ; Wed, 20 Aug 2008 02:03:50 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id 49C473A698E for ; Wed, 20 Aug 2008 02:03:50 -0700 (PDT) MIME-version: 1.0 Content-disposition: inline Content-type: text/plain; charset=utf-8 Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0K5W00I476I4W430@hstga02-in.huaweisymantec.com> for savi@ietf.org; Wed, 20 Aug 2008 17:03:40 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0K5W00FO06I3MR00@hstml02-in.huaweisymantec.com> for savi@ietf.org; Wed, 20 Aug 2008 17:03:40 +0800 (CST) Received: from [10.27.140.206] by hstml02-in.huaweisymantec.com (mshttpd); Wed, 20 Aug 2008 17:03:39 +0800 From: ZhangDong To: Jun Bi , Jianping Wu , yaog@netarchlab.tsinghua.edu.cn Message-id: Date: Wed, 20 Aug 2008 17:03:39 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal Content-transfer-encoding: quoted-printable Cc: savi@ietf.org Subject: [savi] review: draft-bi-savi-csa-00.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: Wed, 20 Aug 2008 09:13:25 -0000 Processor Bi=2C Wu and Yao=2C =3C If the node is an IPv4 node=2C the only different case is DHCP=2E = The =3C node cannot use a CGA address to send a DHCP solicitation=2E This= can =3C be solved by using the address as an identifier=2C but not as a =3C locator=2E The CGA address in contained in the packet as an optio= n=2C =3C and the host id of the IPv4 address is the hash of the CGA address= =2E =3C The signature is computed on the whole packet=2E Here=2C I wonder whether the host id of the IPv4 address created by the = hash of the CGA address will bring a collision=2E In other words=2C the = host id of the IPv4 address may already be used=2E Perhaps=2C it should = has a duplicate detection=2E Best regards=2E ----------- Dong Zhang Huawei Symantec Technologies Co=2E=2C Ltd TEL=EF=BC=9A010-82829263 ADDRESS=EF=BC=9AHarbour Networks P=26D Center=2E Building 17=2C ZhongGua= nCun Software Park=2C No=2E8=2C = Dongbeiwang West Road=2C HaiDian District=2C Beijing=2C C= hina=2E From zhangdong_rh@huaweisymantec.com Wed Aug 20 02:52:48 2008 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 0BBD93A6BB4 for ; Wed, 20 Aug 2008 02:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.042 X-Spam-Level: X-Spam-Status: No, score=-0.042 tagged_above=-999 required=5 tests=[AWL=2.557, 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 POrAm6g1YgsM for ; Wed, 20 Aug 2008 02:52:47 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id 3A2973A69ED for ; Wed, 20 Aug 2008 02:52:47 -0700 (PDT) MIME-version: 1.0 Content-disposition: inline Content-type: text/plain; charset=utf-8 Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0K5W00IGE8S5W430@hstga02-in.huaweisymantec.com> for savi@ietf.org; Wed, 20 Aug 2008 17:52:54 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0K5W00FPD8S3MR00@hstml02-in.huaweisymantec.com> for savi@ietf.org; Wed, 20 Aug 2008 17:52:52 +0800 (CST) Received: from [10.27.140.206] by hstml02-in.huaweisymantec.com (mshttpd); Wed, 20 Aug 2008 17:52:51 +0800 From: ZhangDong To: savi@ietf.org Message-id: Date: Wed, 20 Aug 2008 17:52:51 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal Content-transfer-encoding: quoted-printable Subject: [savi] review: draft-bi-savi-csa-00.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: Wed, 20 Aug 2008 09:52:48 -0000 Processor Bi=2C Wu and Yao=2C =3C If the node is an IPv4 node=2C the only different case is DHCP=2E = The =3C node cannot use a CGA address to send a DHCP solicitation=2E This= can =3C be solved by using the address as an identifier=2C but not as a =3C locator=2E The CGA address in contained in the packet as an optio= n=2C =3C and the host id of the IPv4 address is the hash of the CGA address= =2E =3C The signature is computed on the whole packet=2E Here=2C I wonder whether the host id of the IPv4 address created by the = hash of the CGA address will bring a collision=2E In other words=2C the = host id of the IPv4 address may already be used=2E Perhaps=2C it should = has a duplicate detection=2E Best regards=2E ----------- Dong Zhang Huawei Symantec Technologies Co=2E=2C Ltd TEL=EF=BC=9A010-82829263 ADDRESS=EF=BC=9AHarbour Networks P=26D Center=2E Building 17=2C ZhongGua= nCun Software Park=2C No=2E8=2C = Dongbeiwang West Road=2C HaiDian District=2C Beijing=2C C= hina=2E From zhangdong_rh@huaweisymantec.com Wed Aug 20 20:51:09 2008 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 C86DC3A6832 for ; Wed, 20 Aug 2008 20:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.869 X-Spam-Level: * X-Spam-Status: No, score=1.869 tagged_above=-999 required=5 tests=[AWL=-0.377, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_GB2312=1.345] 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 ykSw9B+XYY9G for ; Wed, 20 Aug 2008 20:51:08 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id 63AA43A6801 for ; Wed, 20 Aug 2008 20:51:08 -0700 (PDT) MIME-version: 1.0 Content-disposition: inline Content-type: text/plain; charset=utf-8 Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0K5X00346MNVB510@hstga02-in.huaweisymantec.com> for savi@ietf.org; Thu, 21 Aug 2008 11:50:20 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0K5X005EVMNUAT00@hstml02-in.huaweisymantec.com> for savi@ietf.org; Thu, 21 Aug 2008 11:50:19 +0800 (CST) Received: from [10.27.140.206] by hstml02-in.huaweisymantec.com (mshttpd); Thu, 21 Aug 2008 11:50:18 +0800 From: ZhangDong To: Guang Yao , 'Jun Bi' Message-id: Date: Thu, 21 Aug 2008 11:50:18 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <000b01c902bc$e003c360$a00b4a20$@tsinghua.edu.cn> References: <6EC4290A25844DD38F1D89D3D608BAB0@userPC> <000b01c902bc$e003c360$a00b4a20$@tsinghua.edu.cn> Content-transfer-encoding: quoted-printable Cc: savi@ietf.org Subject: [savi] =?gb2312?b?u9i4tDogtPC4tDogcmV2aWV3OiBkcmFmdC1iaS1zYXZp?= =?gb2312?b?LWNzYS0wMC50eHQ=?= 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, 21 Aug 2008 03:51:09 -0000 Guang=2C I can understand most of your explanation=2E However=2C there is another= point I want to ask=2E =3E 2 Even collision happens=2C it will not bring any trouble=2E Hosts = can=27t = =3E announce the ownership of this address by a DHCP solicitation=2E It = can = =3E just use it once to send a DHCP solicitation=2E It seems that a host use one temporary address to solicit another addres= s from the DHCP server=2E = I remember the DHCP server sends the DHCPoffer message by broadcast=2E = So if it is=2C the host will not need a source address=2E That is to say= the temporary address may be redundant=2E Thanks=2E ----------- Dong Zhang Huawei Symantec Technologies Co=2E=2C Ltd TEL=EF=BC=9A010-82829263 ADDRESS=EF=BC=9AHarbour Networks P=26D Center=2E Building 17=2C ZhongGua= nCun Software Park=2C No=2E8=2C = Dongbeiwang West Road=2C HaiDian District=2C Beijing=2C C= hina=2E ----- =E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6 ----- =E5=8F=91=E4=BB=B6=E4=BA=BA=3A Guang Yao =3Cyaoa02=40mails=2Etsinghua=2E= edu=2Ecn=3E =E6=97=A5=E6=9C=9F=3A 2008=E5=B9=B4 8=E6=9C=88 20=E6=97=A5=2C =E6=98=9F=E6= =9C=9F=E4=B8=89=2C =E4=B8=8B=E5=8D=888=3A02 =E4=B8=BB=E9=A2=98=3A =E7=AD=94=E5=A4=8D=3A review=3A draft-bi-savi-csa-= 00=2Etxt =E6=94=B6=E4=BB=B6=E4=BA=BA=3A zhangdong=5Frh=40huaweisymantec=2Ecom =E6=8A=84=E9=80=81=3A =27Jun Bi=27 =3Cjunbi=40cernet=2Eedu=2Ecn=3E =3E Dear Dong Zhang=2C =3E = =3E The collision problem of CGA address exists both in IPv4 and IPv6=2E= In = =3E IPv4=2C this problem is more serious=2E This draft just gives a poss= ible = =3E solution=2C and many details should be modified in the future=2C = =3E especially in IPv4=2E =3E I will try to explain why we didn=27t put forward the collision pro= blem = =3E seriously=2E =3E 1 Actually=2C the IPv4 address doesn=27t have to be the hash of the= CGA = =3E identifier=2E It can be any valid address in the local address space= =2E It = =3E is just a temporary address=2C not a permanent address=2E = =3E = =3E 2 Even collision happens=2C it will not bring any trouble=2E Hosts = can=27t = =3E announce the ownership of this address by a DHCP solicitation=2E It = can = =3E just use it once to send a DHCP solicitation=2E =3E = =3E 3 However=2C we choose that the host id should be generated by hash= ing = =3E the CGA=2E This is because we want to control address space exhausti= on=2E = =3E In DHCP=2C one host can request the ownership of all the possible = =3E addresses=2E The collision will slow the speed of application=2E The= = =3E gateway will check the collision of address in DHCP solicitation and= = =3E drop collision request packets=2E But we do think this is will bring= s = =3E much trouble and maybe using other addresses to send DHCP solicitati= on = =3E will be more reasonable=2E =3E = =3E However=2C thanks for your proposition=2E Duplicate detection will = be = =3E firstly considered if we find using a duplicated temporary address = =3E will trouble the existing mechanisms=2C e=2Eg=2E=2C the layer-2 prot= ocol=2E =3E = =3E Best Regards=2C =3E Guang Yao =3E -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =3E =E5=8F=91=E4=BB=B6=E4=BA=BA=3A Jun Bi =5Bmailto=3Ajunbi=40cernet=2E= edu=2Ecn=5D = =3E =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=3A 2008=E5=B9=B48=E6=9C=8820=E6= =97=A5 17=3A58 =3E =E6=94=B6=E4=BB=B6=E4=BA=BA=3A yaoa02 =3E =E4=B8=BB=E9=A2=98=3A Fw=3A review=3A draft-bi-savi-csa-00=2Etxt =3E = =3E Could you reply=3F =3E thanks=2C =3E jun =3E ----- Original Message ----- = =3E From=3A =22ZhangDong=22 =3Czhangdong=5Frh=40huaweisymantec=2Ecom=3E= =3E To=3A =22Jun Bi=22 =3Cjunbi=40cernet=2Eedu=2Ecn=3E=3B =22Jianping W= u=22 = =3E =3Cjianping=40cernet=2Eedu=2Ecn=3E=3B = =3E =3Cyaog=40netarchlab=2Etsinghua=2Eedu=2Ecn=3E =3E Cc=3A =3Csavi=40ietf=2Eorg=3E =3E Sent=3A Wednesday=2C August 20=2C 2008 5=3A03 PM =3E Subject=3A review=3A draft-bi-savi-csa-00=2Etxt =3E = =3E = =3E Processor Bi=2C Wu and Yao=2C =3E = =3E =3C If the node is an IPv4 node=2C the only different case is DHC= P=2E The =3E =3C node cannot use a CGA address to send a DHCP solicitation=2E = This = =3E can =3E =3C be solved by using the address as an identifier=2C but not as = a =3E =3C locator=2E The CGA address in contained in the packet as an = option=2C =3E =3C and the host id of the IPv4 address is the hash of the CGA ad= dress=2E =3E =3C The signature is computed on the whole packet=2E =3E = =3E Here=2C I wonder whether the host id of the IPv4 address created by= the = =3E hash = =3E of the CGA address will bring a collision=2E In other words=2C the = host = =3E id of = =3E the IPv4 address may already be used=2E Perhaps=2C it should has a = =3E duplicate = =3E detection=2E =3E = =3E Best regards=2E =3E = =3E ----------- =3E Dong Zhang =3E Huawei Symantec Technologies Co=2E=2C Ltd =3E TEL=EF=BC=9A010-82829263 =3E ADDRESS=EF=BC=9AHarbour Networks P=26D Center=2E Building 17=2C Zho= ngGuanCun = =3E Software = =3E Park=2C No=2E8=2C =3E Dongbeiwang West Road=2C HaiDian District=2C Beijing= =2C China=2E =3E = =3E = =3E = =3E = =3E From marcelo@it.uc3m.es Mon Sep 22 08:56:42 2008 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 223F828C1AC for ; Mon, 22 Sep 2008 08:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.162 X-Spam-Level: X-Spam-Status: No, score=-1.162 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_BAD_ID=2.837, 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 OU9kFj0DMzpy for ; Mon, 22 Sep 2008 08:56:40 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 5B4B73A6B2D for ; Mon, 22 Sep 2008 08:56:28 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (r190-135-149-211.dialup.adsl.anteldata.net.uy [190.135.149.211])by smtp03.uc3m.es (Postfix) with ESMTP id B3E52649E98;Mon, 22 Sep 2008 17:56:24 +0200 (CEST) Message-ID: <48D7C026.6050609@it.uc3m.es> Date: Mon, 22 Sep 2008 17:56:22 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Fred Baker , danny@arbor.net, savi@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-21.9982 TC:1F TRN:92 TV:5.5.1026(16174.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [savi] comments on draft-mcpherson-savi-threat-scope-00 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2008 15:56:42 -0000 Hi, I have read draft-mcpherson-savi-threat-scope-00 and i have some comments and questions. In section 2. Overview it reads: Solutions such as BCP 38 [RFC 2827] provide guidelines for one such technique for network ingress filtering. However, if these techniques are not implemented on 32-bit prefix boundaries at the ultimate ingress point of the IP network then the validity of the source address can not be positively ascertained. Furthermore, BCP 38 only implies source address verification at the Internet Layer, and is most often implemented on IP subnetwork address boundaries. Right, but also i think we need to point out that BCP 38 is far from universal, so there are a lot of spoofed addresses around I mean, when i read the previous paragraph and the following one, i got the impression that the only problem is that BCP 38 allows hosts within the same IP subnet to spoof each other addresses, and that's it. So i guess i have a question and a comment: The question is, is the idea to assume that BGP38 is deployed and that we will perform the threat analysis and find solutions for residual threats that are not covered by bcp38, or are we supposed to deal with the source address spoofing in a orthogonal way to bcp 38? (i understadn this is not the case, cause later sections seem to be more general than this) If the question is that we are supposed to deal with the general problem and not only with the bcp 38 residual threats, i would suggest to rephrase both the previous and the following paragraph in order to make this clearer cause at least to me was a bit confusing. There is a possibility that in an LAN environment where multiple hosts share a single IP port on a switch or router, one of those hosts may source address spoof the source addresses of other hosts within the local subnet. Understanding these threats and the relevant topologies in which they're introduced is critical when assessing the threats that exists with source address spoofing. Later on in section 4.1.1. Single Packet DoS First of all, i am not sure if the title is the best one cause, the section discusses attacks that involve crashing the system, which seems to me a bit more than what i would call DoS. I would suggest to call this simply Single packet attacks maybe? I find the section a bit too general on spoofed information, rather than focussing and detailing the particular effects of source address spoofing, which should be the focus imho I mean, sending a single packet with spoofed information can generate an attack, indeed, Now, i guess the question is how many of these attacks rely on spoofing the source address? In other words, if we prevent spoofing the source address, do all these attacks go away? or is a subset of these attacks that disapear. I think the document should go a bit deeper into this and describe more in detail which address are enable thanks to source address spoofing and which could be completely prevented if we implement some source address validation. Moreover, the document could try to analyse if we did something like the scope of savi, like a local first hop verification, what is the set of these attacks that can be prevented? Later on in section 4.1.2. Flood-Based DoS I liked this section very much I think however, i may be worth to summarize which of these attacks are more relevant to SAVi and what can be expected from savi From what i understand from this section, there are 3 types of attacks described: - one or more attackers flooding using their own source address (i, this case, savi has nothing to do here, cause there is no source address spoofed involved) - one or more attackers flooding using spoofed source addresses (SVAI can help here, cause if savi is in place we would end up with the previous bullet only) - attackers sending an attack using spoofed source address, but the ultimate goal is to get those addresses filtered, creating a long term attack for those spoofed source addresses (actually this is DoS attack to the owners of the source addresses, which can no longer access to the server). this attack would be completely removed with savi Later in section 4.1.3. Poisoning Attacks I couldn't understand what is the difference between this section and section 4.1.1 Morevoer, i also think the comment i made for section 4.1.1. applies here, i.e. that i think the content should focus in the specifics of the attacks of soruce address spoofing and maybe also in the savi limited scope, i.e. the case of the first hop Later in section 4.1.4. Third Party Recon Right, this seems more like a preparation for an attack than an attack itself. I mean, do these attacks have a particular impact other than enabling the next attack? Now, what is the effect of source address spoofing? I mean, do attcker need to spoof the source address for this? Or do they spoof the source address in order not to reveal themselves? i don't think we can prevent these attacks with a mechanism to prevent source address spoofing. To what extent we can help with source address spoofing prevention? In with the limited scope of savi? Later in section 4.1.6. Reflective Attacks This makes perfect sense to me I guess that we could do the same with a download using a tcp connection from a server, with a spoofed address, so that the server download hits the victim which address was spoofed. Later on, in section 4.1.7. Accounting Subversion Do you have any specific protocol in mind that can be used for this? Later, in section 4.1.8. Other Blind Spoofing Attacks Other Blind spoofing attacks might include spoofing in order to exploit source routing or other policy based routing implemented in a network. i would also benefit from more text here, cause i fail to understand what you have in mind here Finally, what about attacks that imply injecting false routing information in the IGP? Do these need to be considered? I mean, routing protocols usually use the source address of the message to determine which router the message came from so, it seems that it would be an attractive target for an attcker, would this fall out of the scope of this analysis? If so, it may be worth mentioning. If not it may be worth analysing if these attacks should be included in the analysis. Later on 5.5. Spoofing In Local Area Network Segments On Link Layer segments where multiple hosts reside, or a single MAC address can be associated with a port or interface, if a binding between a hardware address (e.g., MAC address) and corresponding IP address(es) are not provisioned via some means (either manual or dynamic mechanisms), then an attacker may exploit attack vectors that enable MITM or other spoof-based attacks. This section is a bit strange, it reads more like a threat than as a solution.... In section 5.10.2. Automated Binding are you planning to discuss IPv6 stateless address autoconfig? I don't know, but when the iid is obtained from the mad address, it maybe be trivial to perform the mapping Later in section 5.11. Cryptographic Techniques Needless to say, MITM and replay attacks can typically be mitigated with cryptographic techniques. However, many of the applications today either don't or can't employ cryptographic authentication and protection mechanisms. I am not sure how this would help the source address spoofing problem I guess the crypto technique that could help, would the IPSec AH, since the source address is protected, but not clear how an intermediate wold would check that. Could be checked at the end point though However, i can't see how other of the availble crypte techniques could help with this particular problem ARP and DNS are two examples. DNSSEC does propose to assist, but until it's deployed ubiquitously, from clients, to resolvers, to authoritative roots, clients and resolvers are still vulnerable to replay, cache poisoning and MITM attacks. How is ARP an example? How DNSsec help with the problem of source address spoofing? I mean, it could mitigate some the attacks that can be generated with spoof source address, but i am uncertain how how dnssec can help with the problem of source spoofing We could talke about send and cgas, that even though they don't really tackle this problem, they seem close enough... later in section 6.1. Address Provisioning Mechanisms In a strictly static environment configuration management for access filters that map Link Layer and Network Layer addresses on a specific switch port might be a viable option. However, most networks, certainly, those that accommodate actual human users, are much more dynamic in nature. As such, mechanisms that provide port-MAC-IP bindings need to accommodate dynamic address allocation schemes enabled by protocols such as DHCP. i would explicitly mention IPv6 SAA maybe i would also mention dhcp prefix delegation Later in section 6.2.2. NATs Prefix-based and multi-address NATs also become problematic, for the same reasons as routers. Because they may forward traffic from an array of address, a priori knowledge must exist providing what IPs should be associated with a given port-MAC pair. I fail to see why nats are problematic. I mean, from the private side, nat is just as a router, so i don't think it deserves special consideration From the public side, the NAT only generates packets from its pools of public addresses, so, it is like a host with multiple IP addresses, which i don't think it is more problematic than a host with one address. You only need to associated multiple IP addresses to the MAC address and you are ok. So i fail to see what is specific to a nat that makes it worth discussing separated. 6.2.3. Multi-Instance Hosts I am not sure i understand what this is... it may be worth to include a definition of this in section 3. same goes for a blade server Later, 6.2.4. Multi-LAN Hosts How common is the usage of the loopback address? I am familair with its usage in bgp, but never heard it in other conext 6.2.6. Mobile IP Need to say something here, I think... Mobile IP Ok, let me do a first analysis of this MIP has 3/4 elements that need to be considered, the CN, the MN, the HA MIP4 only works in tunnel mode while mip6 works both in tunnel mode and in ro mode Let's think about the different cases MN in tunnel mode. It sends and receives packet form the HA in an IPsec tunnel with the right source address. no problem here afaict. (Actually, there were discussions about letting the MN to send the packet directly to the CN, but i understand that this was not done cause it would break with ingress filters :-) MN in ro mode. it also sends packets with the right source address, and includes the HoA in the HoA option, so no problem here CN in tunnel mode acts like a normal fixed host. CN in RO mode always sends packet with its won fixed address, so no problem here The HA in tunnel mode (HA is not involved in ro mode). I guess here is where the problems can arise. The HA is doing proxy ND, in order to capture the packets for the MN. when the MN is back home, it will claim the address back and we will see a change in the binding between the IP address and the MAC address. 6.2.7. Other Topologies maybe talking about proxy ND? Later in section 7. Applicability of Anti-Spoofing Solutions What works where, what's needed? Ingress filtering is useful, even with botnets using real addresses Ingress filtering on the admin border is not sufficient, and more fine-grained filtering from savi is necessary. i guess you are planning to expand on this? in particular, i am not sure i understand the second statement Later in section 8. Deployment Considerations I guess that another problem is that ISPs get paid for inyecting traffic, and if a client is sending packets with spoofed source address, but still paying, they don't have much incentives to filter this traffic. I guess that a solution to work, must put the right incentives in place, so that ISPs prefer droping packets with spoofed IP address from paying customers rather than forwarding them From danny@arbor.net Thu Oct 2 09:47:02 2008 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 61D2C3A6AB2 for ; Thu, 2 Oct 2008 09:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuCFlEuzm8qY for ; Thu, 2 Oct 2008 09:47:00 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 95AA03A6ABD for ; Thu, 2 Oct 2008 09:47:00 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id D302B26867C; Thu, 2 Oct 2008 10:47:20 -0600 (MDT) Received: from [192.168.1.102] (VDSL-151-118-146-59.DNVR.QWEST.NET [151.118.146.59]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 02 Oct 2008 10:47:20 -0600 (MDT) (envelope-from danny@arbor.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=151.118.146.59; client-port=51171; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: <236535C9-A355-4861-97E6-1AF3EE3B4067@arbor.net> From: Danny McPherson To: marcelo bagnulo braun In-Reply-To: <48D7C026.6050609@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 2 Oct 2008 10:47:04 -0600 References: <48D7C026.6050609@it.uc3m.es> X-Mailer: Apple Mail (2.929.2) X-Mailman-Approved-At: Sat, 04 Oct 2008 19:35:41 -0700 Cc: savi@ietf.org Subject: Re: [savi] comments on draft-mcpherson-savi-threat-scope-00 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2008 16:47:02 -0000 Great comments, thanks for taking the time to review so thoroughly Marcelo. IF/When we publish an updated version, we'll be sure to incorporate your input. Thanks! -danny On Sep 22, 2008, at 9:56 AM, marcelo bagnulo braun wrote: > Hi, > > I have read draft-mcpherson-savi-threat-scope-00 and i have some > comments and questions. > > In section 2. Overview it reads: > > Solutions such as BCP 38 [RFC 2827] provide guidelines for one such > technique for network ingress filtering. However, if these > techniques are not implemented on 32-bit prefix boundaries at the > ultimate ingress point of the IP network then the validity of the > source address can not be positively ascertained. Furthermore, BCP > 38 only implies source address verification at the Internet Layer, > and is most often implemented on IP subnetwork address boundaries. > > Right, but also i think we need to point out that BCP 38 is far from > universal, so there are a lot of spoofed addresses around > I mean, when i read the previous paragraph and the following one, i > got the impression that the only problem is that BCP 38 allows hosts > within the same IP subnet to spoof each other addresses, and that's > it. > > So i guess i have a question and a comment: > The question is, is the idea to assume that BGP38 is deployed and > that we will perform the threat analysis and find solutions for > residual threats that are not covered by bcp38, or are we supposed > to deal with the source address spoofing in a orthogonal way to bcp > 38? (i understadn this is not the case, cause later sections seem to > be more general than this) > If the question is that we are supposed to deal with the general > problem and not only with the bcp 38 residual threats, i would > suggest to rephrase both the previous and the following paragraph in > order to make this clearer cause at least to me was a bit confusing. > > > There is a possibility that in an LAN environment where multiple > hosts share a single IP port on a switch or router, one of those > hosts may source address spoof the source addresses of other hosts > within the local subnet. Understanding these threats and the > relevant topologies in which they're introduced is critical when > assessing the threats that exists with source address spoofing. > > Later on in section 4.1.1. Single Packet DoS > > First of all, i am not sure if the title is the best one cause, the > section discusses attacks that involve crashing the system, which > seems to me a bit more than what i would call DoS. I would suggest > to call this simply Single packet attacks maybe? > > I find the section a bit too general on spoofed information, rather > than focussing and detailing the particular effects of source > address spoofing, which should be the focus imho > I mean, sending a single packet with spoofed information can > generate an attack, indeed, Now, i guess the question is how many of > these attacks rely on spoofing the source address? In other words, > if we prevent spoofing the source address, do all these attacks go > away? or is a subset of these attacks that disapear. I think the > document should go a bit deeper into this and describe more in > detail which address are enable thanks to source address spoofing > and which could be completely prevented if we implement some source > address validation. Moreover, the document could try to analyse if > we did something like the scope of savi, like a local first hop > verification, what is the set of these attacks that can be prevented? > > > Later on in section 4.1.2. Flood-Based DoS > > I liked this section very much > I think however, i may be worth to summarize which of these attacks > are more relevant to SAVi and what can be expected from savi > From what i understand from this section, there are 3 types of > attacks described: > - one or more attackers flooding using their own source address (i, > this case, savi has nothing to do here, cause there is no source > address spoofed involved) > - one or more attackers flooding using spoofed source addresses > (SVAI can help here, cause if savi is in place we would end up with > the previous bullet only) > - attackers sending an attack using spoofed source address, but the > ultimate goal is to get those addresses filtered, creating a long > term attack for those spoofed source addresses (actually this is DoS > attack to the owners of the source addresses, which can no longer > access to the server). this attack would be completely removed with > savi > > Later in section 4.1.3. Poisoning Attacks > > I couldn't understand what is the difference between this section > and section 4.1.1 > Morevoer, i also think the comment i made for section 4.1.1. applies > here, i.e. that i think the content should focus in the specifics of > the attacks of soruce address spoofing and maybe also in the savi > limited scope, i.e. the case of the first hop > > > Later in section 4.1.4. Third Party Recon > > Right, this seems more like a preparation for an attack than an > attack itself. I mean, do these attacks have a particular impact > other than enabling the next attack? > > Now, what is the effect of source address spoofing? I mean, do > attcker need to spoof the source address for this? Or do they spoof > the source address in order not to reveal themselves? i don't think > we can prevent these attacks with a mechanism to prevent source > address spoofing. To what extent we can help with source address > spoofing prevention? In with the limited scope of savi? > > Later in section 4.1.6. Reflective Attacks > > This makes perfect sense to me > I guess that we could do the same with a download using a tcp > connection from a server, with a spoofed address, so that the server > download hits the victim which address was spoofed. > > Later on, in section 4.1.7. Accounting Subversion > > Do you have any specific protocol in mind that can be used for this? > > Later, in section 4.1.8. Other Blind Spoofing Attacks > > > Other Blind spoofing attacks might include spoofing in order to > exploit source routing or other policy based routing implemented in a > network. > > > i would also benefit from more text here, cause i fail to understand > what you have in mind here > > Finally, what about attacks that imply injecting false routing > information in the IGP? Do these need to be considered? I mean, > routing protocols usually use the source address of the message to > determine which router the message came from so, it seems that it > would be an attractive target for an attcker, would this fall out of > the scope of this analysis? If so, it may be worth mentioning. If > not it may be worth analysing if these attacks should be included in > the analysis. > > > Later on 5.5. Spoofing In Local Area Network Segments > > > On Link Layer segments where multiple hosts reside, or a single MAC > address can be associated with a port or interface, if a binding > between a hardware address (e.g., MAC address) and corresponding IP > address(es) are not provisioned via some means (either manual or > dynamic mechanisms), then an attacker may exploit attack vectors that > enable MITM or other spoof-based attacks. > > > > This section is a bit strange, it reads more like a threat than as a > solution.... > > In section 5.10.2. Automated Binding > > are you planning to discuss IPv6 stateless address autoconfig? I > don't know, but when the iid is obtained from the mad address, it > maybe be trivial to perform the mapping > > > Later in section > > > 5.11. Cryptographic Techniques > > > Needless to say, MITM and replay attacks can typically be mitigated > with cryptographic techniques. However, many of the applications > today either don't or can't employ cryptographic authentication and > protection mechanisms. > > I am not sure how this would help the source address spoofing problem > I guess the crypto technique that could help, would the IPSec AH, > since the source address is protected, but not clear how an > intermediate wold would check that. Could be checked at the end > point though > However, i can't see how other of the availble crypte techniques > could help with this particular problem > > > > ARP and DNS are two examples. DNSSEC does > propose to assist, but until it's deployed ubiquitously, from > clients, to resolvers, to authoritative roots, clients and resolvers > are still vulnerable to replay, cache poisoning and MITM attacks. > > How is ARP an example? > How DNSsec help with the problem of source address spoofing? I mean, > it could mitigate some the attacks that can be generated with spoof > source address, but i am uncertain how how dnssec can help with the > problem of source spoofing > > We could talke about send and cgas, that even though they don't > really tackle this problem, they seem close enough... > > later in section 6.1. Address Provisioning Mechanisms > > > In a strictly static environment configuration management for access > filters that map Link Layer and Network Layer addresses on a specific > switch port might be a viable option. However, most networks, > certainly, those that accommodate actual human users, are much more > dynamic in nature. As such, mechanisms that provide port-MAC-IP > bindings need to accommodate dynamic address allocation schemes > enabled by protocols such as DHCP. > > > i would explicitly mention IPv6 SAA > maybe i would also mention dhcp prefix delegation > > Later in section 6.2.2. NATs > > > Prefix-based and multi-address NATs also become problematic, for the > same reasons as routers. Because they may forward traffic from an > array of address, a priori knowledge must exist providing what IPs > should be associated with a given port-MAC pair. > > > I fail to see why nats are problematic. I mean, from the private > side, nat is just as a router, so i don't think it deserves special > consideration > From the public side, the NAT only generates packets from its pools > of public addresses, so, it is like a host with multiple IP > addresses, which i don't think it is more problematic than a host > with one address. You only need to associated multiple IP addresses > to the MAC address and you are ok. So i fail to see what is specific > to a nat that makes it worth discussing separated. > > > 6.2.3. Multi-Instance Hosts > > I am not sure i understand what this is... it may be worth to > include a definition of this in section 3. same goes for a blade > server > > Later, 6.2.4. Multi-LAN Hosts > > How common is the usage of the loopback address? I am familair with > its usage in bgp, but never heard it in other conext > > 6.2.6. Mobile IP > > > Need to say something here, I think... Mobile IP > > > Ok, let me do a first analysis of this > > > MIP has 3/4 elements that need to be considered, the CN, the MN, the > HA > > MIP4 only works in tunnel mode while mip6 works both in tunnel mode > and in ro mode > > Let's think about the different cases > > MN in tunnel mode. It sends and receives packet form the HA in an > IPsec tunnel with the right source address. no problem here afaict. > (Actually, there were discussions about letting the MN to send the > packet directly to the CN, but i understand that this was not done > cause it would break with ingress filters :-) > > MN in ro mode. it also sends packets with the right source address, > and includes the HoA in the HoA option, so no problem here > > CN in tunnel mode acts like a normal fixed host. > CN in RO mode always sends packet with its won fixed address, so no > problem here > > The HA in tunnel mode (HA is not involved in ro mode). I guess here > is where the problems can arise. The HA is doing proxy ND, in order > to capture the packets for the MN. when the MN is back home, it will > claim the address back and we will see a change in the binding > between the IP address and the MAC address. > > > 6.2.7. Other Topologies > > > maybe talking about proxy ND? > > Later in section 7. Applicability of Anti-Spoofing Solutions > > > What works where, what's needed? > > Ingress filtering is useful, even with botnets using real addresses > > Ingress filtering on the admin border is not sufficient, and more > fine-grained filtering from savi is necessary. > > > i guess you are planning to expand on this? in particular, i am not > sure i understand the second statement > > Later in section 8. Deployment Considerations > > I guess that another problem is that ISPs get paid for inyecting > traffic, and if a client is sending packets with spoofed source > address, but still paying, they don't have much incentives to filter > this traffic. > I guess that a solution to work, must put the right incentives in > place, so that ISPs prefer droping packets with spoofed IP address > from paying customers rather than forwarding them > > > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From christian.vogt@nomadiclab.com Sat Oct 11 15:57:29 2008 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 BAD653A679C for ; Sat, 11 Oct 2008 15:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=1.450, 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 nATkFVPvuPff for ; Sat, 11 Oct 2008 15:57:29 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id C71CE3A685B for ; Sat, 11 Oct 2008 15:57:28 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 332D31EF158; Sun, 12 Oct 2008 01:58:16 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id BEFC21EF155; Sun, 12 Oct 2008 01:58:15 +0300 (EEST) Message-Id: <4EC04196-A0A9-4CFD-A87F-84466963AECF@nomadiclab.com> From: Christian Vogt To: SAVI Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 12 Oct 2008 01:58:15 +0300 X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV using ClamSMTP Subject: [savi] Defining the Solution Space for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2008 22:57:29 -0000 Folks, at our first SAVI meeting in Dublin, we presented the main solution proposals and had a good discussion on where the working group should be going. We should now follow up on this discussion so that we can eventually decide which type of solution SAVI should aim for. The solutions proposals we have on the table [1-4] make different tradeoffs between simplicity and easy deployability on one hand, and strength of security on the other hand. They fall into two classes: (a) solutions that emphasize strong security (b) solutions that emphasize simplicity and easy deployability Solutions in bucket (a) bind IP addresses to credentials and therefore involve cryptography. Solutions in bucket (b) bind IP addresses to physical or link layer entities and are non-cryptographic. Consequently, solutions in bucket (b) can detect all types of spoofing attacks, but are more complex to setup and maintain. Solutions in bucket (a) are rather lightweight and easy to deploy, although they may not be able to protect against all types of spoofing attacks The working group must now come to a conclusion as to which class a working group solution should fit in. In order for us to make an informed decision, the working group chairs would like to continue the discussion [5] from the SAVI meeting in Dublin with you. We should decide upon the desired properties of a SAVI solution, taking into account the goals and requirements put forth on the working group charter. It may also be helpful to take another look at the design taxonomy [6] that the working group chairs had presented in Dublin. Based on the results of this discussion, we will be able to decide whether a lightweight solution will be sufficient, or whether cryptography is needed. - Bill and Christian [1] Source-Guard-based approach by Fred Baker draft-baker-sava-implementation http://www.ietf.org/proceedings/08jul/slides/savi-0/savi-0.htm [2] EAP-based approach by Ren Gang et al. draft-wu-sava-solution-firsthop-eap http://www.ietf.org/proceedings/08jul/slides/savi-1/savi-1.htm [3] CGA-based approach by Jun Bi et al. draft-sava-solution-ipv6-firsthop-authentication http://www.ietf.org/proceedings/08jul/slides/savi-4/savi-4.htm [4] First-come-first-served approach by Erik Nordmark http://www.ietf.org/proceedings/08jul/slides/savi-5.pdf [5] Minutes from the SAVI Meeting at IETF 72, Dublin http://www.ietf.org/proceedings/08jul/minutes/savi.txt [6] SAVI Design Taxonomy and Analysis http://www.ietf.org/proceedings/08jul/slides/savi-2.pdf From christian.vogt@nomadiclab.com Sat Oct 11 17:22:48 2008 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 50CB13A67E5 for ; Sat, 11 Oct 2008 17:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=0.725, 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 f1vSMRHw3ran for ; Sat, 11 Oct 2008 17:22:47 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 8ECDC3A67DF for ; Sat, 11 Oct 2008 17:22:45 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id CEF0A1EF1B9; Sun, 12 Oct 2008 03:23:32 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5BCB61EF158; Sun, 12 Oct 2008 03:23:32 +0300 (EEST) Message-Id: <9A282462-838A-4E1D-BC25-8A33C8C94C85@nomadiclab.com> From: Christian Vogt To: Marcelo Bagnulo , Fred Baker , Danny McPherson In-Reply-To: <48D7C026.6050609@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 12 Oct 2008 03:23:32 +0300 References: <48D7C026.6050609@it.uc3m.es> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV using ClamSMTP Cc: SAVI Mailing List Subject: Re: [savi] comments on draft-mcpherson-savi-threat-scope-00 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2008 00:22:48 -0000 Marcelo, thanks a lot for reviewing the Threats document so carefully. I agree with your comments and think that the next version of the document should reflect them. In many of your comments, you are suggesting that the treats identified in the document should be accompanied by analyses on whether/how SAVI could eliminate the threats. These analyses should definitely be added to the document in my opinion. One of the roles of the Threats document is to serve as a problem statement and motivation for SAVI, and the analyses you are suggesting would come up to this. Fred and Danny: Do you guys think you can address Marcelo's comments and questions with a revision of the Threats document before IETF 73? Optimally, we would have a ready-to-publish version of the Threats document by then. Finally, my responses to some of Marcelo's comments: > Marcelo bagnulo braun wrote: > > In section 2. Overview it reads: > > Solutions such as BCP 38 [RFC 2827] provide guidelines for one such > technique for network ingress filtering. However, if these > techniques are not implemented on 32-bit prefix boundaries at the > ultimate ingress point of the IP network then the validity of the > source address can not be positively ascertained. Furthermore, BCP > 38 only implies source address verification at the Internet Layer, > and is most often implemented on IP subnetwork address boundaries. > > Right, but also i think we need to point out that BCP 38 is far from > universal, so there are a lot of spoofed addresses around I mean, > when i > read the previous paragraph and the following one, i got the > impression > that the only problem is that BCP 38 allows hosts within the same IP > subnet to spoof each other addresses, and that's it. > > So i guess i have a question and a comment: The question is, is the > idea > to assume that BGP38 is deployed and that we will perform the threat > analysis and find solutions for residual threats that are not > covered by > bcp38, or are we supposed to deal with the source address spoofing > in a > orthogonal way to bcp 38? (i understadn this is not the case, cause > later sections seem to be more general than this) If the question is > that we are supposed to deal with the general problem and not only > with > the bcp 38 residual threats, i would suggest to rephrase both the > previous and the following paragraph in order to make this clearer > cause > at least to me was a bit confusing. Since the document is an analysis of the current security state of the Internet regarding spoofed source addresses, it cannot assume that BCP 38 is universally deployed. So you are right that we are supposed to deal with the general problem, as you call it. > There is a possibility that in an LAN environment where multiple > hosts share a single IP port on a switch or router, one of those > hosts may source address spoof the source addresses of other hosts > within the local subnet. Understanding these threats and the > relevant topologies in which they're introduced is critical when > assessing the threats that exists with source address spoofing. > > Later on in section 4.1.1. Single Packet DoS > > First of all, i am not sure if the title is the best one cause, the > section discusses attacks that involve crashing the system, which > seems > to me a bit more than what i would call DoS. I would suggest to call > this simply Single packet attacks maybe? > > I find the section a bit too general on spoofed information, rather > than > focussing and detailing the particular effects of source address > spoofing, which should be the focus imho I mean, sending a single > packet > with spoofed information can generate an attack, indeed, Now, i guess > the question is how many of these attacks rely on spoofing the source > address? The attacks described in this section do indeed rely on source address spoofing. But I agree that this could (and should) be clarified. > Later on in section 4.1.2. Flood-Based DoS > > I liked this section very much I think however, i may be worth to > summarize which of these attacks are more relevant to SAVi and what > can > be expected from savi From what i understand from this section, there > are 3 types of attacks described: > > - one or more attackers flooding using > their own source address (i, this case, savi has nothing to do here, > cause there is no source address spoofed involved) > > - one or more > attackers flooding using spoofed source addresses (SVAI can help here, > cause if savi is in place we would end up with the previous bullet > only) > > - attackers sending an attack using spoofed source address, but the > ultimate goal is to get those addresses filtered, creating a long term > attack for those spoofed source addresses (actually this is DoS attack > to the owners of the source addresses, which can no longer access to > the > server). this attack would be completely removed with savi I like this categorization of flooding attacks. > Later in section 4.1.3. Poisoning Attacks > > I couldn't understand what is the difference between this section and > section 4.1.1 Morevoer, i also think the comment i made for section > 4.1.1. applies here, i.e. that i think the content should focus in the > specifics of the attacks of soruce address spoofing and maybe also in > the savi limited scope, i.e. the case of the first hop Perhaps section 4.1.3 could be merged with section 4.1.1? > Later in section 4.1.6. Reflective Attacks > > This makes perfect sense to me I guess that we could do the same > with a > download using a tcp connection from a server, with a spoofed address, > so that the server download hits the victim which address was spoofed. I agree with your comment. In addition, maybe this section could be merged with section 4.1.2, "Flood-Based DoS"? The attacks described in both sections seem to fall into the same class. > Later, in section 4.1.8. Other Blind Spoofing Attacks > > Other Blind spoofing attacks might include spoofing in order to > exploit source routing or other policy based routing implemented > in a > network. > > i would also benefit from more text here, cause i fail to understand > what you have in mind here > > Finally, what about attacks that imply injecting false routing > information in the IGP? Do these need to be considered? I mean, > routing > protocols usually use the source address of the message to determine > which router the message came from so, it seems that it would be an > attractive target for an attcker, would this fall out of the scope of > this analysis? If so, it may be worth mentioning. If not it may be > worth > analysing if these attacks should be included in the analysis. This is an excellent suggestion. If SAVI could protect against such IGP attacks, then this would be an excellent motivation to deploy SAVI. Note that ingress filtering offers no protection against IGP attacks unless it is deployed on (or very close to) access links -- which in most deployment cases it is not. - Christian From christian.vogt@nomadiclab.com Sat Oct 11 17:48:07 2008 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 45C333A6855 for ; Sat, 11 Oct 2008 17:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.483, 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 QOPwRcRZI1+0 for ; Sat, 11 Oct 2008 17:48:06 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id F00A73A659B for ; Sat, 11 Oct 2008 17:48:05 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 7C2161EF158; Sun, 12 Oct 2008 03:48:55 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0CBEC1EF155; Sun, 12 Oct 2008 03:48:55 +0300 (EEST) Message-Id: From: Christian Vogt To: Fred Baker , Danny McPherson Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 12 Oct 2008 03:48:54 +0300 X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV using ClamSMTP Cc: SAVI Mailing List Subject: [savi] Another review of SAVI Threat Scope document X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2008 00:48:07 -0000 Fred, Danny, you did a great job with the SAVI Threat Scope document [draft-mcpherson-savi-threat-scope], I think. The document has a great overview of threats, and also talks in quite a bit of detail about what solutions already exist. Of course, the document is still a 00 version, and will have to undergo some revision. Marcelo already made several good comments, and I, too, have a suggestion for improvement: Since one of the roles of the Threats document is to serve as a problem statement and motivation for SAVI, I would suggest elaborating a bit more on is the part that talks about shortfalls of existing solutions and, in particular, where and how the prospective SAVI solution would be of value. I am attaching text that you may copy into the document as a new section. - Christian Existing Techniques for IP Source Address Validation ---------------------------------------------------- Existing techniques for IP source address validation are insufficient for at least one of the following reasons: - False negatives. Techniques may yield false negatives, thus enabling an attacker to select an IP source address that is spoofed, but still passes IP source address validation. - False positives. Techniques may yield false positives, thereby causing interruption or denial of service to hosts that use legitimate IP source addresses. - Non-trivial configuration. Requirements for non-trivial configuration imply expenditures and pose a risk for misconfiguration, which may again lead to false positives or false negatives. Both may discourage operators from using a technique. - Proprietary. Procurement policies oftentimes require techniques that are standardized, hence hindering or preventing the deployment of proprietary techniques. The only standardized technique for IP source address validation is ingress filtering [1]. This calls for routers to check whether the prefix of a to-be-forwarded packet's IP source address is amongst a list of prefixes considered legitimate for the interface through which the packet arrives. Packets that fail this check are discarded. Ingress filtering may yield false negatives in deterministic manner. Packets with a legitimate IP source address prefix, but a spoofed interface identifier, pass ingress filtering checks. Also, packets with an illegitimate IP source address prefix pass the checks as long as the prefix is from the list of prefixes considered legitimate. Ingress filtering implementations that require manual establishment of the list of legitimate prefixes cause considerable configuration overhead. Unicast Reverse Path Forwarding [2] mitigates this issue by automatically deriving the list of legitimate prefixes from a router's forwarding table: A to-be-forwarded packet's IP source address prefix is considered legitimate if the packet is coming through an interface via which return traffic would be routed. On the other hand, Unicast Reverse Path Forwarding may yield false positives, in particular for hosts and networks with multiple, topologically separate Internet attachments [3]. Consequently, there is a need for an IP source address validation technique that avoids false negatives and false positives, that can be set up with no or only trivial configuration, and that has been standardized. The development of such a technique is the goal of the proposed Source Address Validation Improvements working group in the Internet Engineering Task Force. [1] Paul Ferguson and Daniel Senie. Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing. IETF Request for Comments 2827, Best Current Practice 38, May 2000. [2] Cisco Systems. Unicast Reverse Path Forwarding. Cisco IOS Documentation, May 1999. [3] F. Baker and P. Savola. Ingress Filtering for Multihomed Networks. IETF Request for Comments 3704, March 2004. From marcelo@it.uc3m.es Sun Oct 12 02:17:38 2008 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 295123A6946 for ; Sun, 12 Oct 2008 02:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.485 X-Spam-Level: X-Spam-Status: No, score=-4.485 tagged_above=-999 required=5 tests=[AWL=-0.723, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 23Btn1-ttnRh for ; Sun, 12 Oct 2008 02:17:37 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id DE7113A6943 for ; Sun, 12 Oct 2008 02:17:35 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (158.pool85-53-140.dynamic.orange.es [85.53.140.158])by smtp03.uc3m.es (Postfix) with ESMTP id 3C3336A672B; Sun, 12 Oct 2008 11:18:21 +0200 (CEST) Message-ID: <48F1C0DC.6070409@it.uc3m.es> Date: Sun, 12 Oct 2008 11:18:20 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Christian Vogt References: <4EC04196-A0A9-4CFD-A87F-84466963AECF@nomadiclab.com> In-Reply-To: <4EC04196-A0A9-4CFD-A87F-84466963AECF@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-22.9868 TC:1F TRN:66 TV:5.5.1026(16212.006) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: SAVI Mailing List Subject: Re: [savi] Defining the Solution Space for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2008 09:17:38 -0000 Hi Chrsitian, thanks for the analysis, some comments below... Christian Vogt escribió: > Folks, > > at our first SAVI meeting in Dublin, we presented the main solution > proposals and had a good discussion on where the working group should be > going. We should now follow up on this discussion so that we can > eventually decide which type of solution SAVI should aim for. > > The solutions proposals we have on the table [1-4] make different > tradeoffs between simplicity and easy deployability on one hand, and > strength of security on the other hand. They fall into two classes: > > (a) solutions that emphasize strong security > > (b) solutions that emphasize simplicity and easy deployability > > Solutions in bucket (a) bind IP addresses to credentials and therefore > involve cryptography. Solutions in bucket (b) bind IP addresses to > physical or link layer entities and are non-cryptographic. Consequently, > solutions in bucket (b) You mean that solutions in class a? > can detect all types of spoofing attacks, but > are more complex to setup and maintain. Solutions in bucket (a) are You mean that solutions in class b? > rather lightweight and easy to deploy, although they may not be able to > protect against all types of spoofing attacks > > The working group must now come to a conclusion as to which class a > working group solution should fit in. but the charter already makes that decision for us doesn't it? I mean, the savi charter states: The scope of the WG is as follows: - The working group considers only solutions implemented on systems located on the same IP link as a to-be-verified node. The goal of the working group is the LAN environment and solutions running in routers or layer 3 aware Ethernet bridges. - No changes to hosts are allowed. - The WG is prohibited from creating its own protocols or extensions/modifications of current protocols. So, the solution works in the bridge or router, and no host changes are allowed and no new protocols. I guess that solutions in class a require changes in the hosts and are likely to require a new protocol (in order to proof that actual data packets come from the claimed source) I understand that these solutions are simply out of the scope for the WG charter as defined. So, imho this decision has already been taken and we need to figure out what is the best we can do with the imposed constraints I am not saying that leveraging in SeND is not possible but creating new protocols that use CGAs or certificates seems to me to be explicltly out of the charter. > In order for us to make an > informed decision, the working group chairs would like to continue the > discussion [5] from the SAVI meeting in Dublin with you. We should > decide upon the desired properties of a SAVI solution, taking into > account the goals and requirements put forth on the working group > charter. It may also be helpful to take another look at the design > taxonomy [6] that the working group chairs had presented in Dublin. > Based on the results of this discussion, we will be able to decide > whether a lightweight solution will be sufficient, or whether > cryptography is needed. > As i said, the charter already states that we can't do new protocols or host changes. so maybe we cna leverage on send, or in other existent crypto tools that are already defined, but as currently stand, class a propoals are out of the charter imho Regards, marcelo > - Bill and Christian > > > [1] Source-Guard-based approach by Fred Baker > draft-baker-sava-implementation > http://www.ietf.org/proceedings/08jul/slides/savi-0/savi-0.htm > > [2] EAP-based approach by Ren Gang et al. > draft-wu-sava-solution-firsthop-eap > http://www.ietf.org/proceedings/08jul/slides/savi-1/savi-1.htm > > [3] CGA-based approach by Jun Bi et al. > draft-sava-solution-ipv6-firsthop-authentication > http://www.ietf.org/proceedings/08jul/slides/savi-4/savi-4.htm > > [4] First-come-first-served approach by Erik Nordmark > http://www.ietf.org/proceedings/08jul/slides/savi-5.pdf > > [5] Minutes from the SAVI Meeting at IETF 72, Dublin > http://www.ietf.org/proceedings/08jul/minutes/savi.txt > > [6] SAVI Design Taxonomy and Analysis > http://www.ietf.org/proceedings/08jul/slides/savi-2.pdf > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From junbi@cernet.edu.cn Sun Oct 12 07:19:02 2008 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 DB9E63A69A7 for ; Sun, 12 Oct 2008 07:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696] 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 c3sCU5TNJcxc for ; Sun, 12 Oct 2008 07:19:01 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 3BD473A67EE for ; Sun, 12 Oct 2008 07:19:00 -0700 (PDT) Received: from userPC([59.66.53.129]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm2648f27bdd; Sun, 12 Oct 2008 22:19:46 +0800 Message-ID: <5CE879A0D1904950B87A5507C7C86E5E@userPC> From: "Jun Bi" To: "marcelo bagnulo braun" , "Christian Vogt" References: <4EC04196-A0A9-4CFD-A87F-84466963AECF@nomadiclab.com> <48F1C0DC.6070409@it.uc3m.es> In-Reply-To: <48F1C0DC.6070409@it.uc3m.es> Date: Sun, 12 Oct 2008 22:19:34 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: 1dYnBpUB Cc: SAVI Mailing List Subject: Re: [savi] Defining the Solution Space for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2008 14:19:03 -0000 Hi Marcelo, I thought during the IETF72 SAVI WG discussion, as Jari and others pointed, if the solution is revised as an extension of an existing protocol (e.g., SeND or others), then it somehow won't be a new protocol or host change. Anyway, we need solutions that can really fix the problem in the usual situations and deployment scenarios that required by users. Therefore, based on the current experience, I believe a problem statement draft is needed by this WG. And maybe, according to the problem statement, a framework draft is also necessary to provide more detail (than charter) guideline to solution design, e.g. the deployment point, the upper boundary of the cost, etc. thanks, Jun Bi ----- Original Message ----- From: "marcelo bagnulo braun" To: "Christian Vogt" Cc: "SAVI Mailing List" Sent: Sunday, October 12, 2008 5:18 PM Subject: Re: [savi] Defining the Solution Space for SAVI Hi Chrsitian, thanks for the analysis, some comments below... Christian Vogt escribió: > Folks, > > at our first SAVI meeting in Dublin, we presented the main solution > proposals and had a good discussion on where the working group should be > going. We should now follow up on this discussion so that we can > eventually decide which type of solution SAVI should aim for. > > The solutions proposals we have on the table [1-4] make different > tradeoffs between simplicity and easy deployability on one hand, and > strength of security on the other hand. They fall into two classes: > > (a) solutions that emphasize strong security > > (b) solutions that emphasize simplicity and easy deployability > > Solutions in bucket (a) bind IP addresses to credentials and therefore > involve cryptography. Solutions in bucket (b) bind IP addresses to > physical or link layer entities and are non-cryptographic. Consequently, > solutions in bucket (b) You mean that solutions in class a? > can detect all types of spoofing attacks, but > are more complex to setup and maintain. Solutions in bucket (a) are You mean that solutions in class b? > rather lightweight and easy to deploy, although they may not be able to > protect against all types of spoofing attacks > > The working group must now come to a conclusion as to which class a > working group solution should fit in. but the charter already makes that decision for us doesn't it? I mean, the savi charter states: The scope of the WG is as follows: - The working group considers only solutions implemented on systems located on the same IP link as a to-be-verified node. The goal of the working group is the LAN environment and solutions running in routers or layer 3 aware Ethernet bridges. - No changes to hosts are allowed. - The WG is prohibited from creating its own protocols or extensions/modifications of current protocols. So, the solution works in the bridge or router, and no host changes are allowed and no new protocols. I guess that solutions in class a require changes in the hosts and are likely to require a new protocol (in order to proof that actual data packets come from the claimed source) I understand that these solutions are simply out of the scope for the WG charter as defined. So, imho this decision has already been taken and we need to figure out what is the best we can do with the imposed constraints I am not saying that leveraging in SeND is not possible but creating new protocols that use CGAs or certificates seems to me to be explicltly out of the charter. > In order for us to make an > informed decision, the working group chairs would like to continue the > discussion [5] from the SAVI meeting in Dublin with you. We should > decide upon the desired properties of a SAVI solution, taking into > account the goals and requirements put forth on the working group > charter. It may also be helpful to take another look at the design > taxonomy [6] that the working group chairs had presented in Dublin. > Based on the results of this discussion, we will be able to decide > whether a lightweight solution will be sufficient, or whether > cryptography is needed. > As i said, the charter already states that we can't do new protocols or host changes. so maybe we cna leverage on send, or in other existent crypto tools that are already defined, but as currently stand, class a propoals are out of the charter imho Regards, marcelo > - Bill and Christian > > > [1] Source-Guard-based approach by Fred Baker > draft-baker-sava-implementation > http://www.ietf.org/proceedings/08jul/slides/savi-0/savi-0.htm > > [2] EAP-based approach by Ren Gang et al. > draft-wu-sava-solution-firsthop-eap > http://www.ietf.org/proceedings/08jul/slides/savi-1/savi-1.htm > > [3] CGA-based approach by Jun Bi et al. > draft-sava-solution-ipv6-firsthop-authentication > http://www.ietf.org/proceedings/08jul/slides/savi-4/savi-4.htm > > [4] First-come-first-served approach by Erik Nordmark > http://www.ietf.org/proceedings/08jul/slides/savi-5.pdf > > [5] Minutes from the SAVI Meeting at IETF 72, Dublin > http://www.ietf.org/proceedings/08jul/minutes/savi.txt > > [6] SAVI Design Taxonomy and Analysis > http://www.ietf.org/proceedings/08jul/slides/savi-2.pdf > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi From marcelo@it.uc3m.es Sun Oct 12 09:32:08 2008 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 999BC3A69B1 for ; Sun, 12 Oct 2008 09:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.381 X-Spam-Level: X-Spam-Status: No, score=-4.381 tagged_above=-999 required=5 tests=[AWL=-0.619, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 OHAu-nrK5DT1 for ; Sun, 12 Oct 2008 09:32:07 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 2CC3E3A68CB for ; Sun, 12 Oct 2008 09:32:05 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [85.53.140.158])by smtp01.uc3m.es (Postfix) with ESMTP id 3FF40ABE03C; Sun, 12 Oct 2008 18:32:04 +0200 (CEST) Message-ID: <48F22683.6030409@it.uc3m.es> Date: Sun, 12 Oct 2008 18:32:03 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Jun Bi References: <4EC04196-A0A9-4CFD-A87F-84466963AECF@nomadiclab.com> <48F1C0DC.6070409@it.uc3m.es> <5CE879A0D1904950B87A5507C7C86E5E@userPC> In-Reply-To: <5CE879A0D1904950B87A5507C7C86E5E@userPC> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-22.5815 TC:1F TRN:83 TV:5.5.1026(16214.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Christian Vogt , SAVI Mailing List Subject: Re: [savi] Defining the Solution Space for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2008 16:32:08 -0000 Hi Jun Bi, Jun Bi escribió: > Hi Marcelo, > > I thought during the IETF72 SAVI WG discussion, as Jari and others > pointed, > if the solution is revised as an extension of an existing protocol > (e.g., SeND or others), > then it somehow won't be a new protocol i agree that we could extend a protocol and that wouldn't be a new protocol > or host change. > it depends on what the protocol extensions affect for instance, you can extend send so that the routers do something new, and that would be compatible with SAVI charter (we would need to figure out if this WG is the right place to do this, since SeND is been updated in CSI, but that's another disucssion) However, i understand that charter explicitly precludes making extensions to protocols that modify the host behaviour. so if the hypothetical change to the SeND protocol affects host behaviour, it is my understanding that the SAVI charter explicitly precludes from doing that. But maybe i am reading too much into the charter so, maybe the charis or the ADs could clarify this > Anyway, we need solutions that can really fix the problem in the usual > situations and deployment scenarios > that required by users. > Therefore, based on the current experience, I believe a problem > statement draft is needed by this WG. > And maybe, according to the problem statement, a framework draft is > also necessary to provide more detail (than charter) guideline to > solution design, e.g. the deployment point, the upper boundary of the > cost, etc. well, these two documents are not in the charter neither... regards, marcelo > > thanks, > Jun Bi > > > ----- Original Message ----- From: "marcelo bagnulo braun" > > To: "Christian Vogt" > Cc: "SAVI Mailing List" > Sent: Sunday, October 12, 2008 5:18 PM > Subject: Re: [savi] Defining the Solution Space for SAVI > > > Hi Chrsitian, > > thanks for the analysis, some comments below... > > > Christian Vogt escribió: >> Folks, >> >> at our first SAVI meeting in Dublin, we presented the main solution >> proposals and had a good discussion on where the working group should be >> going. We should now follow up on this discussion so that we can >> eventually decide which type of solution SAVI should aim for. >> >> The solutions proposals we have on the table [1-4] make different >> tradeoffs between simplicity and easy deployability on one hand, and >> strength of security on the other hand. They fall into two classes: >> >> (a) solutions that emphasize strong security >> >> (b) solutions that emphasize simplicity and easy deployability >> >> Solutions in bucket (a) bind IP addresses to credentials and therefore >> involve cryptography. Solutions in bucket (b) bind IP addresses to >> physical or link layer entities and are non-cryptographic. Consequently, >> solutions in bucket (b) > > You mean that solutions in class a? > >> can detect all types of spoofing attacks, but >> are more complex to setup and maintain. Solutions in bucket (a) are > You mean that solutions in class b? > >> rather lightweight and easy to deploy, although they may not be able to >> protect against all types of spoofing attacks >> >> The working group must now come to a conclusion as to which class a >> working group solution should fit in. > > but the charter already makes that decision for us doesn't it? > I mean, the savi charter states: > > The scope of the WG is as follows: > > - The working group considers only solutions implemented on systems > located on the same IP link as a to-be-verified node. The goal of the > working group is the LAN environment and solutions running in routers or > layer 3 aware Ethernet bridges. > > - No changes to hosts are allowed. > > - The WG is prohibited from creating its own protocols > or extensions/modifications of current protocols. > > So, the solution works in the bridge or router, and no host changes are > allowed and no new protocols. I guess that solutions in class a require > changes in the hosts and are likely to require a new protocol (in order > to proof that actual data packets come from the claimed source) > > I understand that these solutions are simply out of the scope for the WG > charter as defined. > > So, imho this decision has already been taken and we need to figure out > what is the best we can do with the imposed constraints > > I am not saying that leveraging in SeND is not possible but creating new > protocols that use CGAs or certificates seems to me to be explicltly out > of the charter. > > >> In order for us to make an >> informed decision, the working group chairs would like to continue the >> discussion [5] from the SAVI meeting in Dublin with you. We should >> decide upon the desired properties of a SAVI solution, taking into >> account the goals and requirements put forth on the working group >> charter. It may also be helpful to take another look at the design >> taxonomy [6] that the working group chairs had presented in Dublin. >> Based on the results of this discussion, we will be able to decide >> whether a lightweight solution will be sufficient, or whether >> cryptography is needed. >> > > As i said, the charter already states that we can't do new protocols or > host changes. so maybe we cna leverage on send, or in other existent > crypto tools that are already defined, but as currently stand, class a > propoals are out of the charter imho > > Regards, marcelo > >> - Bill and Christian >> >> >> [1] Source-Guard-based approach by Fred Baker >> draft-baker-sava-implementation >> http://www.ietf.org/proceedings/08jul/slides/savi-0/savi-0.htm >> >> [2] EAP-based approach by Ren Gang et al. >> draft-wu-sava-solution-firsthop-eap >> http://www.ietf.org/proceedings/08jul/slides/savi-1/savi-1.htm >> >> [3] CGA-based approach by Jun Bi et al. >> draft-sava-solution-ipv6-firsthop-authentication >> http://www.ietf.org/proceedings/08jul/slides/savi-4/savi-4.htm >> >> [4] First-come-first-served approach by Erik Nordmark >> http://www.ietf.org/proceedings/08jul/slides/savi-5.pdf >> >> [5] Minutes from the SAVI Meeting at IETF 72, Dublin >> http://www.ietf.org/proceedings/08jul/minutes/savi.txt >> >> [6] SAVI Design Taxonomy and Analysis >> http://www.ietf.org/proceedings/08jul/slides/savi-2.pdf >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > > > > From junbi@tsinghua.edu.cn Sun Oct 12 10:05:49 2008 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 BC20C3A68FF for ; Sun, 12 Oct 2008 10:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 YHSBmgONqCjq for ; Sun, 12 Oct 2008 10:05:46 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id 5E7733A68CB for ; Sun, 12 Oct 2008 10:05:46 -0700 (PDT) Received: from [59.66.53.129] (helo=userPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.63) (envelope-from ) id 1Kp4NV-0002Wd-VY; Mon, 13 Oct 2008 01:05:14 +0800 Message-ID: From: "Jun Bi" To: "marcelo bagnulo braun" References: <4EC04196-A0A9-4CFD-A87F-84466963AECF@nomadiclab.com> <48F1C0DC.6070409@it.uc3m.es> <5CE879A0D1904950B87A5507C7C86E5E@userPC> <48F22683.6030409@it.uc3m.es> In-Reply-To: <48F22683.6030409@it.uc3m.es> Date: Mon, 13 Oct 2008 01:05:04 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 Cc: Christian Vogt , SAVI Mailing List Subject: Re: [savi] Defining the Solution Space for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jun Bi List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2008 17:05:49 -0000 Hi Marcelo, The question is do we really need the two documents or not. Since the charter only provide rough guideline that already brought some arguments (such as what we saw in the mailing list), I guess the WG need the two documents. By the way, thank you for all the comments. Best Regards, Jun Bi > Anyway, we need solutions that can really fix the problem in the usual > situations and deployment scenarios > that required by users. > Therefore, based on the current experience, I believe a problem statement > draft is needed by this WG. > And maybe, according to the problem statement, a framework draft is also > necessary to provide more detail (than charter) guideline to solution > design, e.g. the deployment point, the upper boundary of the cost, etc. well, these two documents are not in the charter neither... regards, marcelo > > thanks, > Jun Bi > > > ----- Original Message ----- From: "marcelo bagnulo braun" > > To: "Christian Vogt" > Cc: "SAVI Mailing List" > Sent: Sunday, October 12, 2008 5:18 PM > Subject: Re: [savi] Defining the Solution Space for SAVI > > > Hi Chrsitian, > > thanks for the analysis, some comments below... > > > Christian Vogt escribió: >> Folks, >> >> at our first SAVI meeting in Dublin, we presented the main solution >> proposals and had a good discussion on where the working group should be >> going. We should now follow up on this discussion so that we can >> eventually decide which type of solution SAVI should aim for. >> >> The solutions proposals we have on the table [1-4] make different >> tradeoffs between simplicity and easy deployability on one hand, and >> strength of security on the other hand. They fall into two classes: >> >> (a) solutions that emphasize strong security >> >> (b) solutions that emphasize simplicity and easy deployability >> >> Solutions in bucket (a) bind IP addresses to credentials and therefore >> involve cryptography. Solutions in bucket (b) bind IP addresses to >> physical or link layer entities and are non-cryptographic. Consequently, >> solutions in bucket (b) > > You mean that solutions in class a? > >> can detect all types of spoofing attacks, but >> are more complex to setup and maintain. Solutions in bucket (a) are > You mean that solutions in class b? > >> rather lightweight and easy to deploy, although they may not be able to >> protect against all types of spoofing attacks >> >> The working group must now come to a conclusion as to which class a >> working group solution should fit in. > > but the charter already makes that decision for us doesn't it? > I mean, the savi charter states: > > The scope of the WG is as follows: > > - The working group considers only solutions implemented on systems > located on the same IP link as a to-be-verified node. The goal of the > working group is the LAN environment and solutions running in routers or > layer 3 aware Ethernet bridges. > > - No changes to hosts are allowed. > > - The WG is prohibited from creating its own protocols > or extensions/modifications of current protocols. > > So, the solution works in the bridge or router, and no host changes are > allowed and no new protocols. I guess that solutions in class a require > changes in the hosts and are likely to require a new protocol (in order > to proof that actual data packets come from the claimed source) > > I understand that these solutions are simply out of the scope for the WG > charter as defined. > > So, imho this decision has already been taken and we need to figure out > what is the best we can do with the imposed constraints > > I am not saying that leveraging in SeND is not possible but creating new > protocols that use CGAs or certificates seems to me to be explicltly out > of the charter. > > >> In order for us to make an >> informed decision, the working group chairs would like to continue the >> discussion [5] from the SAVI meeting in Dublin with you. We should >> decide upon the desired properties of a SAVI solution, taking into >> account the goals and requirements put forth on the working group >> charter. It may also be helpful to take another look at the design >> taxonomy [6] that the working group chairs had presented in Dublin. >> Based on the results of this discussion, we will be able to decide >> whether a lightweight solution will be sufficient, or whether >> cryptography is needed. >> > > As i said, the charter already states that we can't do new protocols or > host changes. so maybe we cna leverage on send, or in other existent > crypto tools that are already defined, but as currently stand, class a > propoals are out of the charter imho > > Regards, marcelo > >> - Bill and Christian >> >> >> [1] Source-Guard-based approach by Fred Baker >> draft-baker-sava-implementation >> http://www.ietf.org/proceedings/08jul/slides/savi-0/savi-0.htm >> >> [2] EAP-based approach by Ren Gang et al. >> draft-wu-sava-solution-firsthop-eap >> http://www.ietf.org/proceedings/08jul/slides/savi-1/savi-1.htm >> >> [3] CGA-based approach by Jun Bi et al. >> draft-sava-solution-ipv6-firsthop-authentication >> http://www.ietf.org/proceedings/08jul/slides/savi-4/savi-4.htm >> >> [4] First-come-first-served approach by Erik Nordmark >> http://www.ietf.org/proceedings/08jul/slides/savi-5.pdf >> >> [5] Minutes from the SAVI Meeting at IETF 72, Dublin >> http://www.ietf.org/proceedings/08jul/minutes/savi.txt >> >> [6] SAVI Design Taxonomy and Analysis >> http://www.ietf.org/proceedings/08jul/slides/savi-2.pdf >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > > > > _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi From marcelo@it.uc3m.es Mon Oct 13 01:53:26 2008 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 87CFF3A659B for ; Mon, 13 Oct 2008 01:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.722 X-Spam-Level: X-Spam-Status: No, score=-5.722 tagged_above=-999 required=5 tests=[AWL=0.877, 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 EF-wc2OQ6YGc for ; Mon, 13 Oct 2008 01:53:25 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id AEECD3A682A for ; Mon, 13 Oct 2008 01:53:25 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (158.pool85-53-140.dynamic.orange.es [85.53.140.158])by smtp03.uc3m.es (Postfix) with ESMTP id ED6EE68DF4Dfor ; Mon, 13 Oct 2008 10:54:14 +0200 (CEST) Message-ID: <48F30CB6.9090508@it.uc3m.es> Date: Mon, 13 Oct 2008 10:54:14 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: SAVI Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-6.6852 TC:1F TRN:22 TV:5.5.1026(16214.005) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [savi] Scope of 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, 13 Oct 2008 08:53:26 -0000 Hi, I am trying to understand what would be the scope of a SAVI solution. A first question that comes to my mind when i start thinking about this is whether we want a solution that complements ingress filtering or we want a solution that substitutes ingress filtering. In other words, one option would be to assume that we have ingress filtering and try to define a SAVI solution that mitigates or even eliminates the remaining threats. As the threat analysis draft describes, even if we have ingress filtering deployed, we would still have the potential threat that a node located in a give LAN could spoof the address of another host of the same LAN and that would not be detected by the ingress filters. I understand that several of the proposals (like Erik's FCFS or Fred's SAVA implementation) go in that direction. The other option is to state that ingress filtering is far from deployed and we need to define a SAVI solution that is stand alone, i.e. that protects against the threats that ingress filtering is supposed to protect against. I am not sure if we can do much better than ingress filtering with the imposed constraints, but since i haven't seen this acknowledged in the charter, it seemed worthwhile to me to make this matters clear Regards, marcelo From christian.vogt@nomadiclab.com Mon Oct 13 07:53:24 2008 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 4DD0B3A6A2F for ; Mon, 13 Oct 2008 07:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.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 E6PnQWDL1Slt for ; Mon, 13 Oct 2008 07:53:20 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 4828F3A69CD for ; Mon, 13 Oct 2008 07:53:20 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id A2BE61EF6DF; Mon, 13 Oct 2008 17:54:12 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 6B57E1EF6DE; Mon, 13 Oct 2008 17:54:12 +0300 (EEST) Message-Id: <22867E3F-3EE7-4DF7-AE99-827586F51C9C@nomadiclab.com> From: Christian Vogt To: marcelo bagnulo braun In-Reply-To: <48F1C0DC.6070409@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 13 Oct 2008 17:54:12 +0300 References: <4EC04196-A0A9-4CFD-A87F-84466963AECF@nomadiclab.com> <48F1C0DC.6070409@it.uc3m.es> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV using ClamSMTP Cc: SAVI Mailing List Subject: Re: [savi] Defining the Solution Space for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2008 14:53:24 -0000 Marcelo - >> Solutions in bucket (a) bind IP addresses to credentials and >> therefore >> involve cryptography. Solutions in bucket (b) bind IP addresses to >> physical or link layer entities and are non-cryptographic. >> Consequently, >> solutions in bucket (b) > > You mean that solutions in class a? Yep. >> can detect all types of spoofing attacks, but are more complex to >> setup >> and maintain. Solutions in bucket (a) are > > You mean that solutions in class b? Yep. :-) >> rather lightweight and easy to deploy, although they may not be >> able to >> protect against all types of spoofing attacks >> >> The working group must now come to a conclusion as to which class a >> working group solution should fit in. > > but the charter already makes that decision for us doesn't it? Not necessarily. The intention of the charter is to avoid host changes and new protocols. Using an existing protocol, unchanged, for the purpose of verifying a host's IP address ownership is, of course, in-charter. What if a SAVI device could use SeND as is? Then why not increase security based on SeND in those environments where it is deployed? The disadvantage would be a significant applicability limitation because SeND deployment would become a prerequisite for SAVI deployment. - Christian From christian.vogt@nomadiclab.com Mon Oct 13 07:54:15 2008 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 269DD28C102 for ; Mon, 13 Oct 2008 07:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=0.290, 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 zwWhZ2a7AGGV for ; Mon, 13 Oct 2008 07:54:14 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id E7DD128C108 for ; Mon, 13 Oct 2008 07:54:13 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id C317B1EF6E4; Mon, 13 Oct 2008 17:55:06 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 85E8A1EF6DF; Mon, 13 Oct 2008 17:55:06 +0300 (EEST) From: Christian Vogt To: Jun Bi In-Reply-To: <5CE879A0D1904950B87A5507C7C86E5E@userPC> X-Priority: 3 References: <4EC04196-A0A9-4CFD-A87F-84466963AECF@nomadiclab.com> <48F1C0DC.6070409@it.uc3m.es> <5CE879A0D1904950B87A5507C7C86E5E@userPC> Message-Id: <887E9B88-3DB9-4E79-9A4C-9CC5A7150333@nomadiclab.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 13 Oct 2008 17:55:06 +0300 X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV using ClamSMTP Cc: SAVI Mailing List Subject: Re: [savi] Defining the Solution Space for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2008 14:54:15 -0000 Jun Bi wrote: > I thought during the IETF72 SAVI WG discussion, as Jari and others > pointed, if the solution is revised as an extension of an existing > protocol (e.g., SeND or others), then it somehow won't be a new > protocol > or host change. Jun and all, what was considered at IETF 72 was not to extend SeND (or another protocol). It was the possibility to request from IESG the addition of a charter deliverable for a SeND-based SAVI solution extension. The idea was that the working group could work on both, a basic non-cryptographic SAVI solution, plus a more secure extension that would be based on (unchanged) SeND. This would allow easy deployment of the basic SAVI solution without special prerequisites. And in those environments where SeND is deployed, stronger security could optionally be obtained by using the SAVI solution extension. - Christian From christian.vogt@nomadiclab.com Mon Oct 13 09:31:53 2008 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 7C66B3A6A8B for ; Mon, 13 Oct 2008 09:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, 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 9KknAMKtOA3C for ; Mon, 13 Oct 2008 09:31:51 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id E79FC3A6980 for ; Mon, 13 Oct 2008 09:31:50 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id ED7991EF6E4; Mon, 13 Oct 2008 19:32:43 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 80C061EF6DE; Mon, 13 Oct 2008 19:32:43 +0300 (EEST) From: Christian Vogt To: Marcelo Bagnulo In-Reply-To: <48F30CB6.9090508@it.uc3m.es> References: <48F30CB6.9090508@it.uc3m.es> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 13 Oct 2008 19:32:43 +0300 X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV using ClamSMTP Cc: SAVI Mailing List Subject: Re: [savi] Scope of 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, 13 Oct 2008 16:31:53 -0000 Marcelo, you are raising a very good question. But I think you are too fast. :-) What we should in my opinion consider first is the higher-level question of where we want SAVI solutions to be deployed. Or, the same question phrased more specifically: Which (existing and unchanged) protocols do we want a SAVI solution to rely upon? Should it be plain IPv6 Neighbor Discovery and ARP? Should it be SeND? Or should it be something even more sophisticated? We need to answer this question first in order to be able to answer the more specific question you are raising. Your question addresses a very specific, technical goal. It falls into the same category as several other questions that have been raised: (a) Should SAVI support hosts with multiple IP addresses per interface? (b) Should SAVI support hosts with multiple link layer addresses per interface? (c) Should SAVI support hosts that move at the link layer? (d) Should SAVI support hosts that are multi-homed at the link layer? (e) Should SAVI support routers? (f) Should SAVI support NATs? (g) Should SAVI support anycast addressing? (h) Should SAVI detect spoofed unused IP addresses? (i) Should SAVI detect spoofed off-link IP addresses? (j) Your question: Should SAVI complement or substitute ingress filtering? It is tempting to answer all of these questions with "yes". But without knowing which protocol SAVI can rely upon and make use of, answering any of these question with "yes" would be dangerous: It would set us a goal that we may not be able to meet. I would therefore suggest to first revisit the initial, high-level question of where in the tradeoff space between strong security and easy deployability a SAVI solution should reside in our opinion. We can answer this question very specifically by pinpointing the (existing and unchanged) protocols that we want a SAVI solution to rely upon -- keeping in mind that we cannot create new protocols. Once we have settled on an answer to this high-level question, we will have a much clearer understanding of what is achievable and what is not. And we will be able to confidently answer the questions that you are raising, as well as the other more specific questions in the list above. - Christian On Oct 13, 2008, marcelo bagnulo braun wrote: > Hi, > > I am trying to understand what would be the scope of a SAVI > solution. A > first question that comes to my mind when i start thinking about > this is > whether we want a solution that complements ingress filtering or we > want > a solution that substitutes ingress filtering. In other words, one > option would be to assume that we have ingress filtering and try to > define a SAVI solution that mitigates or even eliminates the remaining > threats. As the threat analysis draft describes, even if we have > ingress > filtering deployed, we would still have the potential threat that a > node > located in a give LAN could spoof the address of another host of the > same LAN and that would not be detected by the ingress filters. I > understand that several of the proposals (like Erik's FCFS or Fred's > SAVA implementation) go in that direction. The other option is to > state > that ingress filtering is far from deployed and we need to define a > SAVI > solution that is stand alone, i.e. that protects against the threats > that ingress filtering is supposed to protect against. I am not sure > if > we can do much better than ingress filtering with the imposed > constraints, but since i haven't seen this acknowledged in the > charter, > it seemed worthwhile to me to make this matters clear > > Regards, marcelo From zhangdong_rh@huaweisymantec.com Mon Oct 13 19:06:47 2008 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 759F43A6AEE for ; Mon, 13 Oct 2008 19:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 5.035 X-Spam-Level: ***** X-Spam-Status: Yes, score=5.035 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] X-Spam-Report: * 1.3 SARE_SUB_ENC_GB2312 Subject specifies display in non-English lang * 3.2 CHARSET_FARAWAY_HEADER A foreign language charset used in headers * 0.3 CN_BODY_35 BODY: Body contains "\323\312\274\376" * -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] * 2.5 MIME_CHARSET_FARAWAY MIME character set indicates foreign language * 0.3 MIME_8BIT_HEADER Message header contains 8-bit character 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 VtJcc00dDQmw for ; Mon, 13 Oct 2008 19:06:46 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [121.15.168.142]) by core3.amsl.com (Postfix) with ESMTP id 8C02C3A6967 for ; Mon, 13 Oct 2008 19:06:45 -0700 (PDT) MIME-version: 1.0 Content-disposition: inline Content-type: text/plain; charset=gb2312 Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0K8P003FNHVITG20@hstga01-in.huaweisymantec.com> for savi@ietf.org; Tue, 14 Oct 2008 10:06:55 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0K8P00IKBHVHOH00@hstml02-in.huaweisymantec.com> for savi@ietf.org; Tue, 14 Oct 2008 10:06:54 +0800 (CST) Received: from [10.27.141.13] by hstml02-in.huaweisymantec.com (mshttpd); Tue, 14 Oct 2008 10:06:53 +0800 From: ZhangDong To: Christian Vogt Message-id: Date: Tue, 14 Oct 2008 10:06:53 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <887E9B88-3DB9-4E79-9A4C-9CC5A7150333@nomadiclab.com> References: <4EC04196-A0A9-4CFD-A87F-84466963AECF@nomadiclab.com> <48F1C0DC.6070409@it.uc3m.es> <5CE879A0D1904950B87A5507C7C86E5E@userPC> <887E9B88-3DB9-4E79-9A4C-9CC5A7150333@nomadiclab.com> Content-transfer-encoding: quoted-printable Cc: SAVI Mailing List Subject: [savi] =?gb2312?b?KioqU1BBTSoqKiA1LjAzNSAoNSkgu9i4tDogUmU6ICBE?= =?gb2312?b?ZWZpbmluZyB0aGUgU29sdXRpb24gU3BhY2UgZm9yIFNBVkk=?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2008 02:06:47 -0000 Hi all=2C In my opinion=2C a SAVI solution based on SeND is feasible=2E Perhaps th= e solution may depend on CGA(Cryptographically Generated Addresses) dire= ctly=2C which also is used in SeND=2E However the charter requests that both IPv4 and IPv6 need to be covered=2E= SeND is a protocol of IPv6=2E That is to say the SeND-based solution mu= st be implemented in IPv6 network=2E How about IPv4=3F Is this a problem=3F Or I miss some discussion in IETF 72 =3F Best Regards ----- =D4=AD=CA=BC=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A Christian Vogt =3Cchristian=2Evogt=40nomadiclab=2E= com=3E =C8=D5=C6=DA=3A 2008=C4=EA 10=D4=C2 13=C8=D5=2C =D0=C7=C6=DA=D2=BB=2C =CF= =C2=CE=E710=3A55 =D6=F7=CC=E2=3A Re=3A =5Bsavi=5D Defining the Solution Space for SAVI =CA=D5=BC=FE=C8=CB=3A Jun Bi =3Cjunbi=40cernet=2Eedu=2Ecn=3E =B3=AD=CB=CD=3A SAVI Mailing List =3Csavi=40ietf=2Eorg=3E =3E Jun Bi wrote=3A =3E = =3E =3E I thought during the IETF72 SAVI WG discussion=2C as Jari and o= thers =3E =3E pointed=2C if the solution is revised as an extension of an exi= sting =3E =3E protocol (e=2Eg=2E=2C SeND or others)=2C then it somehow won=27= t be a new = =3E =3E protocol =3E =3E or host change=2E =3E = =3E Jun and all=2C =3E = =3E what was considered at IETF 72 was not to extend SeND (or another =3E protocol)=2E It was the possibility to request from IESG the addit= ion = =3E of =3E a charter deliverable for a SeND-based SAVI solution extension=2E = The =3E idea was that the working group could work on both=2C a basic =3E non-cryptographic SAVI solution=2C plus a more secure extension tha= t would =3E be based on (unchanged) SeND=2E This would allow easy deployment o= f the =3E basic SAVI solution without special prerequisites=2E And in those =3E environments where SeND is deployed=2C stronger security could opti= onally =3E be obtained by using the SAVI solution extension=2E =3E = =3E - Christian =3E = =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =3E savi mailing list =3E savi=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/savi =3E From junbi@tsinghua.edu.cn Mon Oct 13 20:46:14 2008 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 E32273A6AEE for ; Mon, 13 Oct 2008 20:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRJhSt1uOQ1h for ; Mon, 13 Oct 2008 20:46:13 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id 8D0103A6A1D for ; Mon, 13 Oct 2008 20:46:12 -0700 (PDT) Received: from [114.138.195.77] (helo=userPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.63) (envelope-from ) id 1Kpaqr-0004dW-RE; Tue, 14 Oct 2008 11:45:42 +0800 Message-ID: <24038106F11D4E2082A3C3A66990ECAB@userPC> From: "Jun Bi" To: "Christian Vogt" References: <4EC04196-A0A9-4CFD-A87F-84466963AECF@nomadiclab.com> <48F1C0DC.6070409@it.uc3m.es> <5CE879A0D1904950B87A5507C7C86E5E@userPC> <887E9B88-3DB9-4E79-9A4C-9CC5A7150333@nomadiclab.com> In-Reply-To: <887E9B88-3DB9-4E79-9A4C-9CC5A7150333@nomadiclab.com> Date: Tue, 14 Oct 2008 11:45:23 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 Cc: SAVI Mailing List Subject: Re: [savi] Defining the Solution Space for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jun Bi List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2008 03:46:15 -0000 Hi Christian, Thank you very much for the clarification. I actually meant the same: considering a SeND-based SAVI solution extension. By the way, to investigating existing protocol, binding ID with IP address, HIP is also being considered for the host ID, Andrei Gurtov showed interests in IETF72. Best Regards, Jun Bi ----- Original Message ----- From: "Christian Vogt" To: "Jun Bi" Cc: "marcelo bagnulo braun" ; "SAVI Mailing List" Sent: Monday, October 13, 2008 10:55 PM Subject: Re: [savi] Defining the Solution Space for SAVI > Jun Bi wrote: > >> I thought during the IETF72 SAVI WG discussion, as Jari and others >> pointed, if the solution is revised as an extension of an existing >> protocol (e.g., SeND or others), then it somehow won't be a new protocol >> or host change. > > Jun and all, > > what was considered at IETF 72 was not to extend SeND (or another > protocol). It was the possibility to request from IESG the addition of > a charter deliverable for a SeND-based SAVI solution extension. The > idea was that the working group could work on both, a basic > non-cryptographic SAVI solution, plus a more secure extension that would > be based on (unchanged) SeND. This would allow easy deployment of the > basic SAVI solution without special prerequisites. And in those > environments where SeND is deployed, stronger security could optionally > be obtained by using the SAVI solution extension. > > - Christian > > > From marcelo@it.uc3m.es Tue Oct 14 11:26:38 2008 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 5617C3A6862 for ; Tue, 14 Oct 2008 11:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.401 X-Spam-Level: X-Spam-Status: No, score=-4.401 tagged_above=-999 required=5 tests=[AWL=-0.639, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 WZt76fFN1EIZ for ; Tue, 14 Oct 2008 11:26:37 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 3CBBE3A67F8 for ; Tue, 14 Oct 2008 11:26:36 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (99.pool85-53-140.dynamic.orange.es [85.53.140.99])by smtp03.uc3m.es (Postfix) with ESMTP id B8E386A72B0; Tue, 14 Oct 2008 20:26:33 +0200 (CEST) Message-ID: <48F4E459.7000700@it.uc3m.es> Date: Tue, 14 Oct 2008 20:26:33 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Christian Vogt References: <4EC04196-A0A9-4CFD-A87F-84466963AECF@nomadiclab.com> <48F1C0DC.6070409@it.uc3m.es> <22867E3F-3EE7-4DF7-AE99-827586F51C9C@nomadiclab.com> In-Reply-To: <22867E3F-3EE7-4DF7-AE99-827586F51C9C@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-13.6027 TC:1F TRN:43 TV:5.5.1026(16218.001) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: SAVI Mailing List Subject: Re: [savi] Defining the Solution Space for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2008 18:26:38 -0000 Christian Vogt escribió: > Marcelo - > >>> Solutions in bucket (a) bind IP addresses to credentials and therefore >>> involve cryptography. Solutions in bucket (b) bind IP addresses to >>> physical or link layer entities and are non-cryptographic. >>> Consequently, >>> solutions in bucket (b) >> >> You mean that solutions in class a? > > Yep. > > >>> can detect all types of spoofing attacks, but are more complex to setup >>> and maintain. Solutions in bucket (a) are >> >> You mean that solutions in class b? > > Yep. :-) > > >>> rather lightweight and easy to deploy, although they may not be able to >>> protect against all types of spoofing attacks >>> >>> The working group must now come to a conclusion as to which class a >>> working group solution should fit in. >> >> but the charter already makes that decision for us doesn't it? > > Not necessarily. The intention of the charter is to avoid host changes > and new protocols. Using an existing protocol, unchanged, for the > purpose of verifying a host's IP address ownership is, of course, > in-charter. What if a SAVI device could use SeND as is? agree, this is perfectly on charter but i haven't seen any proposal in this space i.e. reunsing without requiring changes Moreover, i doubt we will be able to achieve a strong solution on these lines, cause current data packets don't carry any mean to verify the source address, even when CGAs are used, so in order to actually achieve a strong security mechanism, we need means to proof the host that has generated a given data packet and not the neighbor discovery messages (which is basically the scope of send) > Then why not > increase security based on SeND in those environments where it is > deployed? The disadvantage would be a significant applicability > limitation because SeND deployment would become a prerequisite for SAVI > deployment. > I think that a send based solution could provide more security than a neighbour discivery based solution, but i still don't think we will achieve strong security if we don't modify send, that is why i still think that the charter already defines that strong security are out of the charter regards, marcelo > - Christian > > > From marcelo@it.uc3m.es Tue Oct 14 11:28:22 2008 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 EECD53A6C15 for ; Tue, 14 Oct 2008 11:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.337 X-Spam-Level: X-Spam-Status: No, score=-4.337 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 DgO8bZhct9Qu for ; Tue, 14 Oct 2008 11:28:22 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 146683A6BE6 for ; Tue, 14 Oct 2008 11:28:22 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (99.pool85-53-140.dynamic.orange.es [85.53.140.99])by smtp03.uc3m.es (Postfix) with ESMTP id 0D4626A72B0; Tue, 14 Oct 2008 20:28:36 +0200 (CEST) Message-ID: <48F4E4D3.1040209@it.uc3m.es> Date: Tue, 14 Oct 2008 20:28:35 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Christian Vogt References: <4EC04196-A0A9-4CFD-A87F-84466963AECF@nomadiclab.com> <48F1C0DC.6070409@it.uc3m.es> <5CE879A0D1904950B87A5507C7C86E5E@userPC> <887E9B88-3DB9-4E79-9A4C-9CC5A7150333@nomadiclab.com> In-Reply-To: <887E9B88-3DB9-4E79-9A4C-9CC5A7150333@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-16.7861 TC:1F TRN:28 TV:5.5.1026(16218.001) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: SAVI Mailing List Subject: Re: [savi] Defining the Solution Space for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2008 18:28:23 -0000 Christian Vogt escribió: > Jun Bi wrote: > >> I thought during the IETF72 SAVI WG discussion, as Jari and others >> pointed, if the solution is revised as an extension of an existing >> protocol (e.g., SeND or others), then it somehow won't be a new protocol >> or host change. > > Jun and all, > > what was considered at IETF 72 was not to extend SeND (or another > protocol). It was the possibility to request from IESG the addition of > a charter deliverable for a SeND-based SAVI solution extension. The > idea was that the working group could work on both, a basic > non-cryptographic SAVI solution, plus a more secure extension that would > be based on (unchanged) SeND. This would allow easy deployment of the > basic SAVI solution without special prerequisites. And in those > environments where SeND is deployed, stronger security could optionally > be obtained by using the SAVI solution extension. > that makes sense to me moreover, i think that if we define a solution based on ND, it would make sense as well to figure out how it works with send (both unchanged i mean of course). I would even argue that this would fit in the current charter, since send is just the secure version of nd regards, marcelo > - Christian > > > From marcelo@it.uc3m.es Tue Oct 14 11:30:51 2008 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 10F5E3A6784 for ; Tue, 14 Oct 2008 11:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.468 X-Spam-Level: X-Spam-Status: No, score=-0.468 tagged_above=-999 required=5 tests=[AWL=-4.340, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 NQM4UXCrenUO for ; Tue, 14 Oct 2008 11:30:50 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id E4D713A6774 for ; Tue, 14 Oct 2008 11:30:49 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (99.pool85-53-140.dynamic.orange.es [85.53.140.99])by smtp02.uc3m.es (Postfix) with ESMTP id 534BF5BC4B9; Tue, 14 Oct 2008 20:30:45 +0200 (CEST) Message-ID: <48F4E554.1030507@it.uc3m.es> Date: Tue, 14 Oct 2008 20:30:44 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: ZhangDong References: <4EC04196-A0A9-4CFD-A87F-84466963AECF@nomadiclab.com><48F1C0DC.6 070409@it.uc3m.es> <5CE879A0D1904950B87A5507C7C86E5E@userPC><887E9B88-3DB9-4E79-9A4C-9CC5A715 0333@nomadiclab.com> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-27.4013 TC:1F TRN:39 TV:5.5.1026(16218.001) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Christian Vogt , SAVI Mailing List Subject: Re: [savi] =?gb2312?b?KioqU1BBTSoqKiA1LjAzNSAoNSkgu9i4tDogUmU6ICBE?= =?gb2312?b?ZWZpbmluZyB0aGUgU29sdXRpb24gU3BhY2UgZm9yIFNBVkk=?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2008 18:30:51 -0000 ZhangDong escribi¨®: > Hi all, > > In my opinion, a SAVI solution based on SeND is feasible. Perhaps the solution may depend on CGA(Cryptographically Generated Addresses) directly, which also is used in SeND. > However the charter requests that both IPv4 and IPv6 need to be covered. SeND is a protocol of IPv6. That is to say the SeND-based solution must be implemented in IPv6 network. How about IPv4? > Is this a problem? I don't think this is a problem we can do in IPv4 what is possible and maybe do more in ipv6 cause we have additional tools regards, marcelo > Or I miss some discussion in IETF 72 ? > > Best Regards > > > ----- ԭʼÓʼþ ----- > ·¢¼þÈË: Christian Vogt > ÈÕÆÚ: 2008Äê 10Ô 13ÈÕ, ÐÇÆÚÒ», ÏÂÎç10:55 > Ö÷Ìâ: Re: [savi] Defining the Solution Space for SAVI > ÊÕ¼þÈË: Jun Bi > ³­ËÍ: SAVI Mailing List > > > >> Jun Bi wrote: >> >> > I thought during the IETF72 SAVI WG discussion, as Jari and others >> > pointed, if the solution is revised as an extension of an existing >> > protocol (e.g., SeND or others), then it somehow won't be a new >> > protocol >> > or host change. >> >> Jun and all, >> >> what was considered at IETF 72 was not to extend SeND (or another >> protocol). It was the possibility to request from IESG the addition >> of >> a charter deliverable for a SeND-based SAVI solution extension. The >> idea was that the working group could work on both, a basic >> non-cryptographic SAVI solution, plus a more secure extension that would >> be based on (unchanged) SeND. This would allow easy deployment of the >> basic SAVI solution without special prerequisites. And in those >> environments where SeND is deployed, stronger security could optionally >> be obtained by using the SAVI solution extension. >> >> - Christian >> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> >> > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From christian.vogt@nomadiclab.com Tue Oct 14 12:44:52 2008 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 6C36E3A6801 for ; Tue, 14 Oct 2008 12:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 cyvDm9n-klsQ for ; Tue, 14 Oct 2008 12:44:51 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 57FE73A63EC for ; Tue, 14 Oct 2008 12:44:51 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id D1C041EF158; Tue, 14 Oct 2008 22:45:45 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 96D8F1EF157; Tue, 14 Oct 2008 22:45:45 +0300 (EEST) Message-Id: <5C2EF721-0B1A-4244-97B3-6310EC389DBF@nomadiclab.com> From: Christian Vogt To: marcelo bagnulo braun In-Reply-To: <48F4E459.7000700@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 14 Oct 2008 22:45:45 +0300 References: <4EC04196-A0A9-4CFD-A87F-84466963AECF@nomadiclab.com> <48F1C0DC.6070409@it.uc3m.es> <22867E3F-3EE7-4DF7-AE99-827586F51C9C@nomadiclab.com> <48F4E459.7000700@it.uc3m.es> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV using ClamSMTP Cc: SAVI Mailing List Subject: Re: [savi] Defining the Solution Space for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2008 19:44:52 -0000 >> Not necessarily. The intention of the charter is to avoid host >> changes >> and new protocols. Using an existing protocol, unchanged, for the >> purpose of verifying a host's IP address ownership is, of course, >> in-charter. What if a SAVI device could use SeND as is? > > agree, this is perfectly on charter > > but i haven't seen any proposal in this space i.e. reunsing without > requiring changes Me neither. :-) > Moreover, i doubt we will be able to achieve a strong solution on > these > lines, cause current data packets don't carry any mean to verify the > source address, even when CGAs are used, so in order to actually > achieve > a strong security mechanism, we need means to proof the host that has > generated a given data packet and not the neighbor discovery messages > (which is basically the scope of send) That's right, the security improvements are limited. Using unmodified SeND could prevent the spoofing of unused and off-link IP addresses. And for non-shared link segments between a host and a SAVI device, this implies that the host could not use a false IP address. But it seems that spoofing a neighbor's IP address is still possible once that neighbor has convinced the SAVI device that its IP address is OK. - Christian From marcelo@it.uc3m.es Wed Oct 15 00:01:52 2008 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 159F33A683F for ; Wed, 15 Oct 2008 00:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.923 X-Spam-Level: X-Spam-Status: No, score=-3.923 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 16RmwArt0tsS for ; Wed, 15 Oct 2008 00:01:51 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id C510D3A67A6 for ; Wed, 15 Oct 2008 00:01:50 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (99.pool85-53-140.dynamic.orange.es [85.53.140.99])by smtp02.uc3m.es (Postfix) with ESMTP id 522BD5C1614; Wed, 15 Oct 2008 09:02:47 +0200 (CEST) Message-ID: <48F59596.7070203@it.uc3m.es> Date: Wed, 15 Oct 2008 09:02:46 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Christian Vogt References: <4EC04196-A0A9-4CFD-A87F-84466963AECF@nomadiclab.com> <48F1C0DC.6070409@it.uc3m.es> <22867E3F-3EE7-4DF7-AE99-827586F51C9C@nomadiclab.com> <48F4E459.7000700@it.uc3m.es> <5C2EF721-0B1A-4244-97B3-6310EC389DBF@nomadiclab.com> In-Reply-To: <5C2EF721-0B1A-4244-97B3-6310EC389DBF@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-14.5645 TC:1F TRN:57 TV:5.5.1026(16218.005) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: SAVI Mailing List Subject: Re: [savi] Defining the Solution Space for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2008 07:01:52 -0000 Christian Vogt escribió: >>> Not necessarily. The intention of the charter is to avoid host changes >>> and new protocols. Using an existing protocol, unchanged, for the >>> purpose of verifying a host's IP address ownership is, of course, >>> in-charter. What if a SAVI device could use SeND as is? >> >> agree, this is perfectly on charter >> >> but i haven't seen any proposal in this space i.e. reunsing without >> requiring changes > > Me neither. :-) > > >> Moreover, i doubt we will be able to achieve a strong solution on these >> lines, cause current data packets don't carry any mean to verify the >> source address, even when CGAs are used, so in order to actually achieve >> a strong security mechanism, we need means to proof the host that has >> generated a given data packet and not the neighbor discovery messages >> (which is basically the scope of send) > > That's right, the security improvements are limited. Using unmodified > SeND could prevent the spoofing of unused and off-link IP addresses. > And for non-shared link segments between a host and a SAVI device, this > implies that the host could not use a false IP address. But it seems > that spoofing a neighbor's IP address is still possible once that > neighbor has convinced the SAVI device that its IP address is OK. > Well, actually, you could build a SeND based solution that actually does provides a bit more than that. SeND basically uses two tools for security: CGAs for hosts and certificates for routers. Now, we can then have two trust models. For hosts, i only allow them to send packets that correspond to their CGA and that the prefix corresponds to one of the prefixes authorized for the link (this may be tricky cause i would assume that any router on the link is able to learn all prefixes that are available on the link, which may not be guaranteed). this basically means that each time a router receives a packet for a host that it hasn't got its MAC address for, it verifies that the prefix belong to one of the on-link prefixes and if yes, then it uses SeND to verify the CGA. the router should also do that when there is change in the mac, and the router can run periodic tests, so that he is sure that an attacker is not using the address once the original host has left. For routers, i basically need to trust them to send packets from any source address. But that may be compatible with the model that we have certs for routers. So, i think that a send based solution using SeND protocol unmodified from the hosts perspective but using additional checks in the routers could provide a somehow higher level of security. We could try to extend this for regular ND. Actually, i think that one possible trust model, if we don't assume that ingress filtering is deployed, is to have the routers to know: - which are the other routers (i.e. the nodes on the link that are authorized to send packets from any source address) - whcih are the prefixes availabel on the link. If you assume that routers know this information, then, you could actually achieve higher security, cause the regular nodes can only send packets from on-link prefix and probably you can limit the number of source address they should use on any period of time Regards, marcelo > - Christian > > > From marcelo@it.uc3m.es Wed Oct 15 00:42:58 2008 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 689173A6C53 for ; Wed, 15 Oct 2008 00:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 cZaGwwQQ0kje for ; Wed, 15 Oct 2008 00:42:57 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id AB9643A67A6 for ; Wed, 15 Oct 2008 00:42:56 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (99.pool85-53-140.dynamic.orange.es [85.53.140.99])by smtp02.uc3m.es (Postfix) with ESMTP id 07F705C1997; Wed, 15 Oct 2008 09:43:52 +0200 (CEST) Message-ID: <48F59F38.2070902@it.uc3m.es> Date: Wed, 15 Oct 2008 09:43:52 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Christian Vogt References: <48F30CB6.9090508@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-19.6979 TC:1F TRN:84 TV:5.5.1026(16218.005) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: SAVI Mailing List Subject: Re: [savi] Scope of savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2008 07:42:58 -0000 Hi Christian, Christian Vogt escribió: > Marcelo, > > you are raising a very good question. But I think you are too fast. :-) > What we should in my opinion consider first is the higher-level question > of where we want SAVI solutions to be deployed. Or, the same question > phrased more specifically: Which (existing and unchanged) protocols do > we want a SAVI solution to rely upon? Should it be plain IPv6 Neighbor > Discovery and ARP? Should it be SeND? Or should it be something even > more sophisticated? We need to answer this question first in order to > be able to answer the more specific question you are raising. > this is my take on this. First, i understand that the constraints are: - no changes to hosts - SAVI must run either on the router or in the bridge So, in order to communicate with the hosts, we can only leverage on existing protocols. I understand that the possible candidates are: - ARP/ND - SeND - DHCP Any others? (i don't see any other one...) However, we could make changes to the router behavior or bridge. So for the router parts, we could either think to extend any of the previous ones or we could define a new protocol for the communication of savi routers/bridges. However, i am not ure if we are even allowed to do that by the charter, since it states: The WG is prohibited from creating its own protocols or extensions/modifications of current protocols. So, if we take this literally, we could only re use current protocol messages and maybe do additional checks, which scopes the work even more. A second high level question i guess is who will be the policing agents. I mean, who is going to check that the source addresses are not spoofed. I think that the clear candidates are again the router and the bridges. As a strawman, i think the best way would be to try to see how far can we go with the more constrained scenario. i.e. we do not define a new protocol and we don't define any extension to existent protocols and try to re use existent messages to see how much can we do. If the result is clearly no satisfactory, we can then argue that we need more modifcations to make something decent. > Your question addresses a very specific, technical goal. It falls into > the same category as several other questions that have been raised: > > (a) Should SAVI support hosts with multiple IP addresses per interface? yes, well at least in IPv6 this is a must. For ipv4, i guess we could live without this or treat as ane exception > > (b) Should SAVI support hosts with multiple link layer addresses per > interface? > > (c) Should SAVI support hosts that move at the link layer? > > (d) Should SAVI support hosts that are multi-homed at the link layer? > For all these question, i think we should try. I mean, i think we should start by trying to find a solution that relies on exsitnet protocols and does not requires any new message or new protocol and see if we can support these cases. In other words, i think it important to try to do soemthing that is deployeable (i.e. dos not requires new messages nor hos changes) than supporting these > (e) Should SAVI support routers? > I don't understnad what you mean by this I understand that we need to support a scenario where there are multiple routers in one link > (f) Should SAVI support NATs? > not sure hwy this is a problem.. i think this is easier to support than a normal router, since the packets coming from the nat actually carry the nat source address (at least on the public side) which makes life easier imho > (g) Should SAVI support anycast addressing? > imho this one fails in the category of nice to have > (h) Should SAVI detect spoofed unused IP addresses? > i guess so > (i) Should SAVI detect spoofed off-link IP addresses? > this is essentially my question of ingress filtering I think we need to assume a trust model One option is as i mentioned in the other email, to assume that routers are trustworthy and that they and only they can send packets coming from source address with an off link prefix. If you do that everywhere, you are actually protecting from spoofed off link IP addresses. the next question is how do routers verify that the source address is not spoofed if the turst chain is broken, i.e. when there is link with a router that cannot be trusted. In that case, we can fall back to ingress filtering, i guess. But new ideas would be great in this area. So, we can split the problem in two here: - One part is how to verify that on link addresses are not spoofed. i.e. addresses that are supposed to be on the link are actually used by a host that owns them in some way. I think this is the "easiest" problem and we can find somehow efficient ways todo this - the other part, is when a packet is flowing through a link with a source address that doesn't belong to the link, how we can verify that the source address has not been spoofed. This is harder. Either requires some trust chain, where everyone implements the previous security technique i.e. if every on link address is not spoofed and everyone does the same, then the source address are also valid in transit (this option could be suitable for a intra site communication). Or the other option is to rely in something like ingress filtering. > (j) Your question: Should SAVI complement or substitute ingress > filtering? > > It is tempting to answer all of these questions with "yes". But without > knowing which protocol SAVI can rely upon and make use of, answering any > of these question with "yes" would be dangerous: It would set us a goal > that we may not be able to meet. > > I would therefore suggest to first revisit the initial, high-level > question of where in the tradeoff space between strong security and easy > deployability a SAVI solution should reside in our opinion. We can > answer this question very specifically by pinpointing the (existing and > unchanged) protocols that we want a SAVI solution to rely upon -- > keeping in mind that we cannot create new protocols. My take is that we should go as far as we can with exsiting protocol and not changing the host behaviour in no way. We should set us the goal of trying to achieve the above features, but with the preivous constraint. Morevoer, for IPv6, i think we should have a basic solution using ND and another more secure one relying on send (defining only a send based solution is a not such a good iea cause the deployment of send is very limited) Regards, > > Once we have settled on an answer to this high-level question, we will > have a much clearer understanding of what is achievable and what is not. > And we will be able to confidently answer the questions that you are > raising, as well as the other more specific questions in the list above. > > - Christian > > > On Oct 13, 2008, marcelo bagnulo braun wrote: > >> Hi, >> >> I am trying to understand what would be the scope of a SAVI solution. A >> first question that comes to my mind when i start thinking about this is >> whether we want a solution that complements ingress filtering or we want >> a solution that substitutes ingress filtering. In other words, one >> option would be to assume that we have ingress filtering and try to >> define a SAVI solution that mitigates or even eliminates the remaining >> threats. As the threat analysis draft describes, even if we have ingress >> filtering deployed, we would still have the potential threat that a node >> located in a give LAN could spoof the address of another host of the >> same LAN and that would not be detected by the ingress filters. I >> understand that several of the proposals (like Erik's FCFS or Fred's >> SAVA implementation) go in that direction. The other option is to state >> that ingress filtering is far from deployed and we need to define a SAVI >> solution that is stand alone, i.e. that protects against the threats >> that ingress filtering is supposed to protect against. I am not sure if >> we can do much better than ingress filtering with the imposed >> constraints, but since i haven't seen this acknowledged in the charter, >> it seemed worthwhile to me to make this matters clear >> >> Regards, marcelo > > > From iljitsch@muada.com Wed Oct 15 02:50:47 2008 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 2FE763A6920 for ; Wed, 15 Oct 2008 02:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 S4ksZ5qpq2lt for ; Wed, 15 Oct 2008 02:50:39 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 0D4BF3A691A for ; Wed, 15 Oct 2008 02:50:38 -0700 (PDT) Received: from nirrti.it.uc3m.es (nirrti.it.uc3m.es [163.117.139.38]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m9F9pGPp089377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Oct 2008 11:51:17 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: marcelo bagnulo braun In-Reply-To: <48F59F38.2070902@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 15 Oct 2008 11:51:29 +0200 References: <48F30CB6.9090508@it.uc3m.es> <48F59F38.2070902@it.uc3m.es> X-Mailer: Apple Mail (2.929.2) Cc: Christian Vogt , SAVI Mailing List Subject: Re: [savi] Scope of savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2008 09:50:47 -0000 On 15 okt 2008, at 9:43, marcelo bagnulo braun wrote: > First, i understand that the constraints are: > - no changes to hosts > - SAVI must run either on the router or in the bridge > So, in order to communicate with the hosts, we can only leverage on > existing protocols. I understand that the possible candidates are: > - ARP/ND > - SeND > - DHCP Not all hosts support SEND or DHCP. In fact, very few support SEND, and presumably (haven't seen this in the wild), hosts that _can_ do SEND may also use stateless autoconfig, DHCPv6 address assignment or manual configuration. So this pretty much makes it impossible to depend on SEND... >> (f) Should SAVI support NATs? A NAT box acts as a router on the private side and as a host on the public side. So there is no specific action necessary to support NAT. From marcelo@it.uc3m.es Wed Oct 15 03:01:56 2008 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 0ECCA3A6946 for ; Wed, 15 Oct 2008 03:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 nje62Wl7gPJo for ; Wed, 15 Oct 2008 03:01:52 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 2E1973A68B1 for ; Wed, 15 Oct 2008 03:01:52 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (99.pool85-53-140.dynamic.orange.es [85.53.140.99])by smtp03.uc3m.es (Postfix) with ESMTP id E3CD16A7B22; Wed, 15 Oct 2008 12:02:15 +0200 (CEST) Message-ID: <48F5BFA7.6070701@it.uc3m.es> Date: Wed, 15 Oct 2008 12:02:15 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <48F30CB6.9090508@it.uc3m.es> <48F59F38.2070902@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-10.2579 TC:1F TRN:22 TV:5.5.1026(16218.006) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Christian Vogt , SAVI Mailing List Subject: Re: [savi] Scope of savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2008 10:01:56 -0000 Iljitsch van Beijnum escribió: > On 15 okt 2008, at 9:43, marcelo bagnulo braun wrote: > >> First, i understand that the constraints are: >> - no changes to hosts >> - SAVI must run either on the router or in the bridge > >> So, in order to communicate with the hosts, we can only leverage on >> existing protocols. I understand that the possible candidates are: >> - ARP/ND >> - SeND >> - DHCP > > Not all hosts support SEND or DHCP. In fact, very few support SEND, > and presumably (haven't seen this in the wild), hosts that _can_ do > SEND may also use stateless autoconfig, DHCPv6 address assignment or > manual configuration. So this pretty much makes it impossible to > depend on SEND... > I am not arguing to define a solution that only works when send is available, i am arguing for having a solution that when send is available, takes advantage of this and is more secure regards, marcelo >>> (f) Should SAVI support NATs? > > A NAT box acts as a router on the private side and as a host on the > public side. So there is no specific action necessary to support NAT. > > > From junbi@tsinghua.edu.cn Wed Oct 15 11:07:10 2008 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 BDFAF3A6963 for ; Wed, 15 Oct 2008 11:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] 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 BStOW3qEUHXo for ; Wed, 15 Oct 2008 11:07:09 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id 8A2323A6768 for ; Wed, 15 Oct 2008 11:07:09 -0700 (PDT) Received: from [59.66.24.113] (helo=userPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.63) (envelope-from ) id 1KqAmN-0006oh-W6; Thu, 16 Oct 2008 02:07:28 +0800 Message-ID: <8651E85A8317465899BDE54C6F4E28D8@userPC> From: "Jun Bi" To: "Christian Vogt" , "marcelo bagnulo braun" References: <4EC04196-A0A9-4CFD-A87F-84466963AECF@nomadiclab.com><48F1C0DC.6070409@it.uc3m.es><22867E3F-3EE7-4DF7-AE99-827586F51C9C@nomadiclab.com><48F4E459.7000700@it.uc3m.es> <5C2EF721-0B1A-4244-97B3-6310EC389DBF@nomadiclab.com> In-Reply-To: <5C2EF721-0B1A-4244-97B3-6310EC389DBF@nomadiclab.com> Date: Wed, 15 Oct 2008 19:55:30 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 Cc: SAVI Mailing List Subject: Re: [savi] Defining the Solution Space for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jun Bi List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2008 18:07:10 -0000 After IETF72, a new version of CSA draft is designed making use of SeND in the address authorization phase (phase 1). This will be delivered soon. thanks, Jun Bi ----- Original Message ----- From: "Christian Vogt" To: "marcelo bagnulo braun" Cc: "SAVI Mailing List" Sent: Wednesday, October 15, 2008 3:45 AM Subject: Re: [savi] Defining the Solution Space for SAVI >>> Not necessarily. The intention of the charter is to avoid host changes >>> and new protocols. Using an existing protocol, unchanged, for the >>> purpose of verifying a host's IP address ownership is, of course, >>> in-charter. What if a SAVI device could use SeND as is? >> >> agree, this is perfectly on charter >> >> but i haven't seen any proposal in this space i.e. reunsing without >> requiring changes > > Me neither. :-) > > >> Moreover, i doubt we will be able to achieve a strong solution on these >> lines, cause current data packets don't carry any mean to verify the >> source address, even when CGAs are used, so in order to actually achieve >> a strong security mechanism, we need means to proof the host that has >> generated a given data packet and not the neighbor discovery messages >> (which is basically the scope of send) > > That's right, the security improvements are limited. Using unmodified > SeND could prevent the spoofing of unused and off-link IP addresses. > And for non-shared link segments between a host and a SAVI device, this > implies that the host could not use a false IP address. But it seems > that spoofing a neighbor's IP address is still possible once that > neighbor has convinced the SAVI device that its IP address is OK. > > - Christian > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > > From christian.vogt@nomadiclab.com Wed Oct 15 16:58:41 2008 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 C48223A6AAE for ; Wed, 15 Oct 2008 16:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 BqwaeGEtELwx for ; Wed, 15 Oct 2008 16:58:40 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 123233A6AAD for ; Wed, 15 Oct 2008 16:58:40 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 6875F1EF158; Thu, 16 Oct 2008 02:59:38 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id EA49D1EF151; Thu, 16 Oct 2008 02:59:37 +0300 (EEST) Message-Id: From: Christian Vogt To: marcelo bagnulo braun In-Reply-To: <48F59596.7070203@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 16 Oct 2008 02:59:37 +0300 References: <4EC04196-A0A9-4CFD-A87F-84466963AECF@nomadiclab.com> <48F1C0DC.6070409@it.uc3m.es> <22867E3F-3EE7-4DF7-AE99-827586F51C9C@nomadiclab.com> <48F4E459.7000700@it.uc3m.es> <5C2EF721-0B1A-4244-97B3-6310EC389DBF@nomadiclab.com> <48F59596.7070203@it.uc3m.es> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV using ClamSMTP Cc: SAVI Mailing List Subject: Re: [savi] Defining the Solution Space for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2008 23:58:41 -0000 marcelo bagnulo braun wrote: > Well, actually, you could build a SeND based solution that actually > does > provides a bit more than that. SeND basically uses two tools for > security: CGAs for hosts and certificates for routers. Now, we can > then > have two trust models. For hosts, i only allow them to send packets > that > correspond to their CGA and that the prefix corresponds to one of the > prefixes authorized for the link (this may be tricky cause i would > assume that any router on the link is able to learn all prefixes that > are available on the link, which may not be guaranteed). this > basically > means that each time a router receives a packet for a host that it > hasn't got its MAC address for, it verifies that the prefix belong to > one of the on-link prefixes and if yes, then it uses SeND to verify > the > CGA. the router should also do that when there is change in the mac, > and > the router can run periodic tests, so that he is sure that an attacker > is not using the address once the original host has left. For > routers, i > basically need to trust them to send packets from any source address. > But that may be compatible with the model that we have certs for > routers. Cool. Now we have a proposal that takes advantage of SeND unmodified. :-) > We could try to extend this for regular ND. Actually, i think that one > possible trust model, if we don't assume that ingress filtering is > deployed, is to have the routers to know: - which are the other > routers > (i.e. the nodes on the link that are authorized to send packets from > any > source address) - whcih are the prefixes availabel on the link. The opposite approach seems also feasible: to rely on ingress filtering. As a matter of fact, the 2nd of your assumptions ("routers know which prefixes are on-link"), is already sufficient for routers to do ingress filtering. And if they do it, you no longer need the 1st assumption ("routers know other routers"), because you don't have to care about off-link source addresses anymore. In short, relying on ingress filtering reduces the source address validation problem to validating on-link source addresses. And as you say: Which source addresses are on-link is something SAVI devices can, at least in IPv6, automatically learn by listening to Router Advertisement messages. I would argue that this is reliable because the periodic retransmission of Router Advertisement messages automatically repairs occasional loss. It is also secure because an attacker does not gain anything by sending a spoofed Router Advertisement message. The transmission of a Router Advertisement message does not reduce the strictness of SAVI devices; it can at most increase the strictness. Of course, the assumption that all access routers perform ingress filtering is bold. Ingress filtering is today typically deployed further upstream to avoid having to configure it in every single access router. But perhaps access router could auto-configure ingress filtering by listening to Router Advertisement messages, just like SAVI devices might distinguish off-link and on-link addresses by listening to Router Advertisement messages... - Christian From marcelo@it.uc3m.es Thu Oct 16 00:24:23 2008 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 847C23A6ABB for ; Thu, 16 Oct 2008 00:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.891 X-Spam-Level: X-Spam-Status: No, score=-3.891 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 FzsskjQ8soVM for ; Thu, 16 Oct 2008 00:24:22 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 2D2993A69AC for ; Thu, 16 Oct 2008 00:24:21 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [85.53.133.67])by smtp01.uc3m.es (Postfix) with ESMTP id 688A8AC2137;Thu, 16 Oct 2008 09:25:20 +0200 (CEST) Message-ID: <48F6EC60.4020908@it.uc3m.es> Date: Thu, 16 Oct 2008 09:25:20 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Christian Vogt References: <4EC04196-A0A9-4CFD-A87F-84466963AECF@nomadiclab.com> <48F1C0DC.6070409@it.uc3m.es> <22867E3F-3EE7-4DF7-AE99-827586F51C9C@nomadiclab.com> <48F4E459.7000700@it.uc3m.es> <5C2EF721-0B1A-4244-97B3-6310EC389DBF@nomadiclab.com> <48F59596.7070203@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-18.7823 TC:1F TRN:77 TV:5.5.1026(16220.005) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: SAVI Mailing List Subject: Re: [savi] Defining the Solution Space for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2008 07:24:23 -0000 Christian Vogt escribió: > > marcelo bagnulo braun wrote: > >> Well, actually, you could build a SeND based solution that actually does >> provides a bit more than that. SeND basically uses two tools for >> security: CGAs for hosts and certificates for routers. Now, we can then >> have two trust models. For hosts, i only allow them to send packets that >> correspond to their CGA and that the prefix corresponds to one of the >> prefixes authorized for the link (this may be tricky cause i would >> assume that any router on the link is able to learn all prefixes that >> are available on the link, which may not be guaranteed). this basically >> means that each time a router receives a packet for a host that it >> hasn't got its MAC address for, it verifies that the prefix belong to >> one of the on-link prefixes and if yes, then it uses SeND to verify the >> CGA. the router should also do that when there is change in the mac, and >> the router can run periodic tests, so that he is sure that an attacker >> is not using the address once the original host has left. For routers, i >> basically need to trust them to send packets from any source address. >> But that may be compatible with the model that we have certs for >> routers. > > Cool. Now we have a proposal that takes advantage of SeND unmodified. > :-) > > >> We could try to extend this for regular ND. Actually, i think that one >> possible trust model, if we don't assume that ingress filtering is >> deployed, is to have the routers to know: - which are the other routers >> (i.e. the nodes on the link that are authorized to send packets from any >> source address) - whcih are the prefixes availabel on the link. > > The opposite approach seems also feasible: to rely on ingress > filtering. yes, i was trying to figure out a scheme that does not rely on ingress filtering, but if we have ingress filtering, then the problem is simplified > As a matter of fact, the 2nd of your assumptions ("routers > know which prefixes are on-link"), is already sufficient for routers to > do ingress filtering. I think we agree but just to clarify routers need to validate two types of packets afaict. They need to validate the source address of the packets generated by hosts connected to the local link For example, consider the case of router R2 validating packets generated from host H2). In order to do that, they need to know what are the prefixes assigned to the local link (pref2 in the example below). So, if a local _host_ (H2) generates a packet with a source address that does not belongs to one of these local prefixes (for example with Pref1), then the host H2 has spoofed the source address and needs to be discarded. But routers also need to deal with packets forwarded by other routers that are in transit in that link. See for example the situation where H1 sends a packet to H3. H1 will include the prefix Pref1 and send it to R1. R1 will send it to R2. Now the packet will contain a prefix Pref1 that is not one of the prefixes assigned to the local link, but the packet is legal. So, one option to make this work is to do ingress filtering based on reverse path forwarding. the other option that i was mentioning that is slightly different but could work in some trust models is that R1 knows R2 is a router, so R2 will accept packets from any source address if they are coming from R1 (an valid router) Pref1+--+ Pref2 +--+ ----------|R1|---------------------|R2|-------- | +--+ | +--+ | +--+ +--+ +--+ |H1| |H2| |H3| +--+ +--+ +--+ > And if they do it, you no longer need the 1st > assumption ("routers know other routers"), because you don't have to > care about off-link source addresses anymore. > Let me see if we agree: We are considering two options - the router knows the local prefixes and which are the routers directly connected (in this case the trsut models is that the routers are trustworthy) - the router knows the local prefixes and performs ingress filtering. (in this case, the trsut assumptions depend on what type of routing do we have. If we have default routes, you are basically trusting the router for pretty much everything, sinilar to the previous case) > In short, relying on ingress filtering reduces the source address > validation problem to validating on-link source addresses. exactly, that's why my initial question! > And as you > say: Which source addresses are on-link is something SAVI devices > can, at least in IPv6, automatically learn by listening to Router > Advertisement messages. I would argue that this is reliable because the > periodic retransmission of Router Advertisement messages automatically > repairs occasional loss. It is also secure because an attacker does not > gain anything by sending a spoofed Router Advertisement message. The > transmission of a Router Advertisement message does not reduce the > strictness of SAVI devices; it can at most increase the strictness. > i would like to think about this a bit more, to understand if this is a valid general case or there are corner cases, proxy nd for instance or other particualr configurations > Of course, the assumption that all access routers perform ingress > filtering is bold. Ingress filtering is today typically deployed further > upstream to avoid having to configure it in every single access router. right, but it really depends on the scope we have in mind for savi. If the scope is a site i.e. a solution that applies to a local site, then the assumption could be valid. Of course, what we are after is an internet wide solution, then certainly it doesn,'t but i am not sure if we will be able to do that in any case > But perhaps access router could auto-configure ingress filtering by > listening to Router Advertisement messages, just like SAVI devices might > distinguish off-link and on-link addresses by listening to Router > Advertisement messages... but that's not enough, right? we need full routing table to do it right and to cope with the cases i described above. regards, marcelo > > - Christian > > > From jari.arkko@piuha.net Thu Oct 16 04:04:11 2008 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 E916D3A6B62 for ; Thu, 16 Oct 2008 04:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 E3wcW+IYwChW for ; Thu, 16 Oct 2008 04:04:11 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id F3C5D3A6B4A for ; Thu, 16 Oct 2008 04:04:10 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 7DB2C19869F; Thu, 16 Oct 2008 14:05:11 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 31C1119863B; Thu, 16 Oct 2008 14:05:11 +0300 (EEST) Message-ID: <48F7200D.3060903@piuha.net> Date: Thu, 16 Oct 2008 14:05:49 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: marcelo bagnulo braun References: <48F30CB6.9090508@it.uc3m.es> In-Reply-To: <48F30CB6.9090508@it.uc3m.es> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: SAVI Mailing List Subject: Re: [savi] Scope of savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2008 11:04:12 -0000 > I am trying to understand what would be the scope of a SAVI solution. > A first question that comes to my mind when i start thinking about > this is whether we want a solution that complements ingress filtering > or we want a solution that substitutes ingress filtering. In other > words, one option would be to assume that we have ingress filtering > and try to define a SAVI solution that mitigates or even eliminates > the remaining threats. As the threat analysis draft describes, even if > we have ingress filtering deployed, we would still have the potential > threat that a node located in a give LAN could spoof the address of > another host of the same LAN and that would not be detected by the > ingress filters. I understand that several of the proposals (like > Erik's FCFS or Fred's SAVA implementation) go in that direction. > The other option is to state that ingress filtering is far from > deployed and we need to define a SAVI solution that is stand alone, > i.e. that protects against the threats that ingress filtering is > supposed to protect against. I am not sure if we can do much better > than ingress filtering with the imposed constraints, but since i > haven't seen this acknowledged in the charter, it seemed worthwhile to > me to make this matters clear I believe SAVI should complement ingress filtering, not replace it. Jari From jari.arkko@piuha.net Thu Oct 16 04:11:28 2008 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 196983A657C for ; Thu, 16 Oct 2008 04:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 qHwoZdgr27K7 for ; Thu, 16 Oct 2008 04:11:27 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id EE6173A6973 for ; Thu, 16 Oct 2008 04:11:26 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 8817D19869F; Thu, 16 Oct 2008 14:12:22 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 33ED619863B; Thu, 16 Oct 2008 14:12:22 +0300 (EEST) Message-ID: <48F721BC.9060401@piuha.net> Date: Thu, 16 Oct 2008 14:13:00 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Christian Vogt References: <48F30CB6.9090508@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: SAVI Mailing List Subject: Re: [savi] Scope of savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2008 11:11:28 -0000 Christian Vogt wrote: > Marcelo, > > you are raising a very good question. But I think you are too fast. :-) > What we should in my opinion consider first is the higher-level question > of where we want SAVI solutions to be deployed. Let me quote the charter: "The working group considers only solutions implemented on systems located on the same IP link as a to-be-verified node. The goal of the working group is the LAN environment and solutions running in routers or layer 3 aware Ethernet bridges." I think that is still valid. Now, taken together with the idea that we are here to address needs that have not yet been covered by ingress filtering, I think that sets your scope fairly well. > Or, the same question > phrased more specifically: Which (existing and unchanged) protocols do > we want a SAVI solution to rely upon? Should it be plain IPv6 Neighbor > Discovery and ARP? Should it be SeND? Or should it be something even > more sophisticated? These are good questions, too, but I would actually think about this in a slightly different manner. We know we want to have a solution with a higher granularity than ingress filtering, and this forces us to use more information, including looking at things like MAC addresses, ND/ARP, etc. Your other set of questions a through j are requirements or desirable properties. However, I think it would be a mistake to go about this effort in an entirely top down fashion. As you point out, it can be dangerous as there might be something we cannot achieve. As a result, I would actually recommend that you spend time going between what is possible i.e. the solution and what you want to achieve. I though the discussion we had with Erik in the first SAVI meeting was a good one in this respect. I'd be wary of creating too many new documents at this stage before the fundamental tussle between what's possible and what you want to do is a little bit clearer. Jari From christian.vogt@nomadiclab.com Thu Oct 16 06:14:16 2008 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 8922428C0DF for ; Thu, 16 Oct 2008 06:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 XCO6boHxr37I for ; Thu, 16 Oct 2008 06:14:15 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 8675C28B797 for ; Thu, 16 Oct 2008 06:14:15 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id DB5AB1EF158; Thu, 16 Oct 2008 16:15:14 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 633DF1EF157; Thu, 16 Oct 2008 16:15:14 +0300 (EEST) Message-Id: <149A9BFC-8265-4753-A6B8-007E8B3E9C64@nomadiclab.com> From: Christian Vogt To: marcelo bagnulo braun In-Reply-To: <48F6EC60.4020908@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 16 Oct 2008 16:15:13 +0300 References: <4EC04196-A0A9-4CFD-A87F-84466963AECF@nomadiclab.com> <48F1C0DC.6070409@it.uc3m.es> <22867E3F-3EE7-4DF7-AE99-827586F51C9C@nomadiclab.com> <48F4E459.7000700@it.uc3m.es> <5C2EF721-0B1A-4244-97B3-6310EC389DBF@nomadiclab.com> <48F59596.7070203@it.uc3m.es> <48F6EC60.4020908@it.uc3m.es> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV using ClamSMTP Cc: SAVI Mailing List Subject: Re: [savi] Defining the Solution Space for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2008 13:14:16 -0000 Marcelo - >> As a matter of fact, the 2nd of your assumptions ("routers >> know which prefixes are on-link"), is already sufficient for >> routers to >> do ingress filtering. > > I think we agree but just to clarify > routers need to validate two types of packets afaict. > They need to validate the source address of the packets generated by > hosts connected to the local link. [...] But routers also need to > deal with packets forwarded by other routers that are in transit in > that link. That's right. And the second of these is what we could potentially solve by relying on ingress filtering. > Let me see if we agree: > We are considering two options > - the router knows the local prefixes and which are the routers > directly connected (in this case the trsut models is that the > routers are trustworthy) > - the router knows the local prefixes and performs ingress > filtering. (in this case, the trsut assumptions depend on what type > of routing do we have. If we have default routes, you are basically > trusting the router for pretty much everything, sinilar to the > previous case) Yes, these are two options we have for dealing with routers. Referring to your statement "trusting the router for pretty much everything": Do you feel that this option would offload too much security to ingress filtering? >> Of course, the assumption that all access routers perform ingress >> filtering is bold. Ingress filtering is today typically deployed >> further >> upstream to avoid having to configure it in every single access >> router. > > right, but it really depends on the scope we have in mind for savi. > If the scope is a site i.e. a solution that applies to a local site, > then the assumption could be valid. Yes, I agree with this. In particular if SAVI was to be implemented on routers, then it should be straightforward to build a network where all access routers use SAVI + ingress filtering. > Of course, what we are after is an internet wide solution, then > certainly it doesn,'t but i am not sure if we will be able to do > that in any case Right. We are in no position to guarantee an Internet-wide solution since it would require universal deployment of SAVI. Even if SAVI was going to be super-easy to deploy, very likely there would continue to be networks that wouldn't deploy it -- due to costs, due to inertia, due to malicious intents, you name it. >> But perhaps access router could auto-configure ingress filtering by >> listening to Router Advertisement messages, just like SAVI devices >> might >> distinguish off-link and on-link addresses by listening to Router >> Advertisement messages... > > but that's not enough, right? we need full routing table to do it > right and to cope with the cases i described above. My mistake; just listening to Router Advertisement messages is not enough. Routers on transit (non-stub) links need to look beyond their local link to discover all legitimate prefixes. - Christian From christian.vogt@nomadiclab.com Thu Oct 16 06:22:22 2008 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 D2F2F3A6B97 for ; Thu, 16 Oct 2008 06:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 1cSxmboTaQB6 for ; Thu, 16 Oct 2008 06:22:22 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id B1E283A698E for ; Thu, 16 Oct 2008 06:22:21 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 8C4821EF158; Thu, 16 Oct 2008 16:23:21 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id D69951EF157; Thu, 16 Oct 2008 16:23:19 +0300 (EEST) Message-Id: From: Christian Vogt To: Jari Arkko In-Reply-To: <48F721BC.9060401@piuha.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 16 Oct 2008 16:23:01 +0300 References: <48F30CB6.9090508@it.uc3m.es> <48F721BC.9060401@piuha.net> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV using ClamSMTP Cc: SAVI Mailing List Subject: Re: [savi] Scope of savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2008 13:22:22 -0000 On Oct 16, 2008, Jari Arkko wrote: >> you are raising a very good question. But I think you are too >> fast. :-) >> What we should in my opinion consider first is the higher-level >> question >> of where we want SAVI solutions to be deployed. > > Let me quote the charter: "The working group considers only solutions > implemented on systems located on the same IP link as a to-be-verified > node. The goal of the working group is the LAN environment and > solutions > running in routers or layer 3 aware Ethernet bridges." Jari, my question wasn't about /where/ to deploy SAVI in a given network, but in which networks SAVI should be deployable -- deployable without having to deploy additional protocols at the same time. To exemplify: If a SAVI solution required SeND, then obviously it wouldn't be deployable in networks that run only plain ND. So requiring SeND would limit deployability. On the other hand, the toolbox that SeND provides to design a SAVI solution is more powerful than the toolbox that plain ND provides. So to decide which situations a SAVI solution should be able to handle -- i.e., to answer questions (a) through (j) in my earlier email --, we need to have some consensus about the protocols that SAVI should rely upon. That consensus may be of the form: "Let's try to do with plain ND first, and if we see that this is insufficient, we will reconsider." Hence the suggestion to first get to some consensus regarding the protocols SAVI should rely upon -- i.e., our design toolbox --, and then talk about how to achieve the most using this toolbox. So we start top-down to confine our solution space, and then try to find the optimal solution within that space, possibly in bottom-up fashion. Having said this, I think that the discussion so far has shown several convincing arguments (many by Marcelo) in favor of trying to do with ARP/ND/DHCP in the basic case, and perhaps take advantage of SeND where available. - Christian From marcelo@it.uc3m.es Thu Oct 16 09:21:40 2008 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 ABD983A6A38 for ; Thu, 16 Oct 2008 09:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.762 X-Spam-Level: X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 2+NVNHTTxhju for ; Thu, 16 Oct 2008 09:21:39 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 83B083A6A9A for ; Thu, 16 Oct 2008 09:21:39 -0700 (PDT) Received: from dummyhost38.it.uc3m.es (cdkmba.it.uc3m.es [163.117.139.68])by smtp02.uc3m.es (Postfix) with ESMTP id D3BC85C3E80;Thu, 16 Oct 2008 18:22:29 +0200 (CEST) Message-ID: <48F76A45.8010405@it.uc3m.es> Date: Thu, 16 Oct 2008 18:22:29 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Christian Vogt References: <4EC04196-A0A9-4CFD-A87F-84466963AECF@nomadiclab.com> <48F1C0DC.6070409@it.uc3m.es> <22867E3F-3EE7-4DF7-AE99-827586F51C9C@nomadiclab.com> <48F4E459.7000700@it.uc3m.es> <5C2EF721-0B1A-4244-97B3-6310EC389DBF@nomadiclab.com> <48F59596.7070203@it.uc3m.es> <48F6EC60.4020908@it.uc3m.es> <149A9BFC-8265-4753-A6B8-007E8B3E9C64@nomadiclab.com> In-Reply-To: <149A9BFC-8265-4753-A6B8-007E8B3E9C64@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-12.5485 TC:1F TRN:51 TV:5.5.1026(16222.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: SAVI Mailing List Subject: Re: [savi] Defining the Solution Space for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2008 16:21:40 -0000 Christian Vogt escribió: > Marcelo - > >>> As a matter of fact, the 2nd of your assumptions ("routers >>> know which prefixes are on-link"), is already sufficient for routers to >>> do ingress filtering. >> >> I think we agree but just to clarify >> routers need to validate two types of packets afaict. >> They need to validate the source address of the packets generated by >> hosts connected to the local link. [...] But routers also need to >> deal with packets forwarded by other routers that are in transit in >> that link. > > That's right. And the second of these is what we could potentially > solve by relying on ingress filtering. > > >> Let me see if we agree: >> We are considering two options >> - the router knows the local prefixes and which are the routers >> directly connected (in this case the trsut models is that the routers >> are trustworthy) >> - the router knows the local prefixes and performs ingress filtering. >> (in this case, the trsut assumptions depend on what type of routing >> do we have. If we have default routes, you are basically trusting the >> router for pretty much everything, sinilar to the previous case) > > Yes, these are two options we have for dealing with routers. > > Referring to your statement "trusting the router for pretty much > everything": Do you feel that this option would offload too much > security to ingress filtering? no, i think that's fine actually as i said before, you have two options, either simply trust the routers blindly or do ingress filtering as well, which provides more security, since you at least verify that the routing information is coherent with the source address you are looking in the packets. regards, marcelo > > >>> Of course, the assumption that all access routers perform ingress >>> filtering is bold. Ingress filtering is today typically deployed >>> further >>> upstream to avoid having to configure it in every single access router. >> >> right, but it really depends on the scope we have in mind for savi. >> If the scope is a site i.e. a solution that applies to a local site, >> then the assumption could be valid. > > Yes, I agree with this. In particular if SAVI was to be implemented > on routers, then it should be straightforward to build a network where > all access routers use SAVI + ingress filtering. > > >> Of course, what we are after is an internet wide solution, then >> certainly it doesn,'t but i am not sure if we will be able to do that >> in any case > > Right. We are in no position to guarantee an Internet-wide solution > since it would require universal deployment of SAVI. Even if SAVI was > going to be super-easy to deploy, very likely there would continue to > be networks that wouldn't deploy it -- due to costs, due to inertia, > due to malicious intents, you name it. > > >>> But perhaps access router could auto-configure ingress filtering by >>> listening to Router Advertisement messages, just like SAVI devices >>> might >>> distinguish off-link and on-link addresses by listening to Router >>> Advertisement messages... >> >> but that's not enough, right? we need full routing table to do it >> right and to cope with the cases i described above. > > My mistake; just listening to Router Advertisement messages is not > enough. Routers on transit (non-stub) links need to look beyond their > local link to discover all legitimate prefixes. > > - Christian > > > From marcelo@it.uc3m.es Thu Oct 16 09:24:37 2008 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 6CA623A6B08 for ; Thu, 16 Oct 2008 09:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.762 X-Spam-Level: X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 MK9AwtQGepf6 for ; Thu, 16 Oct 2008 09:24:36 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 903863A6A9A for ; Thu, 16 Oct 2008 09:24:36 -0700 (PDT) Received: from dummyhost38.it.uc3m.es (cdkmba.it.uc3m.es [163.117.139.68])by smtp02.uc3m.es (Postfix) with ESMTP id 9FB215C3E81;Thu, 16 Oct 2008 18:25:29 +0200 (CEST) Message-ID: <48F76AF9.70905@it.uc3m.es> Date: Thu, 16 Oct 2008 18:25:29 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Christian Vogt References: <48F30CB6.9090508@it.uc3m.es> <48F721BC.9060401@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-8.3492 TC:1F TRN:18 TV:5.5.1026(16222.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: SAVI Mailing List Subject: Re: [savi] Scope of savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2008 16:24:37 -0000 Christian Vogt escribió: > > Having said this, I think that the discussion so far has shown several > convincing arguments (many by Marcelo) in favor of trying to do with > ARP/ND/DHCP in the basic case, and perhaps take advantage of SeND where > available. > that sounds reasonable to me I think that the other input received from Jari is also to rely on ingress filtering i.e. not try to replace ingress filtering, but try to defien a solution that complements it, which also makes sense to me I think that if we agree on these issues, we are ready to go :-) Regards, marcelo > - Christian > > > From fred@cisco.com Thu Oct 16 09:41:56 2008 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 DC8E63A6809 for ; Thu, 16 Oct 2008 09:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrhtbmhhRTfX for ; Thu, 16 Oct 2008 09:41:56 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 429143A6805 for ; Thu, 16 Oct 2008 09:41:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,424,1220227200"; d="scan'208";a="176587144" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 16 Oct 2008 16:42:58 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9GGgwa0003784; Thu, 16 Oct 2008 09:42:58 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9GGgw3W006260; Thu, 16 Oct 2008 16:42:58 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Oct 2008 09:42:58 -0700 Received: from stealth-10-32-244-220.cisco.com ([10.32.244.220]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Oct 2008 09:42:58 -0700 Message-Id: From: Fred Baker To: Jari Arkko In-Reply-To: <48F7200D.3060903@piuha.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 16 Oct 2008 09:42:57 -0700 References: <48F30CB6.9090508@it.uc3m.es> <48F7200D.3060903@piuha.net> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 16 Oct 2008 16:42:58.0098 (UTC) FILETIME=[3EC98920:01C92FAE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=143; t=1224175378; x=1225039378; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[savi]=20Scope=20of=20savi |Sender:=20; bh=rO+f0BV3vggsbtOhhfXIKugcu/hkBbB9wPRTm6qf4M0=; b=VHNIKR6iLEObCqw7Bpil8DldZTPYr55t1JSfoYhe/ft9+k306rNU7+/4J8 RTOmVeYY6ybBb0/nsMBAxlip6FacKm4ANGt3SPHfmOLxyaznXMmXUWzQzm4N JTNioucaWVrcYOHWiJKtGw9Gs/wauQpzSDHSh2Q+i97b5dK0mIj50=; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: SAVI Mailing List Subject: Re: [savi] Scope of savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2008 16:41:56 -0000 On Oct 16, 2008, at 4:05 AM, Jari Arkko wrote: > I believe SAVI should complement ingress filtering, not replace it. Very much agree. From zhangdong_rh@huaweisymantec.com Thu Oct 16 23:54:24 2008 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 50F713A6894 for ; Thu, 16 Oct 2008 23:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.218 X-Spam-Level: * X-Spam-Status: No, score=1.218 tagged_above=-999 required=5 tests=[AWL=3.817, 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 c-FYkQWi94zz for ; Thu, 16 Oct 2008 23:54:23 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id 7CC133A680C for ; Thu, 16 Oct 2008 23:54:23 -0700 (PDT) MIME-version: 1.0 Content-disposition: inline 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-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0K8V00IL1F8BD830@hstga02-in.huaweisymantec.com> for savi@ietf.org; Fri, 17 Oct 2008 14:55:24 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0K8V00MZAF8AQT00@hstml02-in.huaweisymantec.com> for savi@ietf.org; Fri, 17 Oct 2008 14:55:23 +0800 (CST) Received: from [10.27.141.13] by hstml02-in.huaweisymantec.com (mshttpd); Fri, 17 Oct 2008 14:55:22 +0800 From: ZhangDong To: Christian Vogt Message-id: Date: Fri, 17 Oct 2008 14:55:22 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <48F76AF9.70905@it.uc3m.es> References: <48F30CB6.9090508@it.uc3m.es> <48F721BC.9060401@piuha.net> <48F76AF9.70905@it.uc3m.es> Content-transfer-encoding: quoted-printable Cc: SAVI Mailing List Subject: [savi] Reply: Re: Scope of savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2008 06:54:24 -0000 Marcelo escribi=A8=AE=3A =3E Christian Vogt escribi=A8=AE=3A =3E =3E =3E =3E Having said this=2C I think that the discussion so far has show= n several =3E =3E convincing arguments (many by Marcelo) in favor of trying to do= with =3E =3E ARP/ND/DHCP in the basic case=2C and perhaps take advantage of = SeND where =3E =3E available=2E =3E =3E =3E that sounds reasonable to me =3E I think that the other input received from Jari is also to rely on = =3E ingress filtering i=2Ee=2E not try to replace ingress filtering=2C = but try = =3E to = =3E defien a solution that complements it=2C which also makes sense to = me =3E = =3E I think that if we agree on these issues=2C we are ready to go =3A-= ) It seems there is a temporary conclusion after several days discussion=2E= So can i say we have the direction of the SAVI solution=3F = Dong Zhang From zhangdong_rh@huaweisymantec.com Mon Oct 20 23:58:36 2008 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 301613A6879 for ; Mon, 20 Oct 2008 23:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[AWL=1.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 8n1k+B0XnzCL for ; Mon, 20 Oct 2008 23:58:35 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [121.15.168.142]) by core3.amsl.com (Postfix) with ESMTP id 2F8EF3A63EC for ; Mon, 20 Oct 2008 23:58:34 -0700 (PDT) MIME-version: 1.0 Content-disposition: inline Content-type: text/plain; charset=gb2312 Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0K92008TLU3I5W40@hstga01-in.huaweisymantec.com> for savi@ietf.org; Tue, 21 Oct 2008 14:59:44 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0K9200D0HU3HOT10@hstml02-in.huaweisymantec.com> for savi@ietf.org; Tue, 21 Oct 2008 14:59:42 +0800 (CST) Received: from [10.27.141.13] by hstml02-in.huaweisymantec.com (mshttpd); Tue, 21 Oct 2008 14:59:41 +0800 From: ZhangDong To: marcelo bagnulo braun , Christian Vogt Message-id: Date: Tue, 21 Oct 2008 14:59:41 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <48F4E4D3.1040209@it.uc3m.es> References: <4EC04196-A0A9-4CFD-A87F-84466963AECF@nomadiclab.com> <48F1C0DC.6070409@it.uc3m.es> <5CE879A0D1904950B87A5507C7C86E5E@userPC> <887E9B88-3DB9-4E79-9A4C-9CC5A7150333@nomadiclab.com> <48F4E4D3.1040209@it.uc3m.es> Content-transfer-encoding: quoted-printable Cc: SAVI Mailing List Subject: Re: [savi] Defining the Solution Space for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2008 06:58:36 -0000 Dear Christian and Marcelo=2C Because I did not attend the IETF 72=2E So here I still have confused qu= estions=2E =3E Christian Vogt escribi=A8=AE=3A =3E =3E Jun Bi wrote=3A =3E =3E =3E =3E=3E I thought during the IETF72 SAVI WG discussion=2C as Jari an= d others =3E =3E=3E pointed=2C if the solution is revised as an extension of an = existing =3E =3E=3E protocol (e=2Eg=2E=2C SeND or others)=2C then it somehow won= =27t be a new protocol =3E =3E=3E or host change=2E What kind solution is called host change=3F If the solution uses the option field or reserved field=2C does it chang= e the host or revise the protocol existed=3F = And can extension part be added in protocol existed=3F =3E =3E =3E =3E Jun and all=2C =3E =3E =3E =3E what was considered at IETF 72 was not to extend SeND (or anoth= er =3E =3E protocol)=2E It was the possibility to request from IESG the = =3E addition of =3E =3E a charter deliverable for a SeND-based SAVI solution extension=2E= The =3E =3E idea was that the working group could work on both=2C a basic =3E =3E non-cryptographic SAVI solution=2C plus a more secure extension= that = =3E would =3E =3E be based on (unchanged) SeND=2E This would allow easy deployme= nt of = =3E the =3E =3E basic SAVI solution without special prerequisites=2E And in th= ose =3E =3E environments where SeND is deployed=2C stronger security could = optionally =3E =3E be obtained by using the SAVI solution extension=2E =3E =3E =3E = =3E that makes sense to me =3E moreover=2C i think that if we define a solution based on ND=2C it = would = =3E = =3E make sense as well to figure out how it works with send (both = =3E unchanged = =3E i mean of course)=2E I would even argue that this would fit in the = =3E current = =3E charter=2C since send is just the secure version of nd =3E = =3E regards=2C marcelo =3E = =3E =3E - Christian =3E =3E =3E =3E =3E =3E Dong Zhang From christian.vogt@nomadiclab.com Tue Oct 21 05:49:09 2008 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 98B6328C136 for ; Tue, 21 Oct 2008 05:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 RXqINHZDdyEZ for ; Tue, 21 Oct 2008 05:49:05 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id BC18328C134 for ; Tue, 21 Oct 2008 05:49:05 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0D92E1EF332; Tue, 21 Oct 2008 15:50:18 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id C80E11EF32A; Tue, 21 Oct 2008 15:50:08 +0300 (EEST) Message-Id: <7DD24051-7992-4D68-98A1-EB95B2CD6CE9@nomadiclab.com> From: Christian Vogt To: ZhangDong In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 21 Oct 2008 15:33:02 +0300 References: <4EC04196-A0A9-4CFD-A87F-84466963AECF@nomadiclab.com> <48F1C0DC.6070409@it.uc3m.es> <5CE879A0D1904950B87A5507C7C86E5E@userPC> <887E9B88-3DB9-4E79-9A4C-9CC5A7150333@nomadiclab.com> <48F4E4D3.1040209@it.uc3m.es> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV using ClamSMTP Cc: SAVI Mailing List Subject: Re: [savi] Defining the Solution Space for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2008 12:49:09 -0000 ZhangDong wrote: > What kind solution is called host change? You need to change hosts if hosts need to act differently than specified in existing RFCs. - Christian From marcelo@it.uc3m.es Tue Oct 21 07:11:33 2008 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 5B0F23A6B5B for ; Tue, 21 Oct 2008 07:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.88 X-Spam-Level: X-Spam-Status: No, score=-3.88 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 hgM4TL5ApXvp for ; Tue, 21 Oct 2008 07:11:29 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 7BBF53A6B5A for ; Tue, 21 Oct 2008 07:11:29 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [85.53.133.67])by smtp01.uc3m.es (Postfix) with ESMTP id 8EF7EAC3910;Tue, 21 Oct 2008 16:12:05 +0200 (CEST) Message-ID: <48FDE335.2050304@it.uc3m.es> Date: Tue, 21 Oct 2008 16:12:05 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: ZhangDong References: <4EC04196-A0A9-4CFD-A87F-84466963AECF@nomadiclab.com><48F1C0DC.6 070409@it.uc3m.es> <5CE879A0D1904950B87A5507C7C86E5E@userPC><887E9B88-3DB9-4E79-9A4C-9CC5A715 0333@nomadiclab.com><48F4E4D3.1040209@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-22.0711 TC:1F TRN:34 TV:5.5.1026(16230.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Christian Vogt , SAVI Mailing List Subject: Re: [savi] Defining the Solution Space for SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2008 14:11:33 -0000 ZhangDong escribi¨®: > Dear Christian and Marcelo, > > Because I did not attend the IETF 72. So here I still have confused questions. > > >> Christian Vogt escribi¨®: >> > Jun Bi wrote: >> > >> >> I thought during the IETF72 SAVI WG discussion, as Jari and others >> >> pointed, if the solution is revised as an extension of an existing >> >> protocol (e.g., SeND or others), then it somehow won't be a new protocol >> >> or host change. >> > > What kind solution is called host change? > If the solution uses the option field or reserved field, does it change the host or revise the protocol existed? > And can extension part be added in protocol existed? > imho, the definition is very simple. If you need to change the stack software in the host, this is a strong hint that you are doing a change in the protocol If it is a configuration, i think it wouldn't be the best option, but maybe we can live with that regards, marcelo > >> > >> > Jun and all, >> > >> > what was considered at IETF 72 was not to extend SeND (or another >> > protocol). It was the possibility to request from IESG the >> addition of >> > a charter deliverable for a SeND-based SAVI solution extension. The >> > idea was that the working group could work on both, a basic >> > non-cryptographic SAVI solution, plus a more secure extension that >> would >> > be based on (unchanged) SeND. This would allow easy deployment of >> the >> > basic SAVI solution without special prerequisites. And in those >> > environments where SeND is deployed, stronger security could optionally >> > be obtained by using the SAVI solution extension. >> > >> >> that makes sense to me >> moreover, i think that if we define a solution based on ND, it would >> >> make sense as well to figure out how it works with send (both >> unchanged >> i mean of course). I would even argue that this would fit in the >> current >> charter, since send is just the secure version of nd >> >> regards, marcelo >> >> > - Christian >> > >> > >> > >> > > > > > Dong Zhang > > > > > From zhangdong_rh@huaweisymantec.com Tue Oct 21 18:43:32 2008 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 A92403A695C for ; Tue, 21 Oct 2008 18:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.621 X-Spam-Level: ** X-Spam-Status: No, score=2.621 tagged_above=-999 required=5 tests=[AWL=-2.675, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_62=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] 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 R4Ib8rmnQsxr for ; Tue, 21 Oct 2008 18:43:32 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [121.15.168.142]) by core3.amsl.com (Postfix) with ESMTP id CB3E83A68BC for ; Tue, 21 Oct 2008 18:43:31 -0700 (PDT) MIME-version: 1.0 Content-disposition: inline Content-type: text/plain; charset=gb2312 Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0K9400JRBA6KKN20@hstga01-in.huaweisymantec.com> for savi@ietf.org; Wed, 22 Oct 2008 09:44:46 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0K9400KK3A6JHH00@hstml02-in.huaweisymantec.com> for savi@ietf.org; Wed, 22 Oct 2008 09:44:44 +0800 (CST) Received: from [10.27.141.13] by hstml02-in.huaweisymantec.com (mshttpd); Wed, 22 Oct 2008 09:44:43 +0800 From: ZhangDong To: Christian Vogt Message-id: Date: Wed, 22 Oct 2008 09:44:43 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <7DD24051-7992-4D68-98A1-EB95B2CD6CE9@nomadiclab.com> References: <4EC04196-A0A9-4CFD-A87F-84466963AECF@nomadiclab.com> <48F1C0DC.6070409@it.uc3m.es> <5CE879A0D1904950B87A5507C7C86E5E@userPC> <887E9B88-3DB9-4E79-9A4C-9CC5A7150333@nomadiclab.com> <48F4E4D3.1040209@it.uc3m.es> <7DD24051-7992-4D68-98A1-EB95B2CD6CE9@nomadiclab.com> Content-transfer-encoding: quoted-printable Cc: SAVI Mailing List Subject: [savi] =?gb2312?b?u9i4tDogUmU6ICBEZWZpbmluZyB0aGUgU29sdXRpb24g?= =?gb2312?b?U3BhY2UgZm9yIFNBVkk=?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2008 01:43:32 -0000 =3E ZhangDong wrote=3A =3E = =3E =3E What kind solution is called host change=3F =3E = =3E You need to change hosts if hosts need to act differently =3E than specified in existing RFCs=2E =3E = =3E - Christian =3E = I know that the SAVI solution must not change the behavior of the host s= pecified in existing RFCs=2E =3E Christian Vogt escribi=A8=AE=3A =3E =3E Jun Bi wrote=3A =3E =3E =3E =3E=3E I thought during the IETF72 SAVI WG discussion=2C as Jari an= d others =3E =3E=3E pointed=2C if the solution is revised as an extension of an = existing =3E =3E=3E protocol (e=2Eg=2E=2C SeND or others)=2C then it somehow won= =27t be a new protocol =3E =3E=3E or host change=2E However=2C when makeing an extension of an existing protocol may let the= host do some additional operation=2E According to the discussion earlie= r=2C it is allowed by SAVI=2E Am I ringht=3FOr misunderstanding=3F Dong Zhang Dong Zhang From christian.vogt@nomadiclab.com Fri Oct 24 02:54:11 2008 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 262903A6A41 for ; Fri, 24 Oct 2008 02:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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 r2yor+lS8kpR for ; Fri, 24 Oct 2008 02:54:10 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 518133A6A33 for ; Fri, 24 Oct 2008 02:54:10 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 9C2031EF4C9; Fri, 24 Oct 2008 12:55:30 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 638FE1EF110; Fri, 24 Oct 2008 12:55:30 +0300 (EEST) Message-Id: From: Christian Vogt To: ZhangDong In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 24 Oct 2008 12:55:29 +0300 References: <4EC04196-A0A9-4CFD-A87F-84466963AECF@nomadiclab.com> <48F1C0DC.6070409@it.uc3m.es> <5CE879A0D1904950B87A5507C7C86E5E@userPC> <887E9B88-3DB9-4E79-9A4C-9CC5A7150333@nomadiclab.com> <48F4E4D3.1040209@it.uc3m.es> <7DD24051-7992-4D68-98A1-EB95B2CD6CE9@nomadiclab.com> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV using ClamSMTP Cc: SAVI Mailing List Subject: Re: [savi] =?utf-8?b?5Zue5aSNOiBSZTogIERlZmluaW5nIHRoZSBTb2x1dGlvbiBT?= =?utf-8?q?pace_for_SAVI?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2008 09:54:11 -0000 Hi Dong Zhang - > However, when makeing an extension of an existing protocol may let > the host do some additional operation. According to the discussion > earlier, it is allowed by SAVI. No, such host changes are actually not allowed by SAVI. Note that what we where discussing earlier was an extension to the operation of SAVI devices such that they can make use non-modified SeND support on hosts. - Christian From marcelo@it.uc3m.es Sun Oct 26 09:18:58 2008 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 37EB43A6A03 for ; Sun, 26 Oct 2008 09:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.293 X-Spam-Level: X-Spam-Status: No, score=-5.293 tagged_above=-999 required=5 tests=[AWL=1.306, 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 8qAmG432f9Ry for ; Sun, 26 Oct 2008 09:18:57 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 42F623A691A for ; Sun, 26 Oct 2008 09:18:56 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [85.53.150.214])by smtp01.uc3m.es (Postfix) with ESMTP id 4EB7EAC8C47for ; Sun, 26 Oct 2008 17:20:22 +0100 (CET) Message-ID: <490498C5.3080706@it.uc3m.es> Date: Sun, 26 Oct 2008 17:20:21 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: SAVI Mailing List Content-Type: multipart/mixed; boundary=------------080002090809000406090205 X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-18.0091 TC:1F TRN:37 TV:5.5.1026(16242.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [savi] [Fwd: I-D Action:draft-bagnulo-savi-send-00.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: Sun, 26 Oct 2008 16:18:58 -0000 This is a multi-part message in MIME format. --------------080002090809000406090205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I have submitted a draft describing how to build a SAVI solution using the SeND protocol without any change to the hosts nor to the SeND protocol. I think the resulting security level is pretty good. Comments would be appreciated. Regards, marcelo -------- Mensaje original -------- Asunto: I-D Action:draft-bagnulo-savi-send-00.txt Fecha: Sun, 26 Oct 2008 09:15:01 -0700 (PDT) De: Internet-Drafts@ietf.org Responder a: internet-drafts@ietf.org Para: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SeND-based Source-Address Validation Implementation Author(s) : M. Bagnulo Filename : draft-bagnulo-savi-send-00.txt Pages : 10 Date : 2008-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-bagnulo-savi-send-00.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. --------------080002090809000406090205 Content-Type: Message/External-body; name="draft-bagnulo-savi-send-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-bagnulo-savi-send-00.txt" Content-Type: text/plain Content-ID: <2008-10-26090517.I-D@ietf.org> --------------080002090809000406090205 Content-Type: text/plain; name="Parte del mensaje adjunto" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Parte del mensaje adjunto" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------080002090809000406090205-- From yaoa02@mails.tsinghua.edu.cn Mon Oct 27 00:28:25 2008 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 14BA53A6A46 for ; Mon, 27 Oct 2008 00:28:25 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat X-Spam-Flag: NO X-Spam-Score: 2.79 X-Spam-Level: ** X-Spam-Status: No, score=2.79 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] X-Amavis-Modified: Mail body modified (defanged) by core3.amsl.com 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 Wz2ZLFlP2KjM for ; Mon, 27 Oct 2008 00:28:24 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1225092505-28806-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id 82ABF3A6927 for ; Mon, 27 Oct 2008 00:28:23 -0700 (PDT) Received: from [166.111.132.215] (helo=netarchld5f663) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.63) (envelope-from ) id 1KuMWM-000611-FX for savi@ietf.org; Mon, 27 Oct 2008 15:28:14 +0800 From: "Guang Yao" To: Date: Mon, 27 Oct 2008 15:28:11 +0800 Message-ID: <014b01c93805$9130b490$b3921db0$@tsinghua.edu.cn> X-Mailer: Microsoft Office Outlook 12.0 Subject: Re: [savi] [Fwd: I-D Action:draft-bagnulo-savi-send-00.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, 27 Oct 2008 07:28:25 -0000 This is a multi-part message in MIME format... ------------=_1225092505-28806-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1225092505-28806-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 8bit Content-Description: Original message Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id 82ABF3A6927 for ; Mon, 27 Oct 2008 00:28:23 -0700 (PDT) Received: from [166.111.132.215] (helo=netarchld5f663) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.63) (envelope-from ) id 1KuMWM-000611-FX for savi@ietf.org; Mon, 27 Oct 2008 15:28:14 +0800 From: "Guang Yao" To: Subject: RE: [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt] Date: Mon, 27 Oct 2008 15:28:11 +0800 Message-ID: <014b01c93805$9130b490$b3921db0$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_014C_01C93848.9F53F490" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ack3xQbc3go0vsJTQnGi6QDl/1gqcgAD/wCAAAwf0FA= Content-Language: zh-cn X-MS-TNEF-Correlator: 00000000B36CB62FD428BE40ADAA519BB8A7F806445A2200 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à²¿·ÖÓʼþ¡£ ------=_NextPart_000_014C_01C93848.9F53F490 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Dear Marcelo, It's a good effort. This mechanism greatly conforms to the charter.=20 But I still have some questions on your method: 1 Once there is an entry in the SAVI DB, and the LIFETIME has not = expired, there is only a check on the binding of layer2 and IP address.=20 But the layer2 information is not secure. In this period, an attacker = can spoof its layer2 address and the IP address to pass the verification. So I think there may need some enforcement to improve the security = during this period. And how does this mechanism handle two interfaces of a host using same addresses to do flow balancing? 2 It may happen that during a LIFETIME, the host with an address changed = its address, which meaning it abandons the ownership of this address. But the address still cannot be used by other hosts, though this behavior = cannot be regarded as spoofing. It may trouble if the LIFETIME is long. But too short LIFETIME means frequent NUD processes. So it is better to choose a = proper LIFETIME. 3 Maybe the cost to decide whether a packet is spoofing in "If an entry = is found and the layer-2 information of the received data packet does not match the information contained in the existing matching entry" is too heavy? It seems rather easy to launch DoS attack at this procedure, just by spoofing a lot of layer 2 addresses. 4 As I know, when SeND is used, the CGA address must be used. Maybe this mechanism must be modified to adapt DHCP and manual configuration. Guang Yao -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] = =B4=FA=B1=ED savi-request@ietf.org =B7=A2=CB=CD=CA=B1=BC=E4: 2008=C4=EA10=D4=C227=C8=D5 3:00 =CA=D5=BC=FE=C8=CB: savi@ietf.org =D6=F7=CC=E2: savi Digest, Vol 5, Issue 13 Send savi mailing list submissions to savi@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/savi or, via email, send a message with subject or body 'help' to savi-request@ietf.org You can reach the person managing the list at savi-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of savi digest..." Today's Topics: 1. [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt] (marcelo bagnulo braun) ---------------------------------------------------------------------- Message: 1 Date: Sun, 26 Oct 2008 17:20:21 +0100 From: marcelo bagnulo braun Subject: [savi] [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt] To: SAVI Mailing List Message-ID: <490498C5.3080706@it.uc3m.es> Content-Type: text/plain; charset=3D"iso-8859-1"; Format=3D"flowed" Hi, I have submitted a draft describing how to build a SAVI solution using=20 the SeND protocol without any change to the hosts nor to the SeND=20 protocol. I think the resulting security level is pretty good. Comments would be appreciated. Regards, marcelo -------- Mensaje original -------- Asunto: I-D Action:draft-bagnulo-savi-send-00.txt Fecha: Sun, 26 Oct 2008 09:15:01 -0700 (PDT) De: Internet-Drafts@ietf.org Responder a: internet-drafts@ietf.org Para: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SeND-based Source-Address Validation Implementation Author(s) : M. Bagnulo Filename : draft-bagnulo-savi-send-00.txt Pages : 10 Date : 2008-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-bagnulo-savi-send-00.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. -------------- next part -------------- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Parte del mensaje adjunto Url: ------------------------------ _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi End of savi Digest, Vol 5, Issue 13 *********************************** ------=_NextPart_000_014C_01C93848.9F53F490 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IgsHAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAAqAMAAAAAAACrAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQgABQAEAAAAAAAAAAAAAQkABAACAAAAAAAAAAEDkAYAABMAADgA AAALAAIAAQAAAAMAJgAAAAAACwApAAAAAAALACsAAAAAAAMALgAAAAAAHgBNAAEAAAABAAAAAAAA AB4AcAABAAAANQAAAFJFOiBbRndkOiBJLUQgQWN0aW9uOmRyYWZ0LWJhZ251bG8tc2F2aS1zZW5k LTAwLnR4dF0AAAAAAgFxAAEAAAAgAAAAAck3xQbc3go0vsJTQnGi6QDl/1gqcgAD/wCAAAwf0FAL ABcMAAAAAAsAAQ4AAAAAAgEKDgEAAAAYAAAAAAAAALNsti/UKL5ArapRm7in+AbCgAAAAwAUDgEA AAAeACgOAQAAAEMAAAAwMDAwMDAwNQF5YW9hMDJAbWFpbHMudHNpbmdodWEuZWR1LmNuAXlhb2Ew MkBtYWlscy50c2luZ2h1YS5lZHUuY24AAB4AKQ4BAAAAQwAAADAwMDAwMDA1AXlhb2EwMkBtYWls cy50c2luZ2h1YS5lZHUuY24BeWFvYTAyQG1haWxzLnRzaW5naHVhLmVkdS5jbgAAAwDeP6gDAAAD APE/BAgAAAMACVkBAAAAAwAQgAMgBgAAAAAAwAAAAAAAAEYAAAAAAYEAAAAAAAAFABGAAyAGAAAA AADAAAAAAAAARgAAAAACgQAAAAAAAAAAAAADABKAAyAGAAAAAADAAAAAAAAARgAAAAATgQAAAQAA AAsAFIADIAYAAAAAAMAAAAAAAABGAAAAAByBAAAAAAAACwAdgAggBgAAAAAAwAAAAAAAAEYAAAAA A4UAAAAAAAADAB6ACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAEAAAMAKYADIAYAAAAAAMAAAAAA AABGAAAAACOBAAD///9/AwA2gAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAADAI+AAyAGAAAA AADAAAAAAAAARgAAAAAQgQAAAAAAAAMAkIADIAYAAAAAAMAAAAAAAABGAAAAABGBAAAAAAAACwCW gAMgBgAAAAAAwAAAAAAAAEYAAAAAJIEAAAAAAAALAJeAAyAGAAAAAADAAAAAAAAARgAAAAAsgQAA AAAAAAMAmIADIAYAAAAAAMAAAAAAAABGAAAAACmBAAAAAAAAAwCZgAMgBgAAAAAAwAAAAAAAAEYA AAAAKoEAAAAAAAAeAJ6AAyAGAAAAAADAAAAAAAAARgAAAAAngQAAAQAAAAEAAAAAAAAAAwClgAMg BgAAAAAAwAAAAAAAAEYAAAAAEoEAAAEAAAAeAKmAAyAGAAAAAADAAAAAAAAARgAAAAAhgQAAAQAA AAEAAAAAAAAACwCsgAMgBgAAAAAAwAAAAAAAAEYAAAAAA4EAAAAAAAALAK2AAyAGAAAAAADAAAAA AAAARgAAAAAmgQAAAAAAAAsAsYAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAACwC1gAggBgAA AAAAwAAAAAAAAEYAAAAADoUAAAAAAAADALiACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAMA uoAIIAYAAAAAAMAAAAAAAABGAAAAAEKFAAAAAAAIAgG+gAggBgAAAAAAwAAAAAAAAEYAAAAAIIUA AAEAAAAoAQAAAgEEAAAAAAAAAAS08Li0CElQTS5Ob3RlBNPKvP4EtPC4tAUAAAAAAAAAAAEAAAAA AAAAAgAAAGYAAAACAAAAAQAAAAjIq7K/tPC4tAhJUE0uTm90ZQTTyrz+BLTwuLQFAAAAAAAAAAAB AAAAAAAAAAIAAABnAAAAAwAAAAIAAAAGx+vXqreiCElQTS5Ob3RlBNPKvP4E16q3ogUAAAAAAAAA AAEAAAAAAAAAAgAAAGgAAAAEAAAAAwAAAAy08Li0tb3OxLz+vNAISVBNLlBvc3QEuau45gAFAAAA AAAAAAABAAAAAAAAAAIAAABsAAAACAAAAAQBAlR7DVkCVHsNWQRoUeiQVHsNWQJUew1ZA/eLbI/R UwJsj9FTBlR7DVkwUodl9k45WQALAM6ACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAsAHw4B AAAAAgH4DwEAAAAQAAAAs2y2L9QovkCtqlGbuKf4BgIB+g8BAAAAEAAAALNsti/UKL5ArapRm7in +AYDAP4PBQAAAAIBCRABAAAAqgsAAKYLAADDFgAATFpGdf3d9XUDAAoAcmNwZzEyNSIyA0N0ZXgF QmJp/mQEAAMwAQMB9wqAAqQD4wkCAGNoCsBzZXQw/iAHEwKAEHMAUARWCFUHsu8SRQ5RAwERRzIG AAbDEkVOMwRGEUkTX2Y0EN4xZDM0AzAnYwwwGhBloxoBAOAnZTUSRTUYzwQyOAXSUEdvdGjfDeAC gBJTCO8J9zseXw4wOxrzDGBjAFALCQFkMzajEdALpiBEZQrBTQrAOxpgHfAsCqIKhAqASXRCJwQg YSBnbwRwIOMBER4BLiBUHTAEIAeAMxFhAwBzbSUgHmBhdKhseSAFoG4loW0EIOR0byfwaGUnYBFx DrAmciXgJARCdQVASSBcc3QDEAMgEXB2KFBz+wNwKFBxClApwQIgBCACILwgeQhhJkEdIARwOiQE cDEgT24aYCgiHmAg5w9RA5EJ8HRyJ1ALgCgjiFNBVimgREIsLaEDJWAoMkxJRkVUSWxNRSoRBCBu HRAlcHj8cGkeYS8gLScCICdBJRD7EWAFkGsrUigyDyAvUAuA0mcrUGYgC2B5BJAVYMkvQklQJQBk ZB5gBBD/KOooMjPlC4AnoicgKxEtcqswkhGgYwhwZSXgSS5S/Q9RcAZxBHAvIiUAAkAA0MprE6Fj A5FzcCVAM8D8aXQEIDPmNNQvNzSYJ/J/CrA84ihBKkAGgQ3gNwMu3SQEUygQKaAdIW4yoC0k+wDA J1BuCeAlYCpzCfAlod8aYAeAAjAn8gdwcANgKkHvKDI30zqwJ1BkCHEzgTiJnSXgQS9RLBAH4GRv B5GnOIMmWCaBZGwtAXdBwfsCMASQZgDQB5EzsSUQLBCbKcAkBHUAkDOBc2Eqkc80xUUSKBBE8CBm HfAH4NZiB0AAcGMzcT8kChVg9yTAQAMRcHA40C5SJyBDJu8lEC/GMUNH0yAD8B0gOUN7O3UmcmdA cTqyNMUvIHf/HTFPIAeAJpEzgTqwJQBKgH8vUCsiKDJEwEBQEZAdMHD/M6I4gzTHKWEkBCgyO2Yp xLs6ETCSYihQSIBAcWInUJ8dEROhR+JRESwBdWdPIH84g1bwKiErEDnzVrUeYGf/CxFAcTBhOlMz cTgxTBQuAP8IYAJgLWFT0i+pD1Ed8FuC/zWzJUApsCwQACAkBC/HUaIbBCADUGUqwUGBTlVE/zjA A2BHUUmRJeA/AVIhWQP/AkAToSgBEWAlQBGgJQFCAa840S+3PpUkBDMjcXlW8f8oM06ySdIFkA8w KFBRQCvxPxOhY4E5smIjWyYuMiJJf0ehLcdgQQhgL1EvRjPjLe82jFPDWkIaYGkqQAsxJCL+ZCcg Z5dE8zCSNvFRcSgy/zaqJ3EBkAuAUEIuVA7ABADfKdAzgW7TM3It4yItcl6C8yhAKjB5P0vyEaBB UAQg7nInIFfCI0BzXBEoEAtg82owUXFEbwXwOYQkBE0B1ziEYUJDMWUvIGpIgFbRvydQaFclEB3w BUAztiA7R7dhoSQKGeBBBCApoGswkO53USJMsQZgTmEQD1FXItFORENHQTtXbXfjVwT/JeBlhiYr flYEYT4BQHEoAcc0wEyABUBESEM0oS9RzQOBdQdAJ2NpZwhwPkqNJARHguAzgVlhbyQF8Gh0bWwA IRiFDAGFxW0R0C2HYhoAZBZQGhBhVRoAYhqxZhpxZBiwJ980wIg2h2SFxQKxfYbIhV87hm6IMTeI 8Q5QiEdjOO0aAjpI0VlwLQbgdVEHkLZACJAAMC4FsDOQWwDA2wMQKAA6jx+QIl2NYojh/0cwiDEA UBrQQIGRAmBzKcD/j9eKD4sfjC+NPBojiSGIE7OTEYhSZTSO8AHQMI6iG4jhI0AxAUCIw2MyMoON oY6SZDUgMzqaYN+Uz5XfluMbcpd8OYkiGnE6OBqxOJ0QoCCbITZjn470lD+dL5Zfl21kNohx+5vC GrIyjvQjIINgKuEvINJWBvAgNS8gSQQQClD+IBnAoo+jmj60CfCTVEABnwMQM3KrwE7BqHBibQQB vysTKAAkBQGRoa0kGVReof9cYATyVvEFsWowr7hZcCUQVSgyVwWwbCVgV2bSV/xlYi8gWXAAkEgV raOkUIB0cHM6Ly93tEDaLo/mL5CCA4EvrBI2ov4vkPIkBAWwsqIlEEFQkJHfLyARoGpCJkEEEGFQ ME7kvaxhagWQeSEFwAbgZCdQ4icoQGxwJ60fk6+uu/5ZCGA6AycBbwU40SpwA6D/A4G4YENkNhGs Iicguo5TI7u7/yQiV3wyHmALUHkzcX8vIAtQdLFA0Q9ABUArk1P/uQWrwSpSYgUEYC1ROlBmscc+ EVUGA5EiUmWO8AhQv0bxAjBHc6cTD0Cngi7JUO4iJAqvJm2AeSThr4Aw8FZjtAAkCiDMYDEl4Fus RncsMCmQLWEQQblA9SsROjTgYQGAkTC4YILQrR3wLZDzt7ItmmAuDNDsdF3MB8xhKADAI6NKca/O UzMgdEBqMCnJnwqHY9/TX9Rv1X/WbCQKTbg0jvC7ITMKgEQnIMexxLBuLyA8MjYswLlBmlKooDc6 5wHQ2sAssCswmxABQCQTnkYDYY7w0J/RoiA83EVHj9Al0CEQM20uB5A+9z6luQSO8FuQ8pJAzM/N 37/O769T2XEuwiOAq7RMrCKOPKG73tXYNS1JRI7wDDw0oTDnIDhDNS5CM5pwMDcwNt4vCnHH5S1U eTjQjvAOsi/NC1M7KGMRoT0iBADiEIA4ODU5LTEi6sA+RjbT61BKMgmAyYtIaf8j/CoVrHJikbfi 4VNmka/j5zNyRLIoAWJ1AxC34i6z/ypwCkA3E0iEVQh8c0IBKADvHdFO4whgUjFuJ1FQAyf2/1gD MIFiw/O3JAT0RjgxP0j/WlGocJCwSKNCtkZwKkADIL9282KBJ1AlMmSbCFBtQWL/BCBGsOHwV1FJ EUyQbKEHMP/vsWSbx6BaglER3EXR/9Kt/wXQCfBI4LkgsEGDYAuAgvH/1vx7cGowkMEo8K2y4K/h vx/PRduFJmIE1dmfMDk6fDE1nHAssM9A5/CHQCj4UERU0eUjMATWRvJAUP0GMEQGAo/I/xY6US9Q Z2LfBNVG4wyCBfMNHlDcUA63/Q+wLVaSj4LBb8m+fbAYEfsMLS1zdpCRUlBGcWBgQLD5UtRuLcUz DD3I4WyhKAD3QuB6bbNzVDqwRnEa6NlxP3yBBkFXMj8ATUB3UC1B3Tt1VkqQZtA3BElB8EZwN0Fi NwOtSUEpcF7RKHO6KRsnTVSxBmStSUa3cP+3wEjyGycF/wcPs1UREKeB/xrrmxGtWNkyGukbgQmy 6/D+MGtApiCu2kVUgQDwZm5h//eDLrIvIUWJPRJCEWbSvpD/HII0ts/EFiAdd0iE87/MoP8agL4y Y7FjQYKRRaesoM/Ev0biDmGBc2YgHhZwwWc7k//GsJCwPeFDckWhUdCT4izK/4gg14NRUFiwZ2E0 kILBFlD/QuNwAWXkaZGn8Ww1LYxuYeN+0xPcVVJMagFiwUVS3xT/y5WzwrQeDz0vIy8kP+/uZxfd 3FBJEWzFgRYYV3G7gsBwAHmBAEiA7DBUglH/36DPxPBAPrJHMT8vQDfXev5C3fHxQHLSZfFtg1FE TvDvVlEiMRZyeOBNXXIzw/5Q/2DBt1K9sg5xMqUeG4GD9SD//OBr0VnAVlC50PthGTHvIeFl4kFT Q0n40O8g6xD/a/hDD0DhGXzSzwJRF5DqQP9twakgA4fXH1T/Vg8Du2lhvm1+oC4A78JqgerlLbCB 98Z0gWJZMnd0wLjgr/CscPdbUclRz8ROIlGO8BERJ8H/DnCDAB5RArMt8HfQBKHPxP5VseDm8T6P tOHLUL5ht1LVthMvdeNo/QMvCbKbEAEJQC81NWI4N2WvZNBjuc9B20Au3MB03tX3V99oT9dcX2pP a19sKs/Ef6tPbTgSjbPPtN+17Nd6Rd+30ch2p2+oddeDKnaPd58Fz8R9eSAAAAMADTT9P6UGAwAP NP0/pQYCARQ0AQAAABAAAABOSVRB+b+4AQCqADfZbgAAAgF/AAEAAAAxAAAAMDAwMDAwMDBCMzZD QjYyRkQ0MjhCRTQwQURBQTUxOUJCOEE3RjgwNjQ0NUEyMjAwAAAAAAMABhD3oRYtAwAHECcOAAAD ABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAAREVBUk1BUkNFTE8sSVRTQUdPT0RFRkZPUlRUSElT TUVDSEFOSVNNR1JFQVRMWUNPTkZPUk1TVE9USEVDSEFSVEVSQlVUSVNUSUxMSEFWRVNPTUVRVUVT VElPTlNPTllPVVJNRQAAAADKyw== ------=_NextPart_000_014C_01C93848.9F53F490-- ------------=_1225092505-28806-1-- From marcelo@it.uc3m.es Mon Oct 27 01:09:49 2008 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 5A2473A6992 for ; Mon, 27 Oct 2008 01:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.627 X-Spam-Level: * X-Spam-Status: No, score=1.627 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_BAD_ID=2.837, 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 SQ+8YmDR8E2V for ; Mon, 27 Oct 2008 01:09:48 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id D274E3A6957 for ; Mon, 27 Oct 2008 01:09:47 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [85.53.147.199])by smtp01.uc3m.es (Postfix) with ESMTP id BD915AC913C; Mon, 27 Oct 2008 09:09:44 +0100 (CET) Message-ID: <49057747.3020908@it.uc3m.es> Date: Mon, 27 Oct 2008 09:09:43 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Guang Yao References: <014b01c93805$9130b490$b3921db0$@tsinghua.edu.cn> In-Reply-To: <014b01c93805$9130b490$b3921db0$@tsinghua.edu.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-48.8982 TC:1F TRN:93 TV:5.5.1026(16242.005) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: savi@ietf.org Subject: Re: [savi] [Fwd: I-D Action:draft-bagnulo-savi-send-00.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, 27 Oct 2008 08:09:49 -0000 Hi, thanks for your comments, see replies below... Guang Yao escribi¨®: > > ------------------------------------------------------------------------ > > Asunto: > RE: [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt] > De: > "Guang Yao" > Fecha: > Mon, 27 Oct 2008 15:28:11 +0800 > Para: > > > Para: > > > > Dear Marcelo, > > It's a good effort. This mechanism greatly conforms to the charter. > But I still have some questions on your method: > 1 Once there is an entry in the SAVI DB, and the LIFETIME has not expired, > there is only a check on the binding of layer2 and IP address. > right SeND provides security of the ND messages not of actually data packets So the trust chain isIP address to MAC address using sned security and then we trust the mac address > But the layer2 information is not secure. well, depends right? If you are using a switched ethernet, i would say that it is pretty secure, right? I mean, if you have associated the IP address using send with the mac address AND the port, then the resultng security is quite strong imho. I mean an attacker needs to know the MAC address AND be physically connected to the port, whoc seems quite hard. OTOH, if you are using a plain hub (i am not sure where you are going to get those, i use them for teaching and they are extremely hard to find) then anyone in the link could spoof you mac address and reconfigure their lan card to use the same mac address than you and then use your ip address. If you are using other layer2, we need to consider it. I mean, i agree that this relies on the layer 2 security, indeed. > In this period, an attacker can > spoof its layer2 address and the IP address to pass the verification. > depends on how easy to trick the layer 2 is > So I think there may need some enforcement to improve the security during > this period. well, we do, depending on the layer 2. As i said, switched ethernet does provides this > And how does this mechanism handle two interfaces of a host > using same addresses to do flow balancing? > > there is no problem with that, this case is explicitly covered in the draft, please check it out there but the main idea is that since address ownership is provided by cgas, we can creat multiple bindings between the CGA and a layer 2 address in a secure manner, no problem here afaict > 2 It may happen that during a LIFETIME, the host with an address changed its > address, which meaning it abandons the ownership of this address. But > the address still cannot be used by other hosts, though this behavior cannot > be regarded as spoofing. are you talking about two hosts having the same IPv6/CGA address? I don't think this is very likely....the whole idea of cgas is that the probability of collision is extremely low > It may trouble if the LIFETIME is long. But too > short > LIFETIME means frequent NUD processes. So it is better to choose a proper > LIFETIME. > > well, i don't think lifetime in this case is that critical, as it only affects the nud frequency > 3 Maybe the cost to decide whether a packet is spoofing in "If an entry is > found and the layer-2 information of the received > data packet does not match the information contained in the existing > matching entry" is too heavy? It seems rather easy to launch DoS attack > at this procedure, just by spoofing a lot of layer 2 addresses. > No, cause the key to perfrom the search is the IP address NOT the MAC address. So using many mac address is not a problem, since they can be repeated in the SeND SAVI DB > 4 As I know, when SeND is used, the CGA address must be used. Maybe this > mechanism must be modified to adapt DHCP and manual configuration. > > sure, CSI wg is chartered to do exactly that Regards, marcelo > Guang Yao > -----ÓʼþÔ­¼þ----- > ·¢¼þÈË: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] ´ú±í > savi-request@ietf.org > ·¢ËÍʱ¼ä: 2008Äê10ÔÂ27ÈÕ 3:00 > ÊÕ¼þÈË: savi@ietf.org > Ö÷Ìâ: savi Digest, Vol 5, Issue 13 > > Send savi mailing list submissions to > savi@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/savi > or, via email, send a message with subject or body 'help' to > savi-request@ietf.org > > You can reach the person managing the list at > savi-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of savi digest..." > > > Today's Topics: > > 1. [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt] > (marcelo bagnulo braun) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 26 Oct 2008 17:20:21 +0100 > From: marcelo bagnulo braun > Subject: [savi] [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt] > To: SAVI Mailing List > Message-ID: <490498C5.3080706@it.uc3m.es> > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > Hi, > > I have submitted a draft describing how to build a SAVI solution using > the SeND protocol without any change to the hosts nor to the SeND > protocol. I think the resulting security level is pretty good. > > Comments would be appreciated. > > Regards, marcelo > > > > -------- Mensaje original -------- > Asunto: I-D Action:draft-bagnulo-savi-send-00.txt > Fecha: Sun, 26 Oct 2008 09:15:01 -0700 (PDT) > De: Internet-Drafts@ietf.org > Responder a: internet-drafts@ietf.org > Para: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : SeND-based Source-Address Validation > Implementation > Author(s) : M. Bagnulo > Filename : draft-bagnulo-savi-send-00.txt > Pages : 10 > Date : 2008-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-bagnulo-savi-send-00.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. > > > -------------- next part -------------- > > -------------- next part -------------- > An embedded and charset-unspecified text was scrubbed... > Name: Parte del mensaje adjunto > Url: > -0001.bat> > > ------------------------------ > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > > > End of savi Digest, Vol 5, Issue 13 > *********************************** > > ------------------------------------------------------------------------ > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From yaoa02@mails.tsinghua.edu.cn Mon Oct 27 02:41:24 2008 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 7FB8E3A693E for ; Mon, 27 Oct 2008 02:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.913 X-Spam-Level: *** X-Spam-Status: No, score=3.913 tagged_above=-999 required=5 tests=[AWL=-1.123, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] 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 2Vq-XQ-XQP22 for ; Mon, 27 Oct 2008 02:41:23 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id DBF4A3A6919 for ; Mon, 27 Oct 2008 02:41:22 -0700 (PDT) Received: from [166.111.132.215] (helo=netarchld5f663) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.63) (envelope-from ) id 1KuOb5-0001H5-PN; Mon, 27 Oct 2008 17:41:15 +0800 From: "Guang Yao" To: "'marcelo bagnulo braun'" References: <014b01c93805$9130b490$b3921db0$@tsinghua.edu.cn> <49057747.3020908@it.uc3m.es> In-Reply-To: <49057747.3020908@it.uc3m.es> Date: Mon, 27 Oct 2008 17:41:12 +0800 Message-ID: <015a01c93818$265476d0$72fd6470$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ack4C2EAPp4ZYV16SMCxde37gdiNUwAA2cZQ Content-Language: zh-cn Cc: savi@ietf.org Subject: [savi] =?gb2312?b?tPC4tDogIFtGd2Q6IEktRCBBY3Rpb246ZHJhZnQtYmFn?= =?gb2312?b?bnVsby1zYXZpLXNlbmQtMDAudHh0XQ==?= 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, 27 Oct 2008 09:41:24 -0000 Hi, Thanks for your replies. I made my comments below. Best Regards, Guang Yao -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2008=C4=EA10=D4=C227=C8=D5 16:10 =CA=D5=BC=FE=C8=CB: Guang Yao =B3=AD=CB=CD: savi@ietf.org =D6=F7=CC=E2: Re: [savi] [Fwd: I-D = Action:draft-bagnulo-savi-send-00.txt] Hi, thanks for your comments, see replies below... Guang Yao escribi=A8=AE: > > = ------------------------------------------------------------------------ > > Asunto: > RE: [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt] > De: > "Guang Yao" > Fecha: > Mon, 27 Oct 2008 15:28:11 +0800 > Para: > > > Para: > > > > Dear Marcelo, > > It's a good effort. This mechanism greatly conforms to the charter.=20 > But I still have some questions on your method: > 1 Once there is an entry in the SAVI DB, and the LIFETIME has not = expired, > there is only a check on the binding of layer2 and IP address.=20 > =20 right SeND provides security of the ND messages not of actually data = packets So the trust chain isIP address to MAC address using sned security and then we trust the mac address > But the layer2 information is not secure.=20 well, depends right? If you are using a switched ethernet, i would say that it is pretty secure, right? I mean, if you have associated the IP address using send with the mac address AND the port, then the resultng security is quite strong imho. I mean an attacker needs to know the MAC address AND be physically connected to the port, whoc seems quite hard. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If you choose a switched ethernet and the MAC address has been bound to = the switch port, IP Source Guard is enough. IP Source Guard checks binding of IP-MAC-Port, and the binding of MAC and port is used to ensure the = security of MAC. Your mechanism checks IP-MAC, and supposes the MAC is secure. I think = there is not much difference in a switched ethernet. Your mechanism can handle the mobility of layer 2 easily, which is an advantage over IP Source Guard. But actually I think IP Source Guard is able to handle mobility, too, by enforcing SeND or making some other modification. OTOH, if you are using a plain hub (i am not sure where you are going to get those, i use them for teaching and they are extremely hard to find) then anyone in the link could spoof you mac address and reconfigure their lan card to use the same mac address than you and then use your ip address. If you are using other layer2, we need to consider it. I mean, i agree that this relies on the layer 2 security, indeed. > In this period, an attacker can > spoof its layer2 address and the IP address to pass the verification. > =20 depends on how easy to trick the layer 2 is > So I think there may need some enforcement to improve the security = during > this period. well, we do, depending on the layer 2. As i said, switched ethernet does provides this > And how does this mechanism handle two interfaces of a host > using same addresses to do flow balancing? > > =20 there is no problem with that, this case is explicitly covered in the draft, please check it out there but the main idea is that since address ownership is provided by cgas, we can creat multiple bindings between the CGA and a layer 2 address in a secure manner, no problem here afaict > 2 It may happen that during a LIFETIME, the host with an address = changed its > address, which meaning it abandons the ownership of this address. But > the address still cannot be used by other hosts, though this behavior cannot > be regarded as spoofing. are you talking about two hosts having the same IPv6/CGA address? I don't think this is very likely....the whole idea of cgas is that the probability of collision is extremely low > It may trouble if the LIFETIME is long. But too > short > LIFETIME means frequent NUD processes. So it is better to choose a = proper > LIFETIME. > > =20 well, i don't think lifetime in this case is that critical, as it only affects the nud frequency ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I see.:)=20 > 3 Maybe the cost to decide whether a packet is spoofing in "If an = entry is > found and the layer-2 information of the received > data packet does not match the information contained in the existing > matching entry" is too heavy? It seems rather easy to launch DoS = attack > at this procedure, just by spoofing a lot of layer 2 addresses. > =20 No, cause the key to perfrom the search is the IP address NOT the MAC address. So using many mac address is not a problem, since they can be repeated in the SeND SAVI DB ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I cannot quite understand your explaination... I mean, if an attacker is sending a lot packets with spoofed mac but = proper IP, the check point has to keep a state of all the spoofing packets and perform a lot of NUD. The = cost of discarding a single packet is not much, but it is vulnerable under DoS attacks. Why not discard the packets directly and use other mechanisms to handle special issues? > 4 As I know, when SeND is used, the CGA address must be used. Maybe = this > mechanism must be modified to adapt DHCP and manual configuration. > > =20 sure, CSI wg is chartered to do exactly that ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Good, I will check their documents. Regards, marcelo > Guang Yao > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: savi-bounces@ietf.org = [mailto:savi-bounces@ietf.org] =B4=FA=B1=ED > savi-request@ietf.org > =B7=A2=CB=CD=CA=B1=BC=E4: 2008=C4=EA10=D4=C227=C8=D5 3:00 > =CA=D5=BC=FE=C8=CB: savi@ietf.org > =D6=F7=CC=E2: savi Digest, Vol 5, Issue 13 > > Send savi mailing list submissions to > savi@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/savi > or, via email, send a message with subject or body 'help' to > savi-request@ietf.org > > You can reach the person managing the list at > savi-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of savi digest..." > > > Today's Topics: > > 1. [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt] > (marcelo bagnulo braun) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 26 Oct 2008 17:20:21 +0100 > From: marcelo bagnulo braun > Subject: [savi] [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt] > To: SAVI Mailing List > Message-ID: <490498C5.3080706@it.uc3m.es> > Content-Type: text/plain; charset=3D"iso-8859-1"; Format=3D"flowed" > > Hi, > > I have submitted a draft describing how to build a SAVI solution using = > the SeND protocol without any change to the hosts nor to the SeND=20 > protocol. I think the resulting security level is pretty good. > > Comments would be appreciated. > > Regards, marcelo > > > > -------- Mensaje original -------- > Asunto: I-D Action:draft-bagnulo-savi-send-00.txt > Fecha: Sun, 26 Oct 2008 09:15:01 -0700 (PDT) > De: Internet-Drafts@ietf.org > Responder a: internet-drafts@ietf.org > Para: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : SeND-based Source-Address Validation > Implementation > Author(s) : M. Bagnulo > Filename : draft-bagnulo-savi-send-00.txt > Pages : 10 > Date : 2008-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-bagnulo-savi-send-00.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. > > > -------------- next part -------------- > > -------------- next part -------------- > An embedded and charset-unspecified text was scrubbed... > Name: Parte del mensaje adjunto > Url: > -0001.bat> > > ------------------------------ > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > > > End of savi Digest, Vol 5, Issue 13 > *********************************** > =20 > = ------------------------------------------------------------------------ > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > =20 From marcelo@it.uc3m.es Mon Oct 27 03:42:14 2008 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 45DC33A688A for ; Mon, 27 Oct 2008 03:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.58 X-Spam-Level: ** X-Spam-Status: No, score=2.58 tagged_above=-999 required=5 tests=[AWL=-0.953, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 pkYLO7NTLaxY for ; Mon, 27 Oct 2008 03:42:10 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 354F73A67D9 for ; Mon, 27 Oct 2008 03:42:09 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [85.53.143.124])by smtp01.uc3m.es (Postfix) with ESMTP id 201CBAC90D5; Mon, 27 Oct 2008 11:42:03 +0100 (CET) Message-ID: <49059AF8.3030402@it.uc3m.es> Date: Mon, 27 Oct 2008 11:42:00 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Guang Yao References: <014b01c93805$9130b490$b3921db0$@tsinghua.edu.cn> <49057747.3020908@it.uc3m.es> <015a01c93818$265476d0$72fd6470$@tsinghua.edu.cn> In-Reply-To: <015a01c93818$265476d0$72fd6470$@tsinghua.edu.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-6.4359 TC:1F TRN:39 TV:5.5.1026(16242.006) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: savi@ietf.org Subject: Re: [savi] =?gb2312?b?tPC4tDogIFtGd2Q6IEktRCBBY3Rpb246ZHJhZnQtYmFn?= =?gb2312?b?bnVsby1zYXZpLXNlbmQtMDAudHh0XQ==?= 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, 27 Oct 2008 10:42:14 -0000 Guang Yao escribi¨®: > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > If you choose a switched ethernet and the MAC address has been bound to the > switch port, > IP Source Guard is enough. IP Source Guard checks binding of > IP-MAC-Port, and the binding of MAC and port is used to ensure the security > of MAC. > Your mechanism checks IP-MAC, and supposes the MAC is secure. I think there > is not much difference in a switched ethernet. > Your mechanism can handle the mobility of layer 2 easily, which is an > advantage over IP Source Guard. > But actually I think IP Source Guard is able to handle mobility, too, by > enforcing SeND or making some other modification. > > but how do you actually prove that the sender is the owner of the IP address then? with CGA, SAVI knows for sure the owner of the address is in that port. wihtout cgas, you just assue that right? besdies, SeND based savi can support easily other confgurations such as multiple interfaces with the same address, anycast and so on In addition, with send, you can learn the prefixes in a secure manner and the auhtorized routers, which are needed to properly perform the savi validation so, i think send provides quite a few advantages when doing this. Of course the downside is that you need send deployed > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > I cannot quite understand your explaination... > I mean, if an attacker is sending a lot packets with spoofed mac but proper > IP, the check point has to > keep a state of all the spoofing packets and perform a lot of NUD. The cost > of discarding a single packet > is not much, but it is vulnerable under DoS attacks. Why not discard the > packets directly and use other > mechanisms to handle special issues? > i see, you mean that the savi function is susceptible to a DoS attack. Yes, this is true indeed, as any function that requires state is subject to this type of attack. I guess that if you are building such function, you need to have enough memory and mange it well. OTOH, you know who the attacker is, sicne you have it identified regards, marcelo From marcelo@it.uc3m.es Mon Oct 27 05:20:31 2008 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 33D9E3A6A14 for ; Mon, 27 Oct 2008 05:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=4.590, 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 v3r-BxwiQC0O for ; Mon, 27 Oct 2008 05:20:30 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 0472A3A69EF for ; Mon, 27 Oct 2008 05:20:29 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (124.pool85-53-143.dynamic.orange.es [85.53.143.124])by smtp02.uc3m.es (Postfix) with ESMTP id 81C0B5C878Cfor ; Mon, 27 Oct 2008 13:20:27 +0100 (CET) Message-ID: <4905B20A.9090906@it.uc3m.es> Date: Mon, 27 Oct 2008 13:20:26 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: SAVI Mailing List Content-Type: multipart/mixed; boundary=------------050506080108010804080001 X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-16.7749 TC:1F TRN:35 TV:5.5.1026(16242.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [savi] [Fwd: I-D Action:draft-bagnulo-savi-fcfs-00.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, 27 Oct 2008 12:20:31 -0000 This is a multi-part message in MIME format. --------------050506080108010804080001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, we have submitted a draft describing a savi approach based on the first-come first-serve policy. The proposed approach works with IPv4 and IPv6 and does not requires any change in the hosts. comments are welcome regards, marcelo -------- Mensaje original -------- Asunto: I-D Action:draft-bagnulo-savi-fcfs-00.txt Fecha: Mon, 27 Oct 2008 05:15:01 -0700 (PDT) De: Internet-Drafts@ietf.org Responder a: internet-drafts@ietf.org Para: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : First-Come First-Serve Source-Address Validation Implementation Author(s) : E. Nordmark, M. Bagnulo Filename : draft-bagnulo-savi-fcfs-00.txt Pages : 11 Date : 2008-10-27 This memo describes FCFS SAVI a mechanism to provide source address validation for IPv4 and 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-bagnulo-savi-fcfs-00.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. --------------050506080108010804080001 Content-Type: Message/External-body; name="draft-bagnulo-savi-fcfs-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-bagnulo-savi-fcfs-00.txt" Content-Type: text/plain Content-ID: <2008-10-27050039.I-D@ietf.org> --------------050506080108010804080001 Content-Type: text/plain; name="Parte del mensaje adjunto" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Parte del mensaje adjunto" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------050506080108010804080001-- From junbi@cernet.edu.cn Mon Oct 27 07:51:55 2008 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 5639A3A6B2E for ; Mon, 27 Oct 2008 07:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 8.826 X-Spam-Level: ******** X-Spam-Status: Yes, score=8.826 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_HAS_XAIMC=2.696, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_RECV_IP_221000=1.433, SARE_SUB_ENC_GB2312=1.345, STOX_REPLY_TYPE=0.001] X-Spam-Report: * 0.0 STOX_REPLY_TYPE STOX_REPLY_TYPE * 2.7 FH_HAS_XAIMC Has X-AIMC-AUTH header * 1.3 SARE_SUB_ENC_GB2312 Subject specifies display in non-English lang * 1.4 SARE_RECV_IP_221000 Passed through possible spammer relay or source * 3.2 CHARSET_FARAWAY_HEADER A foreign language charset used in headers * -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] * 2.5 MIME_CHARSET_FARAWAY MIME character set indicates foreign language * 0.3 MIME_8BIT_HEADER Message header contains 8-bit character 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 cL7kI0wF+QQu for ; Mon, 27 Oct 2008 07:51:49 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 6EDA53A694C for ; Mon, 27 Oct 2008 07:50:55 -0700 (PDT) Received: from userPC([221.0.174.2]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm304906447a; Mon, 27 Oct 2008 22:50:53 +0800 Message-ID: <72EE5EDBBF674DD4B630C9815BEB8D66@userPC> From: "Jun Bi" To: "marcelo bagnulo braun" , "Guang Yao" References: <014b01c93805$9130b490$b3921db0$@tsinghua.edu.cn> <49057747.3020908@it.uc3m.es> <015a01c93818$265476d0$72fd6470$@tsinghua.edu.cn> <49059AF8.3030402@it.uc3m.es> In-Reply-To: <49059AF8.3030402@it.uc3m.es> Date: Mon, 27 Oct 2008 22:50:37 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: ELj03uUB Cc: savi@ietf.org Subject: [savi] =?gb2312?b?KioqU1BBTSoqKiA4LjgyNiAoNSkgUmU6ICC08Li0OiAg?= =?gb2312?b?W0Z3ZDogSS1EIEFjdGlvbjpkcmFmdC1iYWdudWxvLXNhdmktc2Vu?= =?gb2312?b?ZC0wMC50eHRd?= 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, 27 Oct 2008 14:51:55 -0000 Dear Marcelo, Thank you for your contribution to the WG. I fully support a solution with SeND. But a solution should handle the spoofable MAC address. So if you want your solution work, please do more work to fix it. CERNET (china education and research network) run 2000 university campus networks. We found the MAC address is spoofable, at least in 2 cases: 1) If you access with a WiFi AP, which is the common case in campus network, 2) MAC can be spoofed when using a HUB (multiple MAC addresses per link, as charter said). Using a hub is a common situation for at least 1/2 universities for the dormitory network. More comments below. ----- Original Message ----- From: "marcelo bagnulo braun" To: "Guang Yao" Cc: Sent: Monday, October 27, 2008 6:42 PM Subject: Re: [savi] ´ð¸´: [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt] > Guang Yao escribi¨®: >> >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> If you choose a switched ethernet and the MAC address has been bound to >> the >> switch port, >> IP Source Guard is enough. IP Source Guard checks binding of >> IP-MAC-Port, and the binding of MAC and port is used to ensure the >> security >> of MAC. >> Your mechanism checks IP-MAC, and supposes the MAC is secure. I think >> there >> is not much difference in a switched ethernet. >> Your mechanism can handle the mobility of layer 2 easily, which is an >> advantage over IP Source Guard. >> But actually I think IP Source Guard is able to handle mobility, too, by >> enforcing SeND or making some other modification. >> >> > but how do you actually prove that the sender is the owner of the IP > address then? > with CGA, SAVI knows for sure the owner of the address is in that port. > wihtout cgas, you just assue that right? > besdies, SeND based savi can support easily other confgurations such as > multiple interfaces with the same address, anycast and so on > In addition, with send, you can learn the prefixes in a secure manner > and the auhtorized routers, which are needed to properly perform the > savi validation > > so, i think send provides quite a few advantages when doing this. Of > course the downside is that you need send deployed > > >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> I cannot quite understand your explaination... >> I mean, if an attacker is sending a lot packets with spoofed mac but >> proper >> IP, the check point has to >> keep a state of all the spoofing packets and perform a lot of NUD. The >> cost >> of discarding a single packet >> is not much, but it is vulnerable under DoS attacks. Why not discard the >> packets directly and use other >> mechanisms to handle special issues? >> > > i see, you mean that the savi function is susceptible to a DoS attack. > Yes, this is true indeed, as any function that requires state is subject > to this type of attack. I guess that if you are building such function, > you need to have enough memory and mange it well. Could you please estimate how much the memory it requires? Right now I don't mean it doesn't work, I mean in engineering, please give us the analysis or do an implementation and testing. Giving the quantity analysis will be helpful to investigate the feasibility. > OTOH, you know who the > attacker is, sicne you have it identified > > regards, marcelo In WiFi case and HUB case, if it is attacked with spoofed MAC address, then it world be hard to know who is the attacher. thanks, Jun Bi From junbi@cernet.edu.cn Mon Oct 27 07:58:20 2008 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 539BC28C149 for ; Mon, 27 Oct 2008 07:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 6.386 X-Spam-Level: ****** X-Spam-Status: Yes, score=6.386 tagged_above=-999 required=5 tests=[AWL=2.441, BAYES_40=-0.185, FH_HAS_XAIMC=2.696, SARE_RECV_IP_221000=1.433, STOX_REPLY_TYPE=0.001] X-Spam-Report: * 0.0 STOX_REPLY_TYPE STOX_REPLY_TYPE * 2.7 FH_HAS_XAIMC Has X-AIMC-AUTH header * 1.4 SARE_RECV_IP_221000 Passed through possible spammer relay or source * -0.2 BAYES_40 BODY: Bayesian spam probability is 20 to 40% * [score: 0.3776] * 2.4 AWL AWL: From: address is in the auto white-list 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 baUxx7D8-3-5 for ; Mon, 27 Oct 2008 07:58:16 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id B694A28C13D for ; Mon, 27 Oct 2008 07:58:15 -0700 (PDT) Received: from userPC([221.0.174.2]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm5649064632; Mon, 27 Oct 2008 22:58:12 +0800 Message-ID: <32D9656EDC0945EF8337CF715C6A2C17@userPC> From: "Jun Bi" To: "marcelo bagnulo braun" , "Guang Yao" References: <014b01c93805$9130b490$b3921db0$@tsinghua.edu.cn> <49057747.3020908@it.uc3m.es> In-Reply-To: <49057747.3020908@it.uc3m.es> Date: Mon, 27 Oct 2008 22:58:01 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: EGo73uUB Cc: savi@ietf.org Subject: [savi] ***SPAM*** 6.386 (5) Re: [Fwd: I-D Action:draft-bagnulo-savi-send-00.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, 27 Oct 2008 14:58:20 -0000 > >> 4 As I know, when SeND is used, the CGA address must be used. Maybe this >> mechanism must be modified to adapt DHCP and manual configuration. >> >> > > sure, CSI wg is chartered to do exactly that > > Regards, marcelo > By running 200 IP v6 university campus networks in CERNET2, we mainly use stateless address and manual configuration, sometimes consider DHCPv6. As the charter required the solution should work with all address assignment mechanisms. I think at least it is mandatory to support manual configuration. thanks, Jun Bi From marcelo@it.uc3m.es Mon Oct 27 10:16:19 2008 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 916C13A6358 for ; Mon, 27 Oct 2008 10:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.533 X-Spam-Level: *** X-Spam-Status: No, score=3.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 vECcSXr9ldxU for ; Mon, 27 Oct 2008 10:16:18 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 847FB3A6943 for ; Mon, 27 Oct 2008 10:16:18 -0700 (PDT) Received: from dummyhost14.it.uc3m.es (dummyhost22.it.uc3m.es [163.117.139.62])by smtp03.uc3m.es (Postfix) with ESMTP id 19D0E6AE279; Mon, 27 Oct 2008 18:16:16 +0100 (CET) Message-ID: <4905F75F.5070608@it.uc3m.es> Date: Mon, 27 Oct 2008 18:16:15 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Jun Bi References: <014b01c93805$9130b490$b3921db0$@tsinghua.edu.cn> <49057747.3020908@it.uc3m.es> <015a01c93818$265476d0$72fd6470$@tsinghua.edu.cn> <49059AF8.3030402@it.uc3m.es> <72EE5EDBBF674DD4B630C9815BEB8D66@userPC> In-Reply-To: <72EE5EDBBF674DD4B630C9815BEB8D66@userPC> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-25.6453 TC:1F TRN:51 TV:5.5.1026(16244.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: savi@ietf.org, Guang Yao Subject: Re: [savi] =?gb2312?b?tPC4tDogIFtGd2Q6IEktRCBBY3Rpb246ZHJhZnQtYmFn?= =?gb2312?b?bnVsby1zYXZpLXNlbmQtMDAudHh0XQ==?= 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, 27 Oct 2008 17:16:19 -0000 Jun Bi escribi¨®: > Dear Marcelo, > > Thank you for your contribution to the WG. > > I fully support a solution with SeND. But a solution should handle the > spoofable MAC address. > So if you want your solution work, please do more work to fix it. > > CERNET (china education and research network) run 2000 university > campus networks. We found the MAC address is spoofable, at least in 2 > cases: > 1) If you access with a WiFi AP, which is the common case in campus > network, > 2) MAC can be spoofed when using a HUB (multiple MAC addresses per > link, as charter said). Using a hub is a common situation for at least > 1/2 universities for the dormitory network. > So any idea how would any solution would provide the level of security you ask for and complies with the current charter, in particular with the constraint of not changing the hosts? I mean, it is not only because the charter says so, but because we need to define a solution that is deployable. IMHO requiring hosts changes for this is a non starter. I think a solution like SeND SAVI or FCFS SAVI that don't requires host changes is not perfect but styill is an increment of the current situation and the deployment model seems to me quite strong. > > Could you please estimate how much the memory it requires? > Right now I don't mean it doesn't work, I mean in engineering, please > give us the analysis or do an implementation and testing. > Giving the quantity analysis will be helpful to investigate the > feasibility. > Well, i would argue that this is similar to an ARP cache actually. I mean the attacker could send more packets with different mac addresses. The result is that the DB will overflow. No problem, since the SAVI function will ask for a new NA again. This result in more traffic, but there is no amplification. regards, marcelo > >> OTOH, you know who the >> attacker is, sicne you have it identified >> >> regards, marcelo > > In WiFi case and HUB case, if it is attacked with spoofed MAC address, > then it world be hard to know who is the attacher. > > thanks, > Jun Bi > > > > > From marcelo@it.uc3m.es Mon Oct 27 10:20:22 2008 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 6EA813A6A72 for ; Mon, 27 Oct 2008 10:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.115 X-Spam-Level: X-Spam-Status: No, score=-0.115 tagged_above=-999 required=5 tests=[AWL=3.647, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 CyIJDwhBhbmt for ; Mon, 27 Oct 2008 10:20:18 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 3EFC83A6804 for ; Mon, 27 Oct 2008 10:20:18 -0700 (PDT) Received: from dummyhost14.it.uc3m.es (dummyhost22.it.uc3m.es [163.117.139.62])by smtp03.uc3m.es (Postfix) with ESMTP id 390C36AE3B1; Mon, 27 Oct 2008 18:20:16 +0100 (CET) Message-ID: <4905F850.1080705@it.uc3m.es> Date: Mon, 27 Oct 2008 18:20:16 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Jun Bi References: <014b01c93805$9130b490$b3921db0$@tsinghua.edu.cn> <49057747.3020908@it.uc3m.es> <32D9656EDC0945EF8337CF715C6A2C17@userPC> In-Reply-To: <32D9656EDC0945EF8337CF715C6A2C17@userPC> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-14.3689 TC:1F TRN:30 TV:5.5.1026(16244.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: savi@ietf.org, Guang Yao Subject: Re: [savi] [Fwd: I-D Action:draft-bagnulo-savi-send-00.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, 27 Oct 2008 17:20:22 -0000 Jun Bi escribi¨®: >> >>> 4 As I know, when SeND is used, the CGA address must be used. Maybe >>> this >>> mechanism must be modified to adapt DHCP and manual configuration. >>> >>> >> >> sure, CSI wg is chartered to do exactly that >> >> Regards, marcelo >> > > By running 200 IP v6 university campus networks in CERNET2, we mainly > use stateless address and manual configuration, > sometimes consider DHCPv6. > if you are interested in doing some work about CGAs and dhcp, please contribute to the CSI wg http://www.ietf.org/html.charters/csi-charter.html > As the charter required the solution should work with all address > assignment mechanisms. I think at least it is mandatory to support > manual configuration. > sure, the same that i don't think it is reasonable to require send for the solution. the way i see it is if you happen to have send and cgas, then you can achieve a higher level of security. by no means i think a send based solution should be the only savi solution. I only think that it makes sense to have a savi solution for the case that send is available regards, marcelo > thanks, > Jun Bi > > > From junbi@cernet.edu.cn Mon Oct 27 11:11:01 2008 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 CA80E28C10D for ; Mon, 27 Oct 2008 11:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.958 X-Spam-Level: *** X-Spam-Status: No, score=3.958 tagged_above=-999 required=5 tests=[AWL=2.427, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, SARE_RECV_IP_221000=1.433, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMp2EGdvWiKU for ; Mon, 27 Oct 2008 11:11:01 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 68FF328C134 for ; Mon, 27 Oct 2008 11:10:59 -0700 (PDT) Received: from userPC([221.0.174.87]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm1d49067360; Tue, 28 Oct 2008 02:10:58 +0800 Message-ID: From: "Jun Bi" To: "marcelo bagnulo braun" References: <014b01c93805$9130b490$b3921db0$@tsinghua.edu.cn> <49057747.3020908@it.uc3m.es> <32D9656EDC0945EF8337CF715C6A2C17@userPC> <4905F850.1080705@it.uc3m.es> In-Reply-To: <4905F850.1080705@it.uc3m.es> Date: Tue, 28 Oct 2008 02:10:40 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: EMW86uUB Cc: savi@ietf.org, Guang Yao Subject: Re: [savi] [Fwd: I-D Action:draft-bagnulo-savi-send-00.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, 27 Oct 2008 18:11:01 -0000 ----- Original Message ----- From: "marcelo bagnulo braun" To: "Jun Bi" Cc: "Guang Yao" ; Sent: Tuesday, October 28, 2008 1:20 AM Subject: Re: [savi] [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt] > Jun Bi escribi¨®: >>> >>>> 4 As I know, when SeND is used, the CGA address must be used. Maybe >>>> this >>>> mechanism must be modified to adapt DHCP and manual configuration. >>>> >>>> >>> >>> sure, CSI wg is chartered to do exactly that >>> >>> Regards, marcelo >>> >> >> By running 200 IP v6 university campus networks in CERNET2, we mainly >> use stateless address and manual configuration, >> sometimes consider DHCPv6. >> > if you are interested in doing some work about CGAs and dhcp, please > contribute to the CSI wg > http://www.ietf.org/html.charters/csi-charter.html > >> As the charter required the solution should work with all address >> assignment mechanisms. I think at least it is mandatory to support >> manual configuration. >> > sure, the same that i don't think it is reasonable to require send for > the solution. > > the way i see it is if you happen to have send and cgas, then you can > achieve a higher level of security. > by no means i think a send based solution should be the only savi > solution. I only think that it makes sense to have a savi solution for > the case that send is available > > regards, marcelo So you also agree that in some senarios required in savi charter, we need to consider other solutions. thanks, Jun From marcelo@it.uc3m.es Mon Oct 27 11:27:47 2008 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 64F3F3A6B7A for ; Mon, 27 Oct 2008 11:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[AWL=1.641, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 n3qpjp0+vJqD for ; Mon, 27 Oct 2008 11:27:46 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 3C3E53A6A8B for ; Mon, 27 Oct 2008 11:27:45 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (226.pool85-53-141.dynamic.orange.es [85.53.141.226])by smtp03.uc3m.es (Postfix) with ESMTP id 10DDF6AE400; Mon, 27 Oct 2008 19:27:41 +0100 (CET) Message-ID: <4906081D.7060002@it.uc3m.es> Date: Mon, 27 Oct 2008 19:27:41 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Jun Bi References: <014b01c93805$9130b490$b3921db0$@tsinghua.edu.cn> <49057747.3020908@it.uc3m.es> <32D9656EDC0945EF8337CF715C6A2C17@userPC> <4905F850.1080705@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-17.6269 TC:1F TRN:37 TV:5.5.1026(16244.001) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: savi@ietf.org, Guang Yao Subject: Re: [savi] [Fwd: I-D Action:draft-bagnulo-savi-send-00.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, 27 Oct 2008 18:27:47 -0000 Jun Bi escribi¨®: > > ----- Original Message ----- From: "marcelo bagnulo braun" > > To: "Jun Bi" > Cc: "Guang Yao" ; > Sent: Tuesday, October 28, 2008 1:20 AM > Subject: Re: [savi] [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt] > > >> Jun Bi escribi¨®: >>>> >>>>> 4 As I know, when SeND is used, the CGA address must be used. Maybe >>>>> this >>>>> mechanism must be modified to adapt DHCP and manual configuration. >>>>> >>>>> >>>> >>>> sure, CSI wg is chartered to do exactly that >>>> >>>> Regards, marcelo >>>> >>> >>> By running 200 IP v6 university campus networks in CERNET2, we mainly >>> use stateless address and manual configuration, >>> sometimes consider DHCPv6. >>> >> if you are interested in doing some work about CGAs and dhcp, please >> contribute to the CSI wg >> http://www.ietf.org/html.charters/csi-charter.html >> >>> As the charter required the solution should work with all address >>> assignment mechanisms. I think at least it is mandatory to support >>> manual configuration. >>> >> sure, the same that i don't think it is reasonable to require send for >> the solution. >> >> the way i see it is if you happen to have send and cgas, then you can >> achieve a higher level of security. >> by no means i think a send based solution should be the only savi >> solution. I only think that it makes sense to have a savi solution for >> the case that send is available >> >> regards, marcelo > > So you also agree that in some senarios required in savi charter, we > need to consider other solutions. > indeed! however, i do think that these solutions should not require host changes as it is stated in the charter please check draft-bagnulo-savi-fcfs-00 recently posted for what i have in mind about how other solutions could be regards, marcelo > thanks, > Jun > > From yaoa02@mails.tsinghua.edu.cn Mon Oct 27 12:11:55 2008 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 56E893A6B89 for ; Mon, 27 Oct 2008 12:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.474 X-Spam-Level: **** X-Spam-Status: No, score=4.474 tagged_above=-999 required=5 tests=[AWL=-0.561, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] 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 uSC2AHia5nGr for ; Mon, 27 Oct 2008 12:11:54 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id 067C63A6BB3 for ; Mon, 27 Oct 2008 12:11:51 -0700 (PDT) Received: from [166.111.132.215] (helo=netarchld5f663) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.63) (envelope-from ) id 1KuXVD-0005L5-5L; Tue, 28 Oct 2008 03:11:47 +0800 From: "Guang Yao" To: "'marcelo bagnulo braun'" References: <014b01c93805$9130b490$b3921db0$@tsinghua.edu.cn> <49057747.3020908@it.uc3m.es> <015a01c93818$265476d0$72fd6470$@tsinghua.edu.cn> <49059AF8.3030402@it.uc3m.es> In-Reply-To: <49059AF8.3030402@it.uc3m.es> Date: Tue, 28 Oct 2008 03:11:43 +0800 Message-ID: <000b01c93867$d99a12f0$8cce38d0$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ack4IKjeKKw52fKGQUCWcxl7Z0c6cQARZ2Qg Content-Language: zh-cn Cc: savi@ietf.org Subject: [savi] =?gb2312?b?tPC4tDogtPC4tDogIFtGd2Q6IEktRCBBY3Rpb246ZHJh?= =?gb2312?b?ZnQtYmFnbnVsby1zYXZpLXNlbmQtMDAudHh0XQ==?= 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, 27 Oct 2008 19:11:55 -0000 -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2008=C4=EA10=D4=C227=C8=D5 18:42 =CA=D5=BC=FE=C8=CB: Guang Yao =B3=AD=CB=CD: savi@ietf.org =D6=F7=CC=E2: Re: =B4=F0=B8=B4: [savi] [Fwd: I-D = Action:draft-bagnulo-savi-send-00.txt] Guang Yao escribi=A8=AE: > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > If you choose a switched ethernet and the MAC address has been bound = to the > switch port, > IP Source Guard is enough. IP Source Guard checks binding of > IP-MAC-Port, and the binding of MAC and port is used to ensure the security > of MAC. > Your mechanism checks IP-MAC, and supposes the MAC is secure. I think there > is not much difference in a switched ethernet. > Your mechanism can handle the mobility of layer 2 easily, which is an > advantage over IP Source Guard. > But actually I think IP Source Guard is able to handle mobility, too, = by > enforcing SeND or making some other modification. > > =20 but how do you actually prove that the sender is the owner of the IP address then? with CGA, SAVI knows for sure the owner of the address is in that port. wihtout cgas, you just assue that right? besdies, SeND based savi can support easily other confgurations such as multiple interfaces with the same address, anycast and so on In addition, with send, you can learn the prefixes in a secure manner and the auhtorized routers, which are needed to properly perform the savi validation so, i think send provides quite a few advantages when doing this. Of course the downside is that you need send deployed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I don't mean SeND is not good. I mean IP Source Guard can also take advantage of SeND. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > I cannot quite understand your explaination... > I mean, if an attacker is sending a lot packets with spoofed mac but proper > IP, the check point has to > keep a state of all the spoofing packets and perform a lot of NUD. The cost > of discarding a single packet > is not much, but it is vulnerable under DoS attacks. Why not discard = the > packets directly and use other > mechanisms to handle special issues? > =20 i see, you mean that the savi function is susceptible to a DoS attack. Yes, this is true indeed, as any function that requires state is subject to this type of attack. I guess that if you are building such function, you need to have enough memory and mange it well. OTOH, you know who the attacker is, sicne you have it identified ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It is much difficult for me to understand this point. How can I know who = the attacker is? regards, marcelo From yaoa02@mails.tsinghua.edu.cn Mon Oct 27 19:40:40 2008 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 567883A68CB for ; Mon, 27 Oct 2008 19:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.661 X-Spam-Level: **** X-Spam-Status: No, score=4.661 tagged_above=-999 required=5 tests=[AWL=-0.374, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] 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 gmGUlm3xekSj for ; Mon, 27 Oct 2008 19:40:39 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id 119863A688E for ; Mon, 27 Oct 2008 19:40:39 -0700 (PDT) Received: from [166.111.132.215] (helo=netarchld5f663) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.63) (envelope-from ) id 1KueVT-00005B-TR for savi@ietf.org; Tue, 28 Oct 2008 10:40:32 +0800 From: "Guang Yao" To: Date: Tue, 28 Oct 2008 10:40:28 +0800 Message-ID: <000601c938a6$89d60140$9d8203c0$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ack4V7jFbLZ7SMU9TLutA8woU6GlBAABtiLQABH8InA= Content-Language: zh-cn Subject: [savi] =?gb2312?b?16q3ojogILTwuLQ6ICBbRndkOiBJLUQgQWN0aW9uOmRy?= =?gb2312?b?YWZ0LWJhZ251bG8tc2F2aS1zZW5kLTAwLnR4dF0=?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2008 02:40:40 -0000 -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Guang Yao [mailto:yaoa02@mails.tsinghua.edu.cn]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2008=C4=EA10=D4=C228=C8=D5 2:47 =CA=D5=BC=FE=C8=CB: 'marcelo bagnulo braun' =D6=F7=CC=E2: =B4=F0=B8=B4: [savi] =B4=F0=B8=B4: [Fwd: I-D = Action:draft-bagnulo-savi-send-00.txt] -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2008=C4=EA10=D4=C228=C8=D5 1:16 =CA=D5=BC=FE=C8=CB: Jun Bi =B3=AD=CB=CD: Guang Yao; savi@ietf.org =D6=F7=CC=E2: Re: [savi] =B4=F0=B8=B4: [Fwd: I-D = Action:draft-bagnulo-savi-send-00.txt] Jun Bi escribi=A8=AE: > Dear Marcelo, > > Thank you for your contribution to the WG. > > I fully support a solution with SeND. But a solution should handle the > spoofable MAC address. > So if you want your solution work, please do more work to fix it. > > CERNET (china education and research network) run 2000 university > campus networks. We found the MAC address is spoofable, at least in 2 > cases: > 1) If you access with a WiFi AP, which is the common case in campus > network, > 2) MAC can be spoofed when using a HUB (multiple MAC addresses per > link, as charter said). Using a hub is a common situation for at least > 1/2 universities for the dormitory network. > So any idea how would any solution would provide the level of security you ask for and complies with the current charter, in particular with the constraint of not changing the hosts? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I think with the constraint of not changing the hosts, the only possible = way Is using a switch mechanism to filter normal data packet and using SeND = to=20 handle mobility at layer2 and other special issues. (But here is still a rather strong precondition that the SeND has been enabled.) And I think your mechanism is secure if you restrict it as a switch mechanism. Your mechanism and IP Source Guard are both in the correct direction in = a switch LAN. Actually I discussed with an engineer of Cisco, his group is = implementing the IP Source Guard for IPv6. And I found they were using SeND to handle layer-2 mobility. Maybe you can first adapt your mechanism for a switch network, to avoid = the argument on its security in a non-switch network. In my opinion, there is no way to achieve strict security with the constraint of no host change when there is no switch in the network. That is not the fault of your mechanism. The solution is not there. I mean, it is not only because the charter says so, but because we need to define a solution that is deployable. IMHO requiring hosts changes for this is a non starter. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ IMHO, host change is a non starter, but is an ending. If we constrain = there should be no host change when finding more secure ND, there will be no SeND. SeND is successful so we modify our host to employ SeND. And = for source address validation, I think the situation may be much the same. I think a solution like SeND SAVI or FCFS SAVI that don't requires host changes is not perfect but styill is an increment of the current situation and the deployment model seems to me quite strong. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I agree with you. That is all we can do now. We have tried all the = possible methods and now we found it's clear what we can achieve is limited. It is better but far from a real security.=20 Since all the existing protocols are not designed for source address validation, why we must persist that we can achieve a great result by = taking advantage of them? > > Could you please estimate how much the memory it requires? > Right now I don't mean it doesn't work, I mean in engineering, please > give us the analysis or do an implementation and testing. > Giving the quantity analysis will be helpful to investigate the > feasibility. > Well, i would argue that this is similar to an ARP cache actually. I mean the attacker could send more packets with different mac addresses. The result is that the DB will overflow. No problem, since the SAVI function will ask for a new NA again. This result in more traffic, but there is no amplification. regards, marcelo > >> OTOH, you know who the >> attacker is, sicne you have it identified >> >> regards, marcelo > > In WiFi case and HUB case, if it is attacked with spoofed MAC address, > then it world be hard to know who is the attacher. > > thanks, > Jun Bi > > > > > From yaoa02@mails.tsinghua.edu.cn Mon Oct 27 19:57:35 2008 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 3BFD23A688E for ; Mon, 27 Oct 2008 19:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.754 X-Spam-Level: **** X-Spam-Status: No, score=4.754 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] 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 cCE55yKvtr-l for ; Mon, 27 Oct 2008 19:57:34 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id 054D03A688A for ; Mon, 27 Oct 2008 19:57:34 -0700 (PDT) Received: from [166.111.132.215] (helo=netarchld5f663) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.63) (envelope-from ) id 1Kuelu-0000Sw-Ey; Tue, 28 Oct 2008 10:57:30 +0800 From: "Guang Yao" To: "'marcelo bagnulo braun'" References: <014b01c93805$9130b490$b3921db0$@tsinghua.edu.cn> <49057747.3020908@it.uc3m.es> <015a01c93818$265476d0$72fd6470$@tsinghua.edu.cn> <49059AF8.3030402@it.uc3m.es> <72EE5EDBBF674DD4B630C9815BEB8D66@userPC> <4905F75F.5070608@it.uc3m.es> <000a01c93865$afc33cb0$0f49b610$@tsinghua.edu.cn> <49061580.8010503@it.uc3m.es> In-Reply-To: <49061580.8010503@it.uc3m.es> Date: Tue, 28 Oct 2008 10:57:26 +0800 Message-ID: <000701c938a8$e8ed8070$bac88150$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ack4aa6sYdiIjfs1TVaTDdfC6zG8RwAPPLTQ Content-Language: zh-cn Cc: savi@ietf.org Subject: [savi] =?gb2312?b?tPC4tDogtPC4tDogILTwuLQ6ICBbRndkOiBJLUQgQWN0?= =?gb2312?b?aW9uOmRyYWZ0LWJhZ251bG8tc2F2aS1zZW5kLTAwLnR4dF0=?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2008 02:57:35 -0000 -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2008=C4=EA10=D4=C228=C8=D5 3:25 =CA=D5=BC=FE=C8=CB: Guang Yao =D6=F7=CC=E2: Re: =B4=F0=B8=B4: [savi] =B4=F0=B8=B4: [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt] Guang Yao escribi=A8=AE: > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 > =B7=A2=CB=CD=CA=B1=BC=E4: 2008=C4=EA10=D4=C228=C8=D5 1:16 > =CA=D5=BC=FE=C8=CB: Jun Bi > =B3=AD=CB=CD: Guang Yao; savi@ietf.org > =D6=F7=CC=E2: Re: [savi] =B4=F0=B8=B4: [Fwd: I-D = Action:draft-bagnulo-savi-send-00.txt] > > Jun Bi escribi=A8=AE: > =20 >> Dear Marcelo, >> >> Thank you for your contribution to the WG. >> >> I fully support a solution with SeND. But a solution should handle = the >> spoofable MAC address. >> So if you want your solution work, please do more work to fix it. >> >> CERNET (china education and research network) run 2000 university >> campus networks. We found the MAC address is spoofable, at least in 2 >> cases: >> 1) If you access with a WiFi AP, which is the common case in campus >> network, >> 2) MAC can be spoofed when using a HUB (multiple MAC addresses per >> link, as charter said). Using a hub is a common situation for at = least >> 1/2 universities for the dormitory network. >> >> =20 > So any idea how would any solution would provide the level of security > you ask for and complies with the current charter, in particular with > the constraint of not changing the hosts? > > I mean, it is not only because the charter says so, but because we = need > to define a solution that is deployable. IMHO requiring hosts changes > for this is a non starter. > I think a solution like SeND SAVI or FCFS SAVI that don't requires = host > changes is not perfect but styill is an increment of the current > situation and the deployment model seems to me quite strong. > > =20 >> Could you please estimate how much the memory it requires? >> Right now I don't mean it doesn't work, I mean in engineering, please >> give us the analysis or do an implementation and testing. >> Giving the quantity analysis will be helpful to investigate the >> feasibility. >> >> =20 > > Well, i would argue that this is similar to an ARP cache actually. > I mean the attacker could send more packets with different mac > addresses. The result is that the DB will overflow. No problem, since > the SAVI function will ask for a new NA again. This result in more > traffic, but there is no amplification. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > I don=A1=AFt think so. You forget the attack can make the DB overflow = all the > time and disable the mechanism totally. > Some other mechanism must be used to protect the DB. > =20 No this is not true If the db is overflowed, then the savi function will simply ask for NS again, exactly the same when the ARP cache is overflowed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ You must cache the spoofing packets and normal packets before NUD reply. = This cache can be overflowed. Then you must choose either to drop all packets=20 or transmit all packets. Both of them are dangerous. The former will = stop the normal communication and the later will allow spoofing. Even you use a huge cache, the normal communication will be delayed = greatly. Regards, marcelo > regards, marcelo > > > > > =20 >>> OTOH, you know who the >>> attacker is, sicne you have it identified >>> >>> regards, marcelo >>> =20 >> In WiFi case and HUB case, if it is attacked with spoofed MAC = address, >> then it world be hard to know who is the attacher. >> >> thanks, >> Jun Bi >> >> >> >> >> >> =20 > > > > =20 From marcelo@it.uc3m.es Tue Oct 28 01:35:02 2008 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 131893A6BC0 for ; Tue, 28 Oct 2008 01:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.286 X-Spam-Level: * X-Spam-Status: No, score=1.286 tagged_above=-999 required=5 tests=[AWL=-2.586, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 UrbmDQblAplE for ; Tue, 28 Oct 2008 01:35:01 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id A83873A6BA1 for ; Tue, 28 Oct 2008 01:35:00 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [85.53.138.189])by smtp01.uc3m.es (Postfix) with ESMTP id 01E76AC9335; Tue, 28 Oct 2008 09:34:56 +0100 (CET) Message-ID: <4906CEAF.6070008@it.uc3m.es> Date: Tue, 28 Oct 2008 09:34:55 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Guang Yao References: <014b01c93805$9130b490$b3921db0$@tsinghua.edu.cn> <49057747.3020908@it.uc3m.es> <015a01c93818$265476d0$72fd6470$@tsinghua.edu.cn> <49059AF8.3030402@it.uc3m.es> <72EE5EDBBF674DD4B630C9815BEB8D66@userPC> <4905F75F.5070608@it.uc3m.es> <000a01c93865$afc33cb0$0f49b610$@tsinghua.edu.cn> <49061580.8010503@it.uc3m.es> <000701c938a8$e8ed8070$bac88150$@tsinghua.edu.cn> In-Reply-To: <000701c938a8$e8ed8070$bac88150$@tsinghua.edu.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-39.7255 TC:1F TRN:84 TV:5.5.1026(16244.004) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: savi@ietf.org Subject: Re: [savi] =?gb2312?b?tPC4tDogtPC4tDogILTwuLQ6ICBbRndkOiBJLUQgQWN0?= =?gb2312?b?aW9uOmRyYWZ0LWJhZ251bG8tc2F2aS1zZW5kLTAwLnR4dF0=?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2008 08:35:02 -0000 Guang Yao escribi¨®: > -----ÓʼþÔ­¼þ----- > ·¢¼þÈË: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > ·¢ËÍʱ¼ä: 2008Äê10ÔÂ28ÈÕ 3:25 > ÊÕ¼þÈË: Guang Yao > Ö÷Ìâ: Re: ´ð¸´: [savi] ´ð¸´: [Fwd: I-D > Action:draft-bagnulo-savi-send-00.txt] > > Guang Yao escribi¨®: > >> -----ÓʼþÔ­¼þ----- >> ·¢¼þÈË: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> ·¢ËÍʱ¼ä: 2008Äê10ÔÂ28ÈÕ 1:16 >> ÊÕ¼þÈË: Jun Bi >> ³­ËÍ: Guang Yao; savi@ietf.org >> Ö÷Ìâ: Re: [savi] ´ð¸´: [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt] >> >> Jun Bi escribi¨®: >> >> >>> Dear Marcelo, >>> >>> Thank you for your contribution to the WG. >>> >>> I fully support a solution with SeND. But a solution should handle the >>> spoofable MAC address. >>> So if you want your solution work, please do more work to fix it. >>> >>> CERNET (china education and research network) run 2000 university >>> campus networks. We found the MAC address is spoofable, at least in 2 >>> cases: >>> 1) If you access with a WiFi AP, which is the common case in campus >>> network, >>> 2) MAC can be spoofed when using a HUB (multiple MAC addresses per >>> link, as charter said). Using a hub is a common situation for at least >>> 1/2 universities for the dormitory network. >>> >>> >>> >> So any idea how would any solution would provide the level of security >> you ask for and complies with the current charter, in particular with >> the constraint of not changing the hosts? >> >> I mean, it is not only because the charter says so, but because we need >> to define a solution that is deployable. IMHO requiring hosts changes >> for this is a non starter. >> I think a solution like SeND SAVI or FCFS SAVI that don't requires host >> changes is not perfect but styill is an increment of the current >> situation and the deployment model seems to me quite strong. >> >> >> >>> Could you please estimate how much the memory it requires? >>> Right now I don't mean it doesn't work, I mean in engineering, please >>> give us the analysis or do an implementation and testing. >>> Giving the quantity analysis will be helpful to investigate the >>> feasibility. >>> >>> >>> >> Well, i would argue that this is similar to an ARP cache actually. >> I mean the attacker could send more packets with different mac >> addresses. The result is that the DB will overflow. No problem, since >> the SAVI function will ask for a new NA again. This result in more >> traffic, but there is no amplification. >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> I don¡¯t think so. You forget the attack can make the DB overflow all the >> time and disable the mechanism totally. >> Some other mechanism must be used to protect the DB. >> >> > > No this is not true > If the db is overflowed, then the savi function will simply ask for NS > again, exactly the same when the ARP cache is overflowed > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > You must cache the spoofing packets and normal packets before NUD reply. > This cache can be overflowed. Then you must choose either to drop all > packets > or transmit all packets. Both of them are dangerous. The former will stop > the normal > communication and the later will allow spoofing. > Even you use a huge cache, the normal communication will be delayed greatly. > > but again, this is similar to the case of the ARP cache. I mean, when i send an ARP request to a host, the target host will include the information of the sender in the arp cache, so it is suceptible to the same type of attacks. there are other ways you can achieve the same type of attacks. Moreover, in SeND it is even harder for the attacker to launch such attach. In send, the good thing is that the verification of the CGA is quite cheap (only verify a hash) So, consider an attacker wants to launch an attack as the one you mention. It will start sending packets. If the packets carry the same source IP address, it is easy to detect and prevent (i.e. the SAVI function only accepts 10 entries with a given source IP address or so) If the packets carry different source IP address, then the attacker needs to generate different IP address. Since the source addresses are CGAs, the attacker needs to generate new CGA, which is an expensive procedure (at least it is more expsnive to generate them than to verify them, so the balance is reasonable to enable good defense) You can next get a bit deeper into what information you store about the CGAs in order to detect the same cga was used. It really depends on the SEC value you are using. If you are using a sec value other than 0, then you are probably ok, cause the CGA generation even with the same key is expensive. If you use a SEC value of 0, then just changing the modifier would do it. But in that case, you could actually store a hash of the key itself and you are in good shape. So, again, i don't see this attack as problematic Regards, marcelo > Regards, marcelo > > > > >> regards, marcelo >> >> >> >> >> >> >>>> OTOH, you know who the >>>> attacker is, sicne you have it identified >>>> >>>> regards, marcelo >>>> >>>> >>> In WiFi case and HUB case, if it is attacked with spoofed MAC address, >>> then it world be hard to know who is the attacher. >>> >>> thanks, >>> Jun Bi >>> >>> >>> >>> >>> >>> >>> >> >> >> > > > > From christian.vogt@nomadiclab.com Thu Oct 30 11:08:14 2008 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 94B3528B56A for ; Thu, 30 Oct 2008 11:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, 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 jF8-LowydblW for ; Thu, 30 Oct 2008 11:08:13 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 148693A6951 for ; Thu, 30 Oct 2008 11:08:13 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 537921EF130; Thu, 30 Oct 2008 20:08:10 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id E0D561EF12C; Thu, 30 Oct 2008 20:08:09 +0200 (EET) Message-Id: From: Christian Vogt To: SAVI Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 30 Oct 2008 20:08:09 +0200 References: <5AFF2C66-D235-4A69-9312-C22F03F94991@ericsson.com> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV using ClamSMTP Subject: [savi] Request to IESG: Additional SAVI working group documents 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, 30 Oct 2008 18:08:14 -0000 Folks, FYI: We have requested from IESG the addition of a Rationale document and a SeND-based Solution document to the SAVI charter. See quoted email below. - Christian Begin forwarded message: > From: Christian Vogt > Date: October 30, 2008 0:41:40 GMT+02:00 > To: Mark Townsley , Jari Arkko >, > IESG > Cc: Bill Fenner > Subject: Proposal for additional SAVI working group documents > > Hi Mark and Jari, dear IESG members, > > as a co-chair of the SAVI working group and in agreement with the > group, > I would like to request the addition of two document deliverables to > the > SAVI charter: > > - a Rationale document, comprising an analysis of the design space for > SAVI solutions, and a motivation for the solution approach that the > working group has agreed to take, > > - a document extending the IPv6 SAVI solution document by making use > of > Secure Neighbor Discovery (SeND) where this is deployed in addition > to SAVI. > > Both documents would be valuable to have for the following reasons: > > The Rationale document would give the working group guidance > throughout > the engineering phase, and it would provide a basis for assessing the > eventual SAVI solution. Furthermore, the document would certainly > be an > interesting read for engineers and researchers inside and outside of > IETF, given the large number of possible solution approaches that SAVI > could take. > > The extension for SeND would provide a straightforward way to exploit > existing means for IP address ownership verification for the purpose > of > SAVI. This gives network administrators an extra benefit for > deploying > SeND, while still not requiring SeND for SAVI to work. Note that this > proposed extension is fully compliant to the SAVI charter, since in an > environment where SeND is already deployed, the extension requires > neither host changes nor SAVI-specific protocols. > > Finally, I suggest the following milestones related to the proposed > new > documents: > > Dec 2008 First WG draft on SAVI solution rationale > Dec 2008 First WG draft on SeND-based SAVI extension > May 2009 Submit SAVI solution rationale to IESG for Informational RFC > May 2009 Submit SeND-based SAVI extension to IESG for Informational > RFC > > I would be happy to answer any questions you may have, and I am > looking > forward to hear about your decision. Thanks, and best regards, > > - Christian, for Bill and Christian From christian.vogt@nomadiclab.com Thu Oct 30 14:41:31 2008 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 7F2873A6981 for ; Thu, 30 Oct 2008 14:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=0.197, 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 0JEbQu+U27vc for ; Thu, 30 Oct 2008 14:41:30 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id B206B3A6B53 for ; Thu, 30 Oct 2008 14:41:30 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 7B47B1EF130; Thu, 30 Oct 2008 23:41:27 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 45BB61EF12C; Thu, 30 Oct 2008 23:41:27 +0200 (EET) Message-Id: <951708DA-D220-4EA0-BFD5-47564DA9EF7B@nomadiclab.com> From: Christian Vogt To: SAVI Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 30 Oct 2008 23:41:26 +0200 X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV using ClamSMTP Subject: [savi] Discussion Summary: SAVI's Basic Solution Approach 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, 30 Oct 2008 21:41:31 -0000 Folks, thanks for a good discussion about the basic solution approach that SAVI should take. I think we reached more than just "rough" consensus on that we should follow two parallel tracks: a non-cryptographic base SAVI protocol, which will rely on nothing more but ARP/ND/DHCP, and a cryptographic SAVI extension, which will take advantage of SeND in networks where this is deployed. We also reinforced that the charter requirements are not debatable -- i.e., no host changes, no special protocols. Finally, we agreed with our area director that SAVI should complement, but not substitute, ingress filtering. Time to move on to more specific questions then. I will identify two of those in separate emails. - Christian, for Bill and Christian From christian.vogt@nomadiclab.com Thu Oct 30 14:43:14 2008 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 45D543A6B73 for ; Thu, 30 Oct 2008 14:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.169, 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 Hx1CeJnRCCuE for ; Thu, 30 Oct 2008 14:43:13 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 125B23A6B71 for ; Thu, 30 Oct 2008 14:43:13 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 2058D1EF130; Thu, 30 Oct 2008 23:43:10 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id B01761EF12C; Thu, 30 Oct 2008 23:43:09 +0200 (EET) Message-Id: From: Christian Vogt To: marcelo bagnulo braun In-Reply-To: <490498C5.3080706@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 30 Oct 2008 23:43:09 +0200 References: <490498C5.3080706@it.uc3m.es> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV using ClamSMTP Cc: SAVI Mailing List Subject: [savi] Review of draft-bagnulo-savi-send-00 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2008 21:43:14 -0000 marcelo bagnulo braun wrote: > I have submitted a draft describing how to build a SAVI solution using > the SeND protocol without any change to the hosts nor to the SeND > protocol. I think the resulting security level is pretty good. > > Comments would be appreciated. Hi Marcelo, thanks for your solution proposal for SeND-based SAVI. I like this because of its simplicity. Also, it fully complies to the charter, so no show-stopper in that regard. I have three comments. Of those, two apply not just to SeND-based SAVI, but also to plain-ND SAVI: - Your proposal binds IP addresses to layer-2 addresses and optionally to additional layer-2 properties such as a switch port. Yet checking a layer-2 address may actually no longer be necessary once you check a switch port. This leads to the more general question of which "lower-layer binding anchor" IP addresses should be bound to. Since this question applies to SAVI in general, not just the SeND- based variant, I will open a separate mailing list thread for this. - You are using the terms "local traffic" and "transit traffic" to differentiate between, respectively, traffic that should be validated and traffic that should not be. Introducing special terms for this is a very good idea. But perhaps we should re-word to avoid misunderstandings. A situation where the term "local traffic" could be misunderstood is this: A host addresses a packet to a neighbor, but sends it to the local router instead of sending it directly to the neighbor. One would intuitively consider this "local traffic", but SAVI should still not validate the packet when forwarded by the router. How about "first-hop traffic" and "forwarded traffic"? Or perhaps someone has a better idea? - This brings me to another general question: How does a SAVI device distinguish first-hop traffic from forwarded traffic. I see two basic approaches: (1) Based on whether or not a packet's source address is from an on-link subnet prefix; or (2) based on whether or not the sending node is an authorized router. Your proposal uses both approaches simultaneously, and I think that is perfectly feasible if SeND is available. With plain ND, however, approach (2) would be less elegant since it would require manual configuration. We should discuss which approach is best for plain-ND SAVI, and which is best for SeND-based SAVI. I will open up another mailing list tread for this as well. Cheers, - Christian From christian.vogt@nomadiclab.com Thu Oct 30 14:44:21 2008 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 E2BE43A6B54 for ; Thu, 30 Oct 2008 14:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 q-PM7FZAf7W7 for ; Thu, 30 Oct 2008 14:44:21 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id C3DE53A6B57 for ; Thu, 30 Oct 2008 14:44:20 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 239481EF130; Thu, 30 Oct 2008 23:44:18 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id E24B01EF12C; Thu, 30 Oct 2008 23:44:17 +0200 (EET) Message-Id: From: Christian Vogt To: SAVI Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 30 Oct 2008 23:44:17 +0200 X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV using ClamSMTP Subject: [savi] Lower-Layer Binding Anchors 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, 30 Oct 2008 21:44:22 -0000 Folks, since our charter requires SAVI to not change hosts, a SAVI device will necessarily have to bind IP addresses to a property of layers below IP. This is because, in the absence of host changes, properties of lower layers are the only reasonably trustworthy information about a packet sender that shows up in all packets. The question hence is which lower-layer properties, or lower-layer "binding anchors", are most appropriate for this purpose. In the design taxonomy [1] that Bill and I presented in Dublin, we identified two suitable lower-layer binding anchors: link-layer addresses and switch ports. The design taxonomy also includes an analysis of which challenging situations (mobility, multi-homing, etc.) each binding anchor can handle. I would like to take this as a basis for a discussion with you on which binding anchor, or which combination, you folks deem more appropriate. One possible approach would be to define a set of possible binding anchors, and leave it up to the administrator to choose one or more of them. We should, of course, explain the pros and cons of the different binding anchors. And we could define a default setup. - Christian [1] http://www.ietf.org/proceedings/08jul/slides/savi-2.pdf From christian.vogt@nomadiclab.com Thu Oct 30 14:45:46 2008 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 581613A6B54 for ; Thu, 30 Oct 2008 14:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 vCjR97fGCbQ5 for ; Thu, 30 Oct 2008 14:45:45 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 688AC3A68D0 for ; Thu, 30 Oct 2008 14:45:29 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B4B111EF130; Thu, 30 Oct 2008 23:45:26 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 479DA1EF12C; Thu, 30 Oct 2008 23:45:26 +0200 (EET) Message-Id: <29B0AB6A-A250-427F-BFBB-AF63D405D633@nomadiclab.com> From: Christian Vogt To: SAVI Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 30 Oct 2008 23:45:25 +0200 X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV using ClamSMTP Subject: [savi] Identifying First-Hop Vs. Forwarded Traffic 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, 30 Oct 2008 21:45:46 -0000 We have agreed that SAVI should be complementary to ingress filtering, and not substitute it. This implies that SAVI should not validate packets that are forwarded by routers. Thankfully, this makes the design of SAVI simpler. But it requires us to find a way for SAVI to distinguish first-hop traffic from forwarded traffic (where "first-hop traffic" is transmitted by the originating host, and "forwarded traffic" is relayed by a router). I would like to open a discussion about the alternatives for achieving such traffic differentiation. Which techniques are possible, and which are the ones we prefer? As for myself, I see two possible approaches to distinguish between first-hop traffic and forwarded traffic: (1) Based on whether or not a packet's source address is from an on-link subnet prefix. (2) Based on whether or not the sending node is an authorized router. Both approaches have pros and cons. An advantage of approach (1) is that a SAVI device can automatically detect the set of on-link subnet prefixes by simply listening to Router Advertisement messages. With approach (2), similar auto-configuration is possible only with SeND because a router can then be securely identified based on its verifiable Router Advertisement messages. There is no way for a SAVI device to automatically and securely identify a router if plain ND is used. Approach (2) therefore requires pre-configuration of SAVI devices with information about local routers if plain ND is used. On the other hand, a disadvantage of approach (1) is that SAVI may erroneously validate forwarded packets with the consequence of false drops. This happens when a host sends a packet to a neighbor via the local router instead of sending it to the neighbor directly. The packet is then dropped when forwarded by the local router. With approach (2), the SAVI device would not validate, and hence not drop, the packet given that it is coming from the router. This issue with approach (1) can be mitigated if local routers use Redirect messages to enforce direct neighbor-to-neighbor communications. One conclusion from the above could be that approach (2) should only be used when SeND is available. And in such a case, approach (1) could be omitted. This would mean that, with plain ND, approach (1) would be used exclusively. What do you folks think about this? - Christian From pekkas@netcore.fi Thu Oct 30 23:24:57 2008 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 3BA613A67CC for ; Thu, 30 Oct 2008 23:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 S2efVLFqPJq0 for ; Thu, 30 Oct 2008 23:24:56 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 0ED8F3A67C0 for ; Thu, 30 Oct 2008 23:24:55 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m9V6OcxZ022847; Fri, 31 Oct 2008 08:24:38 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m9V6ObvP022844; Fri, 31 Oct 2008 08:24:37 +0200 Date: Fri, 31 Oct 2008 08:24:37 +0200 (EET) From: Pekka Savola To: Christian Vogt In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.94/8546/Fri Oct 31 03:39:08 2008 on otso.netcore.fi X-Virus-Status: Clean Cc: SAVI Mailing List Subject: Re: [savi] Lower-Layer Binding Anchors 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, 31 Oct 2008 06:24:57 -0000 On Thu, 30 Oct 2008, Christian Vogt wrote: > since our charter requires SAVI to not change hosts, a SAVI device will > necessarily have to bind IP addresses to a property of layers below IP. > This is because, in the absence of host changes, properties of lower > layers are the only reasonably trustworthy information about a packet > sender that shows up in all packets. The question hence is which > lower-layer properties, or lower-layer "binding anchors", are most > appropriate for this purpose. If lower-layer address is chosen, we assume that the lower-layer address spoofability is prevented, yes? (E.g. using MAC address locking in switches). Usually that is not done by default however, and doing so is challenging in many environments (e.g. a virtual server or a blade server connected to a switch port, having 20 or 30 MAC addresses in one extreme; office network with roaming laptops in another). Would port-based be a more widely applicable (default) solution? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From pekkas@netcore.fi Thu Oct 30 23:38:37 2008 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 2EC153A6857 for ; Thu, 30 Oct 2008 23:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 VOQ9GDC3gLCx for ; Thu, 30 Oct 2008 23:38:36 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id ED3943A67FD for ; Thu, 30 Oct 2008 23:38:35 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m9V6cSOp023137; Fri, 31 Oct 2008 08:38:28 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m9V6cS8b023133; Fri, 31 Oct 2008 08:38:28 +0200 Date: Fri, 31 Oct 2008 08:38:28 +0200 (EET) From: Pekka Savola To: Christian Vogt In-Reply-To: <29B0AB6A-A250-427F-BFBB-AF63D405D633@nomadiclab.com> Message-ID: References: <29B0AB6A-A250-427F-BFBB-AF63D405D633@nomadiclab.com> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.94/8546/Fri Oct 31 03:39:08 2008 on otso.netcore.fi X-Virus-Status: Clean Cc: SAVI Mailing List Subject: Re: [savi] Identifying First-Hop Vs. Forwarded Traffic 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, 31 Oct 2008 06:38:37 -0000 On Thu, 30 Oct 2008, Christian Vogt wrote: > (1) Based on whether or not a packet's source address is from an on-link > subnet prefix. > > (2) Based on whether or not the sending node is an authorized router. > > Both approaches have pros and cons. An advantage of approach (1) is > that a SAVI device can automatically detect the set of on-link subnet > prefixes by simply listening to Router Advertisement messages. Note that as both IPv4 and IPv6 need to be covered (1) would not be that simple for IPv4. Additionally for v6, the system might need to snoop DHCPv6 traffic (in case RAs are not used to advertise onlink prefixes?), and I guess there would also need to be a provision for manual configuration. Some mechanisms in ethernet switches already require identifying ports which attach the routers (e.g. IGMP snooping) or that are excluded from automatic checks (e.g. DHCP snooping, ARP inspection). Maybe this would be a third alternative. This is slightly complicated in a high-availability scenario like follows: router1 --- switch1 --- switch2 --- router2 | | hosts hosts .. to cover for high-availability, switch1 would also need to be configured to have the switch1-switch2 as a router port. As such this kind of port-based checking has its own limitations or would need to be used as a last resort rule (allow if there is no specific binding). Another possibility could be to identify forwarded traffic based on a set of source MAC addresses (and/or ports); while a router may use multiple MAC addresses for forwarding (e.g. when VRRP is used), it usually uses a relatively small number of them. If the scenario is such that MAC address spoofing is prevented, this could also provide a method to distinguish traffic. In all these cases the issue is if the router ports/MAC addresses would need to be automatically discovered. This might be a challenge (FWIW, for multicast router ports, RFC 4286 already specified a solution, though I'm not sure if anyone has implemented it). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From zhangdong_rh@huaweisymantec.com Fri Oct 31 00:08:35 2008 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 D8E003A68C2 for ; Fri, 31 Oct 2008 00:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.246 X-Spam-Level: ** X-Spam-Status: No, score=2.246 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_GB2312=1.345] 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 1pEAtn763Bmn for ; Fri, 31 Oct 2008 00:08:35 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id 1A4333A68B5 for ; Fri, 31 Oct 2008 00:08:35 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0K9L00HAOD664K40@hstga02-in.huaweisymantec.com> for savi@ietf.org; Fri, 31 Oct 2008 15:08:32 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0K9L0090VD65G510@hstml02-in.huaweisymantec.com> for savi@ietf.org; Fri, 31 Oct 2008 15:08:30 +0800 (CST) Received: from [10.27.141.13] by hstml02-in.huaweisymantec.com (mshttpd); Fri, 31 Oct 2008 15:08:29 +0800 From: ZhangDong To: Christian Vogt Message-id: Date: Fri, 31 Oct 2008 15:08:29 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: References: Cc: SAVI Mailing List Subject: [savi] =?gb2312?b?u9i4tDogIExvd2VyLUxheWVyIEJpbmRpbmcgQW5jaG9y?= =?gb2312?b?cw==?= 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, 31 Oct 2008 07:08:36 -0000 > In the design taxonomy [1] that Bill and I presented in Dublin, we > identified two suitable lower-layer binding anchors: link-layer > addresses and switch ports. I do not think link-layer address cannot be spoofed. One important thing is that we must guarantee reliability and reality of the source information(e.g. link-layer address) which the SAVI device obtains for binding. This is the premise of binding. Dong Zhang From marcelo@it.uc3m.es Fri Oct 31 01:40:14 2008 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 0082C3A6B83 for ; Fri, 31 Oct 2008 01:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=1.748, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 LLzJF3N86Chs for ; Fri, 31 Oct 2008 01:40:13 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 137543A6BB7 for ; Fri, 31 Oct 2008 01:40:13 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (110.pool85-53-133.dynamic.orange.es [85.53.133.110])by smtp03.uc3m.es (Postfix) with ESMTP id 6A2F56ADE99; Fri, 31 Oct 2008 09:40:10 +0100 (CET) Message-ID: <490AC469.7060707@it.uc3m.es> Date: Fri, 31 Oct 2008 09:40:09 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Christian Vogt References: <951708DA-D220-4EA0-BFD5-47564DA9EF7B@nomadiclab.com> In-Reply-To: <951708DA-D220-4EA0-BFD5-47564DA9EF7B@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-13.5871 TC:1F TRN:22 TV:5.5.1026(16250.004) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: SAVI Mailing List Subject: Re: [savi] Discussion Summary: SAVI's Basic Solution Approach 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, 31 Oct 2008 08:40:14 -0000 makes sense to me thanks, marcelo Christian Vogt escribió: > Folks, > > thanks for a good discussion about the basic solution approach that SAVI > should take. I think we reached more than just "rough" consensus on > that we should follow two parallel tracks: a non-cryptographic base > SAVI protocol, which will rely on nothing more but ARP/ND/DHCP, and a > cryptographic SAVI extension, which will take advantage of SeND in > networks where this is deployed. We also reinforced that the charter > requirements are not debatable -- i.e., no host changes, no special > protocols. Finally, we agreed with our area director that SAVI should > complement, but not substitute, ingress filtering. > > Time to move on to more specific questions then. I will identify two of > those in separate emails. > > - Christian, for Bill and Christian > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From marcelo@it.uc3m.es Fri Oct 31 01:52:31 2008 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 41B983A67A4 for ; Fri, 31 Oct 2008 01:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=1.457, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 KDVZiLuiL-Vq for ; Fri, 31 Oct 2008 01:52:30 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 062E43A69AA for ; Fri, 31 Oct 2008 01:52:29 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (110.pool85-53-133.dynamic.orange.es [85.53.133.110])by smtp03.uc3m.es (Postfix) with ESMTP id 262BB6AE115; Fri, 31 Oct 2008 09:52:25 +0100 (CET) Message-ID: <490AC747.90004@it.uc3m.es> Date: Fri, 31 Oct 2008 09:52:23 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Christian Vogt References: <490498C5.3080706@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-32.4312 TC:1F TRN:65 TV:5.5.1026(16250.004) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: SAVI Mailing List Subject: Re: [savi] Review of draft-bagnulo-savi-send-00 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2008 08:52:31 -0000 Hi Chrsitian, thanks for the comments, see replies below... Christian Vogt escribió: > > marcelo bagnulo braun wrote: > >> I have submitted a draft describing how to build a SAVI solution using >> the SeND protocol without any change to the hosts nor to the SeND >> protocol. I think the resulting security level is pretty good. >> >> Comments would be appreciated. > > > > Hi Marcelo, > > thanks for your solution proposal for SeND-based SAVI. I like this > because of its simplicity. Also, it fully complies to the charter, so > no show-stopper in that regard. I have three comments. Of those, two > apply not just to SeND-based SAVI, but also to plain-ND SAVI: > > - Your proposal binds IP addresses to layer-2 addresses and optionally > to additional layer-2 properties such as a switch port. Yet > checking a layer-2 address may actually no longer be necessary once > you check a switch port. right but otoh, binding the the layer 2 address is what SAVI _does_ right? So it would be a bit unnatural to simply use the MAC address information just as a random set of bits to be signed so that the CGA holder can prove his identify... more when the MAC address is somehow related to all the SAVI approach So, i agree that you checking the mac address may not be needed, but also, it is the only think you are sure you can bind the IP address when you are using SeND in all the cases. So, in any case, you must always check the signature to verify CGA ownership. Once you have made this verification, if you don't have any other more relevant layer-2 information to bind the IP address to, you need to use the layer 2 address. If you do have, you can ignore it (once you have verified it) > This leads to the more general question of > which "lower-layer binding anchor" IP addresses should be bound to. > Since this question applies to SAVI in general, not just the SeND- > based variant, I will open a separate mailing list thread for this. > > - You are using the terms "local traffic" and "transit traffic" to > differentiate between, respectively, traffic that should be > validated and traffic that should not be. Introducing special terms > for this is a very good idea. But perhaps we should re-word to > avoid misunderstandings. A situation where the term "local traffic" > could be misunderstood is this: A host addresses a packet to a > neighbor, but sends it to the local router instead of sending it > directly to the neighbor. One would intuitively consider this > "local traffic", but SAVI should still not validate the packet when > forwarded by the router. right but it is a bit corner case, right? > How about "first-hop traffic" and > "forwarded traffic"? Or perhaps someone has a better idea? > well, the traffic that a host sends to a router is forwarded traffic, since the router needs to forward it. the problem with short names is that you can always read to much into them :-) I am ok with any name we choose, cause the good thing about short names is that most of the times you can interpret them correctly also regards, marcelo > - This brings me to another general question: How does a SAVI device > distinguish first-hop traffic from forwarded traffic. I see two > basic approaches: (1) Based on whether or not a packet's source > address is from an on-link subnet prefix; or (2) based on whether or > not the sending node is an authorized router. Your proposal uses > both approaches simultaneously, and I think that is perfectly > feasible if SeND is available. With plain ND, however, approach (2) > would be less elegant since it would require manual configuration. > We should discuss which approach is best for plain-ND SAVI, and > which is best for SeND-based SAVI. I will open up another mailing > list tread for this as well. > > Cheers, > - Christian > > > From marcelo@it.uc3m.es Fri Oct 31 02:11:03 2008 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 D14273A6868 for ; Fri, 31 Oct 2008 02:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=1.249, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 pReGBs+gCLGG for ; Fri, 31 Oct 2008 02:11:02 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 5002D3A682B for ; Fri, 31 Oct 2008 02:11:02 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [85.53.133.110])by smtp01.uc3m.es (Postfix) with ESMTP id 1AE11AC94AC; Fri, 31 Oct 2008 10:10:58 +0100 (CET) Message-ID: <490ACBA1.8030503@it.uc3m.es> Date: Fri, 31 Oct 2008 10:10:57 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Christian Vogt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-22.7224 TC:1F TRN:64 TV:5.5.1026(16250.004) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: SAVI Mailing List Subject: Re: [savi] Lower-Layer Binding Anchors 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, 31 Oct 2008 09:11:03 -0000 Hi Christian, My view on this is that whatever we do, if we bind the IP address to the layer 2 information, we are improving the security. If we simply bind it to the MAC address and not further checks are applied, we are making a very limited increment, but still is better than nothing in an environment where you are very constrained, cause essentially you are assuming no layer 2 security, no configurnation of MAC address enforcement no port switching and so on. If we have more capable layer 2, we can provide much better security so SAVI would improve the security considerably. My point is that depending the scenario you are asuming and the constraints about not being able to mae changes in the host, then you may not have many options more below... Christian Vogt escribió: > > One possible approach would be to define a set of possible binding > anchors, and leave it up to the administrator to choose one or more of > them. We should, of course, explain the pros and cons of the different > binding anchors. And we could define a default setup. > yes, and i think draft-baker-sava-implementation has a very good starting poitn for this: section 2.1. Trust anchors of draft-baker-sava-implementation reads: In short, the implementation approach requires neighboring devices to associate a layer 3 entity addressed with an IPv6 address with a layer 2 entity. The identification of the layer 2 entity may take a number of forms: o On a traditional Ethernet or for a host or router attached to a switched Ethernet, the only real option is association with the MAC Address. o The switch, however, may be able to associate the IPv6 address with a switch port if it knows that only one host is attached to the port. o In a wireless network, there are often layer 2 security associations between neighboring devices, and the address can be associated with that security association. o In a Cable Modem network, the address may be associated with the combination of a MAC address and a customer relationship. o In a classical DSL network, it may be associated with an ATM Virtual Channel, or a PPPoE or L2TP Session ID. o In some cases, an IP/IP tunnel, an MPLS LSP, or similar tunneling technology is taken to a single system. In such cases, local address validation can be applied to the use of the tunnel. The key is to have a solid understanding of o what identifies a neighbor in the context: a MAC Address, a switch port, an ATM VC, or whatever, o what addresses one's neighbor is in fact using, and o to limit what one accepts from the neighbor as so identified to that which the neighbor is legitimately using. One could argue that this runs counter to the Robustness Principle, which is stated in RFC 793 as "be conservative in what you do, be liberal in what you accept from others." In fact, it follows the Robustness Principle, but adds the Russian proverb made famous in the west by Ronald Reagan: "Trust, but verify". Now, with respect to the defaul case, i am not sure you can do that I mean, is not that there is a defaul layer 2 out there IMHO, what we can do is a list (similar to the one Fred has) and explain for each case what can be achieved Regards, marcelo > - Christian > > > [1] http://www.ietf.org/proceedings/08jul/slides/savi-2.pdf > > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From marcelo@it.uc3m.es Fri Oct 31 02:17:48 2008 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 CDF5F3A6BC7 for ; Fri, 31 Oct 2008 02:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=1.093, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 TgenNaHpZH1O for ; Fri, 31 Oct 2008 02:17:48 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id BADB73A6BBF for ; Fri, 31 Oct 2008 02:17:47 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (110.pool85-53-133.dynamic.orange.es [85.53.133.110])by smtp02.uc3m.es (Postfix) with ESMTP id 7BFB65C8891; Fri, 31 Oct 2008 10:17:44 +0100 (CET) Message-ID: <490ACD36.4000700@it.uc3m.es> Date: Fri, 31 Oct 2008 10:17:42 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Pekka Savola References: <29B0AB6A-A250-427F-BFBB-AF63D405D633@nomadiclab.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-22.0295 TC:1F TRN:43 TV:5.5.1026(16250.004) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Christian Vogt , SAVI Mailing List Subject: Re: [savi] Identifying First-Hop Vs. Forwarded Traffic 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, 31 Oct 2008 09:17:48 -0000 Pekka Savola escribió: > On Thu, 30 Oct 2008, Christian Vogt wrote: >> (1) Based on whether or not a packet's source address is from an on-link >> subnet prefix. >> >> (2) Based on whether or not the sending node is an authorized router. >> >> Both approaches have pros and cons. An advantage of approach (1) is >> that a SAVI device can automatically detect the set of on-link subnet >> prefixes by simply listening to Router Advertisement messages. > > Note that as both IPv4 and IPv6 need to be covered (1) would not be > that simple for IPv4. Why not? I mean, i understand that in general, any device running IP should know what are the prefixes that are directly connected to its interfaces, so it can directly deliver the datagrams, right? I understand that the next hop is always directly connects to the sending interface, so both the host and the router shouls be aware of the prefix used in the source address afaiu what am missing? > Additionally for v6, the system might need to snoop DHCPv6 traffic (in > case RAs are not used to advertise onlink prefixes?), and I guess > there would also need to be a provision for manual configuration. > > Some mechanisms in ethernet switches already require identifying ports > which attach the routers (e.g. IGMP snooping) or that are excluded > from automatic checks (e.g. DHCP snooping, ARP inspection). Maybe > this would be a third alternative. This is slightly complicated in a > high-availability scenario like follows: > > router1 --- switch1 --- switch2 --- router2 > | | > hosts hosts > > .. to cover for high-availability, switch1 would also need to be > configured to have the switch1-switch2 as a router port. As such this > kind of port-based checking has its own limitations or would need to > be used as a last resort rule (allow if there is no specific binding). > > Another possibility could be to identify forwarded traffic based on a > set of source MAC addresses (and/or ports); while a router may use > multiple MAC addresses for forwarding (e.g. when VRRP is used), it > usually uses a relatively small number of them. If the scenario is > such that MAC address spoofing is prevented, this could also provide a > method to distinguish traffic. > > In all these cases the issue is if the router ports/MAC addresses > would need to be automatically discovered. This might be a challenge > (FWIW, for multicast router ports, RFC 4286 already specified a > solution, though I'm not sure if anyone has implemented it). > From pekkas@netcore.fi Fri Oct 31 03:21:51 2008 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 918143A69AA for ; Fri, 31 Oct 2008 03:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypgLiyTBlsHm for ; Fri, 31 Oct 2008 03:21:50 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 762D93A67E1 for ; Fri, 31 Oct 2008 03:21:50 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m9VALiDg027623; Fri, 31 Oct 2008 12:21:44 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m9VALhOC027619; Fri, 31 Oct 2008 12:21:43 +0200 Date: Fri, 31 Oct 2008 12:21:43 +0200 (EET) From: Pekka Savola To: marcelo bagnulo braun In-Reply-To: <490ACD36.4000700@it.uc3m.es> Message-ID: References: <29B0AB6A-A250-427F-BFBB-AF63D405D633@nomadiclab.com> <490ACD36.4000700@it.uc3m.es> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.94/8546/Fri Oct 31 03:39:08 2008 on otso.netcore.fi X-Virus-Status: Clean Cc: Christian Vogt , SAVI Mailing List Subject: Re: [savi] Identifying First-Hop Vs. Forwarded Traffic 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, 31 Oct 2008 10:21:51 -0000 On Fri, 31 Oct 2008, marcelo bagnulo braun wrote: >> Note that as both IPv4 and IPv6 need to be covered (1) would not be that >> simple for IPv4. > Why not? > I mean, i understand that in general, any device running IP should know what > are the prefixes that are directly connected to its interfaces, so it can > directly deliver the datagrams, right? If an ethernet switch is operating in layer 2 only, it doesn't know anything about IP prefixes on the link. In IPv4 specifically, there are no RA's that could be snooped. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From marcelo@it.uc3m.es Fri Oct 31 03:33:18 2008 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 188813A6BD3 for ; Fri, 31 Oct 2008 03:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.791 X-Spam-Level: X-Spam-Status: No, score=-2.791 tagged_above=-999 required=5 tests=[AWL=0.971, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 rp1osEt+-g9S for ; Fri, 31 Oct 2008 03:33:17 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 39AAF3A6B8E for ; Fri, 31 Oct 2008 03:33:16 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [85.53.133.110])by smtp01.uc3m.es (Postfix) with ESMTP id CBC11AC93AC; Fri, 31 Oct 2008 11:33:12 +0100 (CET) Message-ID: <490ADEE7.6080505@it.uc3m.es> Date: Fri, 31 Oct 2008 11:33:11 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Pekka Savola References: <29B0AB6A-A250-427F-BFBB-AF63D405D633@nomadiclab.com> <490ACD36.4000700@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-10.7708 TC:1F TRN:30 TV:5.5.1026(16250.006) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Christian Vogt , SAVI Mailing List Subject: Re: [savi] Identifying First-Hop Vs. Forwarded Traffic 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, 31 Oct 2008 10:33:18 -0000 Pekka Savola escribió: > On Fri, 31 Oct 2008, marcelo bagnulo braun wrote: >>> Note that as both IPv4 and IPv6 need to be covered (1) would not be >>> that >>> simple for IPv4. >> Why not? >> I mean, i understand that in general, any device running IP should >> know what are the prefixes that are directly connected to its >> interfaces, so it can directly deliver the datagrams, right? > > If an ethernet switch is operating in layer 2 only, it doesn't know > anything about IP prefixes on the link. In IPv4 specifically, there > are no RA's that could be snooped. > Right The SAVI function can be implemented in routers or in switches. In the case of routers we can assume that the routers will know the on link prefixes for all their interfaces. In the case of switches, this information is not available and needs to be configured. I don't think this is a big problem. I mean, we have a very constrained environment here. We cannot change the hosts, we cannot make new protocols. We must limit ourselves to include a new functionality in the switch or in the router. It would be great if we don't have to configure the SAVI device, but is think it is reasonable to accept some that configuration is needed e.g. configuring the on-link prefixes for IPv4, makes sense? Regards, marcelo From christian.vogt@nomadiclab.com Fri Oct 31 04:48:26 2008 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 A0DEE3A67FA for ; Fri, 31 Oct 2008 04:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 7Wye+mgRSqon for ; Fri, 31 Oct 2008 04:48:25 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 716053A67F6 for ; Fri, 31 Oct 2008 04:48:25 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 97C6E1EF130; Fri, 31 Oct 2008 13:48:22 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 29ED21EF11A; Fri, 31 Oct 2008 13:48:22 +0200 (EET) Message-Id: <4FFCABE7-BB56-4EE2-8F79-4225A2DC358D@nomadiclab.com> From: Christian Vogt To: Marcelo Bagnulo Braun , Pekka Savola In-Reply-To: <490ADEE7.6080505@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 31 Oct 2008 13:48:21 +0200 References: <29B0AB6A-A250-427F-BFBB-AF63D405D633@nomadiclab.com> <490ACD36.4000700@it.uc3m.es> <490ADEE7.6080505@it.uc3m.es> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV using ClamSMTP Cc: SAVI Mailing List Subject: Re: [savi] Identifying First-Hop Vs. Forwarded Traffic 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, 31 Oct 2008 11:48:26 -0000 Marcelo and Pekka - > I mean, we have a very constrained environment here. We cannot change > the hosts, we cannot make new protocols. We must limit ourselves to > include a new functionality in the switch or in the router. It would > be > great if we don't have to configure the SAVI device, but is think it > is > reasonable to accept some that configuration is needed e.g. > configuring > the on-link prefixes for IPv4, makes sense? I agree that we have to make compromises. Manual configuration seems to be unavoidable in some cases. To summarize your and Pekka's comments: Of the two approaches to distinguish first-hop traffic from forwarded traffic... (1) Based on whether or not a packet's source address is from an on-link subnet prefix. (2) Based on whether or not the sending node is an authorized router. ...both are feasible, but neither enables complete auto-configuration of SAVI devices in all cases. For auto-configuration in approach (1), we could: - rely on routing information if SAVI is colocated with a router, - snoop Router Advertisement messages (and DHCP messages) in IPv6. For auto-configuration in approach (2), we could: - rely on routing information if SAVI is colocated with a router and if the routing information is authenticated, - snoop IGMP or Router Advertisement messages if the messages are authenticated. In either case, the property of being an authorized router could be associated with a router's MAC address, or with a switch port to which the router connects. The same applies if a SAVI device is manually configured. It is worthwhile emphasizing the following important difference between approaches (1) and (2): Approach (1) is inherently secure because it is an "opt-in" approach: The injection of a bogus on-link subnet prefix does not reduce the strictness of SAVI devices; it can at most increase the strictness. Approach (2), on the other hand, requires authentication because it is an "opt-out" approach: If an attacker manages to convince a SAVI device that it is an authorized router, the SAVI device would deactivate source address validation for the packets sent by the attacker. This can be protected against only through authentication of authorized routers. This difference between approaches (1) and (2) has an impact on the applicability of SAVI device auto-configuration. The need for authentication in approach (2) is a deployment hurdle in my opinion, so I would argue that approach (1) should be preferred for auto-configuration. The difference between approaches (1) and (2) has no impact on manual configuration of SAVI devices because manually configured information necessarily needs to be trusted. - Christian From christian.vogt@nomadiclab.com Fri Oct 31 05:08:08 2008 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 EB8503A6359 for ; Fri, 31 Oct 2008 05:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 Xbu8EfZLwPUQ for ; Fri, 31 Oct 2008 05:08:08 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 0F0113A68E8 for ; Fri, 31 Oct 2008 05:08:08 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 444251EF130; Fri, 31 Oct 2008 14:08:06 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0C72B1EF11A; Fri, 31 Oct 2008 14:08:06 +0200 (EET) Message-Id: <57B1F2B3-5FB7-4406-A170-28849028EEF3@nomadiclab.com> From: Christian Vogt To: marcelo bagnulo braun In-Reply-To: <490ACBA1.8030503@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 31 Oct 2008 14:08:05 +0200 References: <490ACBA1.8030503@it.uc3m.es> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV using ClamSMTP Cc: SAVI Mailing List Subject: Re: [savi] Lower-Layer Binding Anchors 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, 31 Oct 2008 12:08:09 -0000 On Oct 31, 2008, marcelo bagnulo braun wrote: > My view on this is that whatever we do, if we bind the IP address to > the layer 2 information, we are improving the security. > If we simply bind it to the MAC address and not further checks are > applied, we are making a very limited increment, but still is better > than nothing in an environment where you are very constrained, cause > essentially you are assuming no layer 2 security, no configurnation > of MAC address enforcement no port switching and so on. > If we have more capable layer 2, we can provide much better security > so SAVI would improve the security considerably. Yes, we are on the same page. [...] > Now, with respect to the defaul case, i am not sure you can do that > I mean, is not that there is a defaul layer 2 out there But since the SAVI charter wants us to focus on Ethernet, we may use MAC addresses as a default. Having said that, I agree that we should also come up with a list of alternatives, along with the benefits and shortfalls of each. - Christian From marcelo@it.uc3m.es Fri Oct 31 05:39:24 2008 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 8348828C2EB for ; Fri, 31 Oct 2008 05:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.967 X-Spam-Level: X-Spam-Status: No, score=-2.967 tagged_above=-999 required=5 tests=[AWL=0.795, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 T1mGwqDNmChL for ; Fri, 31 Oct 2008 05:39:23 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 4913E28C39B for ; Fri, 31 Oct 2008 05:39:22 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (110.pool85-53-133.dynamic.orange.es [85.53.133.110])by smtp02.uc3m.es (Postfix) with ESMTP id E9EB15C8D0F; Fri, 31 Oct 2008 13:39:19 +0100 (CET) Message-ID: <490AFC77.5000601@it.uc3m.es> Date: Fri, 31 Oct 2008 13:39:19 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Christian Vogt References: <29B0AB6A-A250-427F-BFBB-AF63D405D633@nomadiclab.com> <490ACD36.4000700@it.uc3m.es> <490ADEE7.6080505@it.uc3m.es> <4FFCABE7-BB56-4EE2-8F79-4225A2DC358D@nomadiclab.com> In-Reply-To: <4FFCABE7-BB56-4EE2-8F79-4225A2DC358D@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-18.5233 TC:1F TRN:45 TV:5.5.1026(16250.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: SAVI Mailing List Subject: Re: [savi] Identifying First-Hop Vs. Forwarded Traffic 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, 31 Oct 2008 12:39:24 -0000 Christian Vogt escribió: > Marcelo and Pekka - > >> I mean, we have a very constrained environment here. We cannot change >> the hosts, we cannot make new protocols. We must limit ourselves to >> include a new functionality in the switch or in the router. It would be >> great if we don't have to configure the SAVI device, but is think it is >> reasonable to accept some that configuration is needed e.g. configuring >> the on-link prefixes for IPv4, makes sense? > > I agree that we have to make compromises. Manual configuration seems to > be unavoidable in some cases. > > To summarize your and Pekka's comments: Of the two approaches to > distinguish first-hop traffic from forwarded traffic... > > (1) Based on whether or not a packet's source address is from an on-link > subnet prefix. > > (2) Based on whether or not the sending node is an authorized router. > > ...both are feasible, but neither enables complete auto-configuration of > SAVI devices in all cases. > > For auto-configuration in approach (1), we could: > > - rely on routing information if SAVI is colocated with a router, well, it doesn't need much routing information, only on link prefixes (i.e. what any device with layer 3 knows) > > - snoop Router Advertisement messages (and DHCP messages) in IPv6. > > For auto-configuration in approach (2), we could: > > - rely on routing information if SAVI is colocated with a router and if > the routing information is authenticated, well, as i say before, you don't need routing information. What you need to to know what are the onlink prefixes. Normally any layer 3 device knows that, sicne when you configure an address and a mask, you are configuring this information. So, i am not sure how much authentication we need here > - snoop IGMP or Router Advertisement messages if the messages are > authenticated. > > In either case, the property of being an authorized router could be > associated with a router's MAC address, or with a switch port to which > the router connects. The same applies if a SAVI device is manually > configured. > > It is worthwhile emphasizing the following important difference between > approaches (1) and (2): Approach (1) is inherently secure because it is > an "opt-in" approach: The injection of a bogus on-link subnet prefix > does not reduce the strictness of SAVI devices; it can at most increase > the strictness. not sure what you mean... If an attacker manages to convince the savi device that a given prefix is onlink, then the attacker can send packets using that source address, which is one of the things we want to prevent, right? So, i am not sure i agree with the assertion that this is inherently secure... what am i missing? > Approach (2), on the other hand, requires > authentication because it is an "opt-out" approach: If an attacker > manages to convince a SAVI device that it is an authorized router, the > SAVI device would deactivate source address validation for the packets > sent by the attacker. right, this case is worse, cause the attacker can send packets from any prefix. but we are not taking ingress filtering into account, right? Ingress filtering could actually solve this, right? > This can be protected against only through > authentication of authorized routers. > > This difference between approaches (1) and (2) has an impact on the > applicability of SAVI device auto-configuration. The need for > authentication in approach (2) is a deployment hurdle in my opinion, so doesn't ingress filtering mitigates this? regards, marcelo > I would argue that approach (1) should be preferred for > auto-configuration. The difference between approaches (1) and (2) has > no impact on manual configuration of SAVI devices because manually > configured information necessarily needs to be trusted. > > - Christian > > > From christian.vogt@nomadiclab.com Fri Oct 31 06:28:09 2008 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 2D9D33A6B4C for ; Fri, 31 Oct 2008 06:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 9yKxvX87dSaH for ; Fri, 31 Oct 2008 06:28:08 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 3BE3B3A696B for ; Fri, 31 Oct 2008 06:28:08 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0D4B31EF9DD; Fri, 31 Oct 2008 15:28:06 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 9A83C1EF9DB; Fri, 31 Oct 2008 15:28:05 +0200 (EET) Message-Id: From: Christian Vogt To: marcelo bagnulo braun In-Reply-To: <490AFC77.5000601@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 31 Oct 2008 15:28:05 +0200 References: <29B0AB6A-A250-427F-BFBB-AF63D405D633@nomadiclab.com> <490ACD36.4000700@it.uc3m.es> <490ADEE7.6080505@it.uc3m.es> <4FFCABE7-BB56-4EE2-8F79-4225A2DC358D@nomadiclab.com> <490AFC77.5000601@it.uc3m.es> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV using ClamSMTP Cc: SAVI Mailing List Subject: Re: [savi] Identifying First-Hop Vs. Forwarded Traffic 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, 31 Oct 2008 13:28:09 -0000 Marcelo - >> It is worthwhile emphasizing the following important difference >> between >> approaches (1) and (2): Approach (1) is inherently secure because >> it is >> an "opt-in" approach: The injection of a bogus on-link subnet prefix >> does not reduce the strictness of SAVI devices; it can at most >> increase >> the strictness. > > not sure what you mean... If an attacker manages to convince the savi > device that a given prefix is onlink, then the attacker can send > packets > using that source address, which is one of the things we want to > prevent, right? So, i am not sure i agree with the assertion that this > is inherently secure... what am i missing? The reason I am saying that approach (1) is "opt-in" is this: Before the attack, the SAVI device does not even perform any validation at all. The SAVI device starts validating only once the attacker has convinced the SAVI device that the bogus prefix is on-link. So the attack can at most increase the strictness of the SAVI device; it cannot reduce it. Of course, the attacker could still get away with an address from the bogus prefix: If the attacker configured an address from the bogus prefix using legitimate mechanisms such as ND, the SAVI device would accept this address. But I think this is acceptable because, since SAVI should be complementary to ingress filtering and not replace it, the responsibility for validating prefixes and hence detecting off-link addresses could be delegated to ingress filtering. This would mean that it would be OK for SAVI devices to accept addresses from bogus on-link prefixes, because those are just a special case of off-link prefixes. >> This difference between approaches (1) and (2) has an impact on the >> applicability of SAVI device auto-configuration. The need for >> authentication in approach (2) is a deployment hurdle in my >> opinion, so > > doesn't ingress filtering mitigates this? It mitigates it, but the validation still becomes weaker. More specifically, we should differentiate two cases: (1) no SAVI validation for any packets from a router, (2) no SAVI validation for packets with off-link source addresses from a router. In case (a), an attacker can spoof any on-link source address once it has convinced the SAVI device that it is an authorized router. This is because the SAVI device will then discontinue the validation of packets from the router, and ingress filtering won't detect the spoofing because the spoofed addresses have a correct prefix. The attacker can also spoof off-link source addresses with a prefix that appears to be topologically correct from the perspective of ingress filtering. In case (b), an attacker can spoof only off-link source addresses from prefixes that appear to be topologically correct from the perspective of ingress filtering. - Christian From christian.vogt@nomadiclab.com Fri Oct 31 06:43:19 2008 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 6A0B728C413 for ; Fri, 31 Oct 2008 06:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 5ahKDGK8Qfnn for ; Fri, 31 Oct 2008 06:43:15 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id AE86028C3FC for ; Fri, 31 Oct 2008 06:43:14 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E43701EFCDE; Fri, 31 Oct 2008 15:43:12 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 6C82D1EFCDD; Fri, 31 Oct 2008 15:43:12 +0200 (EET) Message-Id: <80FC6F68-D020-4D4F-B3A8-1EFC619C2290@nomadiclab.com> From: Christian Vogt To: Pekka Savola , ZhangDong In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 31 Oct 2008 15:43:12 +0200 References: X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV using ClamSMTP Cc: SAVI Mailing List Subject: Re: [savi] Lower-Layer Binding Anchors 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, 31 Oct 2008 13:43:19 -0000 Pekka and Zhang Dong, you are of course right that MAC addresses fail to render a secure binding anchor because they can be spoofed without much effort. But in some cases, we may have to rely on them anyway. Having said this, I agree with you that we should use a more secure binding anchor whenever possible. And this makes me reconsider what I previously wrote to Marcelo: > But since the SAVI charter wants us to focus on Ethernet, we may use > MAC addresses as a default. Perhaps it would be better to define the default as: Use switch ports when available, and MAC addresses otherwise. Or: Use MAC addresses, and switch ports in addition if available. What do you think? - Christian On Oct 31, 2008, ZhangDong wrote: > I do not think link-layer address cannot be spoofed. > One important thing is that we must guarantee reliability and > reality of the source information(e.g. link-layer address) which the > SAVI device obtains for binding. > This is the premise of binding. On Oct 31, 2008, Pekka Savola wrote: > If lower-layer address is chosen, we assume that the lower-layer > address spoofability is prevented, yes? (E.g. using MAC address > locking in switches). Usually that is not done by default however, > and doing so is challenging in many environments (e.g. a virtual > server or a blade server connected to a switch port, having 20 or 30 > MAC addresses in one extreme; office network with roaming laptops in > another). > > Would port-based be a more widely applicable (default) solution? From marcelo@it.uc3m.es Fri Oct 31 07:56:39 2008 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 1636C3A6A1F for ; Fri, 31 Oct 2008 07:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.034 X-Spam-Level: X-Spam-Status: No, score=-3.034 tagged_above=-999 required=5 tests=[AWL=0.728, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 2uJmzrADWBvt for ; Fri, 31 Oct 2008 07:56:38 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id CEB7B3A6A20 for ; Fri, 31 Oct 2008 07:56:37 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (110.pool85-53-133.dynamic.orange.es [85.53.133.110])by smtp02.uc3m.es (Postfix) with ESMTP id 529C95C9073; Fri, 31 Oct 2008 15:56:34 +0100 (CET) Message-ID: <490B1CA1.7010103@it.uc3m.es> Date: Fri, 31 Oct 2008 15:56:33 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Christian Vogt References: <29B0AB6A-A250-427F-BFBB-AF63D405D633@nomadiclab.com> <490ACD36.4000700@it.uc3m.es> <490ADEE7.6080505@it.uc3m.es> <4FFCABE7-BB56-4EE2-8F79-4225A2DC358D@nomadiclab.com> <490AFC77.5000601@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-5.1280 TC:1F TRN:46 TV:5.5.1026(16250.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: SAVI Mailing List Subject: Re: [savi] Identifying First-Hop Vs. Forwarded Traffic 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, 31 Oct 2008 14:56:39 -0000 Christian Vogt escribió: > Marcelo - > >>> It is worthwhile emphasizing the following important difference between >>> approaches (1) and (2): Approach (1) is inherently secure because >>> it is >>> an "opt-in" approach: The injection of a bogus on-link subnet prefix >>> does not reduce the strictness of SAVI devices; it can at most increase >>> the strictness. >> >> not sure what you mean... If an attacker manages to convince the savi >> device that a given prefix is onlink, then the attacker can send packets >> using that source address, which is one of the things we want to >> prevent, right? So, i am not sure i agree with the assertion that this >> is inherently secure... what am i missing? > > The reason I am saying that approach (1) is "opt-in" is this: Before > the attack, the SAVI device does not even perform any validation at all. what do you mean? AFAIU, the SAVI device by default drops all the packets except those coming with a source address containing one of the on-link prefixes. So, SAVI is perfroming validation and dropping everything. When the attacker manages to convince that one additional prefix is onlink, then this new prefix is acceptable to be used in the source address and then the savi filtering does not applies to these packets. > The SAVI device starts validating only once the attacker has convinced > the SAVI device that the bogus prefix is on-link. So the attack can at > most increase the strictness of the SAVI device; it cannot reduce it. > i don't think i understand your point. > Of course, the attacker could still get away with an address from the > bogus prefix: If the attacker configured an address from the bogus > prefix using legitimate mechanisms such as ND, the SAVI device would > accept this address. But I think this is acceptable because, since SAVI > should be complementary to ingress filtering and not replace it, the > responsibility for validating prefixes and hence detecting off-link > addresses could be delegated to ingress filtering. well, i am not sure if this is the case If we don't know which are on-link prefixes then this means that any node can send packets with any source address, since the SAVI function does not knows whether the prefix is onlink or not > This would mean that > it would be OK for SAVI devices to accept addresses from bogus on-link > prefixes, because those are just a special case of off-link prefixes. > >>> This difference between approaches (1) and (2) has an impact on the >>> applicability of SAVI device auto-configuration. The need for >>> authentication in approach (2) is a deployment hurdle in my opinion, so >> >> doesn't ingress filtering mitigates this? > > It mitigates it, but the validation still becomes weaker. More > specifically, we should differentiate two cases: > > (1) no SAVI validation for any packets from a router, > no, i don't think this is ever the case.... If the source address has the onlink prefix and it is being used by another device, then savi should drop the packets, even if they come from a router. I mean, if the CGA proof that another node is the owner of th given address, then no other node (not even a router) can send packets from that source imho > (2) no SAVI validation for packets with off-link source addresses from a > router. > i think this is the actual case Moreover, i think that ingress filtering does provides higher granularity If SAVI tells you a list of auhtorized routers, ingress filtering tells you more, ingress fitlering tells you which of these routers are able to send using which prefixes. > In case (a), an attacker can spoof any on-link source address once it > has convinced the SAVI device that it is an authorized router. This is > because the SAVI device will then discontinue the validation of packets > from the router, and ingress filtering won't detect the spoofing because > the spoofed addresses have a correct prefix. The attacker can also > spoof off-link source addresses with a prefix that appears to be > topologically correct from the perspective of ingress filtering. > > In case (b), an attacker can spoof only off-link source addresses from > prefixes that appear to be topologically correct from the perspective of > ingress filtering. > right (agree with b) Regards, marcelo > - Christian > > > From marcelo@it.uc3m.es Fri Oct 31 07:59:32 2008 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 D82EB3A6B49 for ; Fri, 31 Oct 2008 07:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.09 X-Spam-Level: X-Spam-Status: No, score=-3.09 tagged_above=-999 required=5 tests=[AWL=0.672, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 YM3zeqBsT7kA for ; Fri, 31 Oct 2008 07:59:32 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id ABABE3A6A20 for ; Fri, 31 Oct 2008 07:59:31 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (110.pool85-53-133.dynamic.orange.es [85.53.133.110])by smtp03.uc3m.es (Postfix) with ESMTP id BFCD96AE078; Fri, 31 Oct 2008 15:59:28 +0100 (CET) Message-ID: <490B1D50.5030500@it.uc3m.es> Date: Fri, 31 Oct 2008 15:59:28 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Christian Vogt References: <29B0AB6A-A250-427F-BFBB-AF63D405D633@nomadiclab.com> In-Reply-To: <29B0AB6A-A250-427F-BFBB-AF63D405D633@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-13.7540 TC:1F TRN:47 TV:5.5.1026(16250.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: SAVI Mailing List Subject: Re: [savi] Identifying First-Hop Vs. Forwarded Traffic 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, 31 Oct 2008 14:59:32 -0000 Christian Vogt escribió: > We have agreed that SAVI should be complementary to ingress filtering, > and not substitute it. This implies that SAVI should not validate > packets that are forwarded by routers. Thankfully, this makes the > design of SAVI simpler. But it requires us to find a way for SAVI to > distinguish first-hop traffic from forwarded traffic (where "first-hop > traffic" is transmitted by the originating host, and "forwarded traffic" > is relayed by a router). I would like to open a discussion about the > alternatives for achieving such traffic differentiation. Which > techniques are possible, and which are the ones we prefer? > > As for myself, I see two possible approaches to distinguish between > first-hop traffic and forwarded traffic: > > (1) Based on whether or not a packet's source address is from an on-link > subnet prefix. > > (2) Based on whether or not the sending node is an authorized router. coming back to this original question, i think that in any case we need both. I mean, we need the list of onlink prefixes, if not SAVI does not know which source addresses can be generated by onlink nodes We need the list of routers cause if not we don't know which of the directly connected devices can generate packets with off-link source addresses. I am don't see how you can build a savi solution with only one of those I don't see these as one or the other, but i think you need one _and_ the other. Regards, marcelo > > Both approaches have pros and cons. An advantage of approach (1) is > that a SAVI device can automatically detect the set of on-link subnet > prefixes by simply listening to Router Advertisement messages. With > approach (2), similar auto-configuration is possible only with SeND > because a router can then be securely identified based on its verifiable > Router Advertisement messages. There is no way for a SAVI device to > automatically and securely identify a router if plain ND is used. > Approach (2) therefore requires pre-configuration of SAVI devices with > information about local routers if plain ND is used. > > On the other hand, a disadvantage of approach (1) is that SAVI may > erroneously validate forwarded packets with the consequence of false > drops. This happens when a host sends a packet to a neighbor via the > local router instead of sending it to the neighbor directly. The packet > is then dropped when forwarded by the local router. With approach (2), > the SAVI device would not validate, and hence not drop, the packet given > that it is coming from the router. This issue with approach (1) can be > mitigated if local routers use Redirect messages to enforce direct > neighbor-to-neighbor communications. > > One conclusion from the above could be that approach (2) should only be > used when SeND is available. And in such a case, approach (1) could be > omitted. This would mean that, with plain ND, approach (1) would be > used exclusively. > > What do you folks think about this? > > - Christian > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From ietfdbh@comcast.net Wed Nov 5 09:43:24 2008 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 B8DE13A69E4 for ; Wed, 5 Nov 2008 09:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Ysds9w3I08vs for ; Wed, 5 Nov 2008 09:43:23 -0800 (PST) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id C200F3A6825 for ; Wed, 5 Nov 2008 09:43:22 -0800 (PST) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA08.westchester.pa.mail.comcast.net with comcast id bUtb1a00417dt5G58VfrPx; Wed, 05 Nov 2008 17:39:51 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA13.westchester.pa.mail.comcast.net with comcast id bVfs1a0044HwxpC3ZVfv0S; Wed, 05 Nov 2008 17:40:09 +0000 X-Authority-Analysis: v=1.0 c=1 a=SqQCI2xKtNwA:10 a=48vgC7mUAAAA:8 a=ljcgX6JHNHv-OKl-cJkA:9 a=cAfQUxZ_L1ZQuRc1x90A:7 a=LP_Vzjk0IAVngzTlorcLoysWz4gA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Christian Vogt'" , "'Pekka Savola'" , "'ZhangDong'" References: <80FC6F68-D020-4D4F-B3A8-1EFC619C2290@nomadiclab.com> Date: Wed, 5 Nov 2008 12:39:54 -0500 Message-ID: <074501c93f6d$912c1420$0500a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <80FC6F68-D020-4D4F-B3A8-1EFC619C2290@nomadiclab.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Ack7XqNVuMeC+11ARDOoiBd6wF9ouAEDnLoQ Cc: 'SAVI Mailing List' Subject: Re: [savi] Lower-Layer Binding Anchors X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2008 17:43:24 -0000 Hi, It's been a while since I participated in IEEE 802.1, but I recall them working on 802.1af(?) to provide link-layer security, and another effort (don't remember the name) to standardize a link-layer identity. If we want a more secure MAC address, could those be helpful here? Has anybody been following IEEE 802.1? David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On > Behalf Of Christian Vogt > Sent: Friday, October 31, 2008 9:43 AM > To: Pekka Savola; ZhangDong > Cc: SAVI Mailing List > Subject: Re: [savi] Lower-Layer Binding Anchors > > Pekka and Zhang Dong, > > you are of course right that MAC addresses fail to render a secure > binding anchor because they can be spoofed without much effort. But > in some cases, we may have to rely on them anyway. > > Having said this, I agree with you that we should use a more secure > binding anchor whenever possible. And this makes me > reconsider what I > previously wrote to Marcelo: > > > But since the SAVI charter wants us to focus on Ethernet, > we may use > > MAC addresses as a default. > > Perhaps it would be better to define the default as: Use > switch ports > when available, and MAC addresses otherwise. Or: Use MAC > addresses, > and switch ports in addition if available. > > What do you think? > > - Christian > > > > On Oct 31, 2008, ZhangDong wrote: > > > I do not think link-layer address cannot be spoofed. > > One important thing is that we must guarantee reliability and > > reality of the source information(e.g. link-layer address) > which the > > SAVI device obtains for binding. > > This is the premise of binding. > > > > On Oct 31, 2008, Pekka Savola wrote: > > > If lower-layer address is chosen, we assume that the lower-layer > > address spoofability is prevented, yes? (E.g. using MAC address > > locking in switches). Usually that is not done by default > however, > > and doing so is challenging in many environments (e.g. a virtual > > server or a blade server connected to a switch port, having > 20 or 30 > > MAC addresses in one extreme; office network with roaming > laptops in > > another). > > > > Would port-based be a more widely applicable (default) solution? > > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From eric.gray@ericsson.com Wed Nov 5 12:33:09 2008 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 E13E43A6915 for ; Wed, 5 Nov 2008 12:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.136 X-Spam-Level: X-Spam-Status: No, score=-6.136 tagged_above=-999 required=5 tests=[AWL=0.464, 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 LYkLrribI3pj for ; Wed, 5 Nov 2008 12:33:09 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id EC9EC3A67F8 for ; Wed, 5 Nov 2008 12:33:08 -0800 (PST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id mA5KXnaN010995; Wed, 5 Nov 2008 14:33:50 -0600 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Nov 2008 14:31:52 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Nov 2008 14:31:49 -0600 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF04138EA7@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <074501c93f6d$912c1420$0500a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [savi] Lower-Layer Binding Anchors Thread-Index: Ack7XqNVuMeC+11ARDOoiBd6wF9ouAEDnLoQAADh8qA= References: <80FC6F68-D020-4D4F-B3A8-1EFC619C2290@nomadiclab.com> <074501c93f6d$912c1420$0500a8c0@china.huawei.com> From: "Eric Gray" To: "David Harrington" , "Christian Vogt" , "Pekka Savola" , "ZhangDong" X-OriginalArrivalTime: 05 Nov 2008 20:31:52.0341 (UTC) FILETIME=[894BB450:01C93F85] Cc: SAVI Mailing List Subject: Re: [savi] Lower-Layer Binding Anchors X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2008 20:33:10 -0000 Yes. But I am not sure I am qualified to determine how applicable that work is to this question. Current work that probably relates to this is in the projects 802.1X-REV (Revision to update/synchronize Port-based Network Access Control) and 802.1AR (Secure Device Identifier). It looks to me as if 802.1X is what 802.1af evolved into. -- Eric Gray Principal Engineer Ericsson =20 > -----Original Message----- > From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On=20 > Behalf Of David Harrington > Sent: Wednesday, November 05, 2008 12:40 PM > To: 'Christian Vogt'; 'Pekka Savola'; 'ZhangDong' > Cc: 'SAVI Mailing List' > Subject: Re: [savi] Lower-Layer Binding Anchors >=20 > Hi, >=20 > It's been a while since I participated in IEEE 802.1, but I recall > them working on 802.1af(?) to provide link-layer security, and another > effort (don't remember the name) to standardize a link-layer identity. > If we want a more secure MAC address, could those be helpful here? Has > anybody been following IEEE 802.1? >=20 > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com >=20 >=20 > > -----Original Message----- > > From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On=20 > > Behalf Of Christian Vogt > > Sent: Friday, October 31, 2008 9:43 AM > > To: Pekka Savola; ZhangDong > > Cc: SAVI Mailing List > > Subject: Re: [savi] Lower-Layer Binding Anchors > >=20 > > Pekka and Zhang Dong, > >=20 > > you are of course right that MAC addresses fail to render a secure =20 > > binding anchor because they can be spoofed without much effort. But >=20 > > in some cases, we may have to rely on them anyway. > >=20 > > Having said this, I agree with you that we should use a more secure >=20 > > binding anchor whenever possible. And this makes me=20 > > reconsider what I =20 > > previously wrote to Marcelo: > >=20 > > > But since the SAVI charter wants us to focus on Ethernet,=20 > > we may use =20 > > > MAC addresses as a default. > >=20 > > Perhaps it would be better to define the default as: Use=20 > > switch ports =20 > > when available, and MAC addresses otherwise. Or: Use MAC=20 > > addresses, =20 > > and switch ports in addition if available. > >=20 > > What do you think? > >=20 > > - Christian > >=20 > >=20 > >=20 > > On Oct 31, 2008, ZhangDong wrote: > >=20 > > > I do not think link-layer address cannot be spoofed. > > > One important thing is that we must guarantee reliability and =20 > > > reality of the source information(e.g. link-layer address)=20 > > which the =20 > > > SAVI device obtains for binding. > > > This is the premise of binding. > >=20 > >=20 > >=20 > > On Oct 31, 2008, Pekka Savola wrote: > >=20 > > > If lower-layer address is chosen, we assume that the lower-layer =20 > > > address spoofability is prevented, yes? (E.g. using MAC address =20 > > > locking in switches). Usually that is not done by default=20 > > however, =20 > > > and doing so is challenging in many environments (e.g. a virtual =20 > > > server or a blade server connected to a switch port, having=20 > > 20 or 30 =20 > > > MAC addresses in one extreme; office network with roaming=20 > > laptops in =20 > > > another). > > > > > > Would port-based be a more widely applicable (default) solution? > >=20 > >=20 > >=20 > > _______________________________________________ > > savi mailing list > > savi@ietf.org > > https://www.ietf.org/mailman/listinfo/savi > >=20 >=20 > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi >=20 From christian.vogt@nomadiclab.com Wed Nov 5 14:38:21 2008 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 C84F93A67F6 for ; Wed, 5 Nov 2008 14:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 FOkRwmEnZguR for ; Wed, 5 Nov 2008 14:38:21 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id E17E63A6774 for ; Wed, 5 Nov 2008 14:38:20 -0800 (PST) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 2279C1EF1CB; Thu, 6 Nov 2008 00:38:17 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id D86871EF1C5; Thu, 6 Nov 2008 00:38:16 +0200 (EET) Message-Id: <661CD92A-9DCE-474A-B282-1987F4BEB0C8@nomadiclab.com> From: Christian Vogt To: David Harrington In-Reply-To: <074501c93f6d$912c1420$0500a8c0@china.huawei.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 6 Nov 2008 00:38:16 +0200 References: <80FC6F68-D020-4D4F-B3A8-1EFC619C2290@nomadiclab.com> <074501c93f6d$912c1420$0500a8c0@china.huawei.com> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV using ClamSMTP Cc: 'SAVI Mailing List' Subject: Re: [savi] Lower-Layer Binding Anchors X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2008 22:38:21 -0000 Hi David, this is interesting. Note, however, that a recently agreed-upon goal of SAVI is to do with minimal requirements for SAVI deployment. Requiring special crypto at the link layer would not be compatible with that goal. Of course, it is certainly conceivable that, on the long run, one could devise a SAVI extension that makes use of the extra link layer security -- for those scenarios where it is available. - Christian On Nov 5, 2008, at 19:39, David Harrington wrote: > Hi, > > It's been a while since I participated in IEEE 802.1, but I recall > them working on 802.1af(?) to provide link-layer security, and another > effort (don't remember the name) to standardize a link-layer identity. > If we want a more secure MAC address, could those be helpful here? Has > anybody been following IEEE 802.1? > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com From ietfdbh@comcast.net Wed Nov 5 15:09:49 2008 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 26F993A688C for ; Wed, 5 Nov 2008 15:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 CN7H6Md6zuQo for ; Wed, 5 Nov 2008 15:09:48 -0800 (PST) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 28E0A3A687B for ; Wed, 5 Nov 2008 15:09:36 -0800 (PST) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA07.westchester.pa.mail.comcast.net with comcast id bb7M1a00316LCl057b7bus; Wed, 05 Nov 2008 23:07:35 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA06.westchester.pa.mail.comcast.net with comcast id bb841a0014HwxpC3Sb84PL; Wed, 05 Nov 2008 23:08:06 +0000 X-Authority-Analysis: v=1.0 c=1 a=SqQCI2xKtNwA:10 a=8Vt6Cm07uw2zX_cvGl8A:9 a=I0ZDqY6ZuKqR1VWVlnwA:7 a=XfjqWLVS7N2NUB76z0yMvz21ye4A:4 a=wf6Uu8L3f_0A:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=DtNC_WMltDEA:10 From: "David Harrington" To: "'Christian Vogt'" References: <80FC6F68-D020-4D4F-B3A8-1EFC619C2290@nomadiclab.com> <074501c93f6d$912c1420$0500a8c0@china.huawei.com> <661CD92A-9DCE-474A-B282-1987F4BEB0C8@nomadiclab.com> Date: Wed, 5 Nov 2008 18:08:03 -0500 Message-ID: <076a01c93f9b$5c2d6750$0500a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <661CD92A-9DCE-474A-B282-1987F4BEB0C8@nomadiclab.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Ack/l0qKpMkdH6e3SyGIOB027x0mGwAA+oGg Cc: 'SAVI Mailing List' Subject: Re: [savi] Lower-Layer Binding Anchors X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2008 23:09:49 -0000 802.1X seems to be widely deployed, so I wouldn't expect it be veruy onerous. dbh > -----Original Message----- > From: Christian Vogt [mailto:christian.vogt@nomadiclab.com] > Sent: Wednesday, November 05, 2008 5:38 PM > To: David Harrington > Cc: 'Pekka Savola'; 'ZhangDong'; 'SAVI Mailing List' > Subject: Re: [savi] Lower-Layer Binding Anchors > > Hi David, > > this is interesting. > > Note, however, that a recently agreed-upon goal of SAVI is to > do with > minimal requirements for SAVI deployment. Requiring special > crypto at > the link layer would not be compatible with that goal. Of > course, it > is certainly conceivable that, on the long run, one could devise a > SAVI extension that makes use of the extra link layer > security -- for > those scenarios where it is available. > > - Christian > > > > On Nov 5, 2008, at 19:39, David Harrington wrote: > > > Hi, > > > > It's been a while since I participated in IEEE 802.1, but I recall > > them working on 802.1af(?) to provide link-layer security, > and another > > effort (don't remember the name) to standardize a > link-layer identity. > > If we want a more secure MAC address, could those be > helpful here? Has > > anybody been following IEEE 802.1? > > > > David Harrington > > dbharrington@comcast.net > > ietfdbh@comcast.net > > dharrington@huawei.com > > > From fred@cisco.com Wed Nov 5 15:10:08 2008 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 168303A687C for ; Wed, 5 Nov 2008 15:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDF+sMPABmFB for ; Wed, 5 Nov 2008 15:10:05 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id EA2053A687B for ; Wed, 5 Nov 2008 15:10:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,552,1220227200"; d="scan'208";a="102081517" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 05 Nov 2008 23:09:26 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id mA5N9QQG028626; Wed, 5 Nov 2008 15:09:26 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mA5N9QnT014073; Wed, 5 Nov 2008 23:09:26 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Nov 2008 15:09:26 -0800 Received: from stealth-10-32-244-221.cisco.com ([10.32.244.221]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Nov 2008 15:09:25 -0800 Message-Id: <473BFA27-9816-42CD-B08F-C7B2B6A64AE7@cisco.com> From: Fred Baker To: Christian Vogt In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 5 Nov 2008 15:09:25 -0800 References: X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 05 Nov 2008 23:09:26.0136 (UTC) FILETIME=[8C325780:01C93F9B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1836; t=1225926566; x=1226790566; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[savi]=20Lower-Layer=20Binding=20Anchor s |Sender:=20; bh=f+OenyMfSoVTjmebVVL9W2UYadeKvNWkJ5cuU/RLlTw=; b=hzLslEfMgRRygZCNEBsgUU4xeVp0S9mAe1lYG5vDu1bDaiy6ITSRFfFlfY +EiIwk3kLD4pd9bHNm7yAV4I5eP4DmvWY1iTemPpwQK7yGuG4dqbkOvEYMZA o/dOde2T9h; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: SAVI Mailing List Subject: Re: [savi] Lower-Layer Binding Anchors X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2008 23:10:08 -0000 lower layer elements would include the following, I think. Have I missed anything? - switch port or set of ports (as viewed by a switch) - MAC address or equivalent - radio channel or security association related to such - DSL VC-or-equivalent - Cable Modem customer channel On Oct 30, 2008, at 2:44 PM, Christian Vogt wrote: > Folks, > > since our charter requires SAVI to not change hosts, a SAVI device > will > necessarily have to bind IP addresses to a property of layers below > IP. > This is because, in the absence of host changes, properties of lower > layers are the only reasonably trustworthy information about a packet > sender that shows up in all packets. The question hence is which > lower-layer properties, or lower-layer "binding anchors", are most > appropriate for this purpose. > > In the design taxonomy [1] that Bill and I presented in Dublin, we > identified two suitable lower-layer binding anchors: link-layer > addresses and switch ports. The design taxonomy also includes an > analysis of which challenging situations (mobility, multi-homing, > etc.) > each binding anchor can handle. I would like to take this as a basis > for a discussion with you on which binding anchor, or which > combination, > you folks deem more appropriate. > > One possible approach would be to define a set of possible binding > anchors, and leave it up to the administrator to choose one or more of > them. We should, of course, explain the pros and cons of the > different > binding anchors. And we could define a default setup. > > - Christian > > > [1] http://www.ietf.org/proceedings/08jul/slides/savi-2.pdf > > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From fred@cisco.com Wed Nov 5 15:12:38 2008 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 422713A687C for ; Wed, 5 Nov 2008 15:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PBdq6K-RwuG for ; Wed, 5 Nov 2008 15:12:37 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 5EF533A6828 for ; Wed, 5 Nov 2008 15:12:37 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,552,1220227200"; d="scan'208";a="100780773" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 05 Nov 2008 23:12:17 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mA5NCHlf026594; Wed, 5 Nov 2008 15:12:17 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id mA5NCHNq005193; Wed, 5 Nov 2008 23:12:17 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Nov 2008 15:12:17 -0800 Received: from stealth-10-32-244-221.cisco.com ([10.32.244.221]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Nov 2008 15:12:16 -0800 Message-Id: <5CB27A60-DF96-4115-9EA9-F82681A6B07F@cisco.com> From: Fred Baker To: Christian Vogt In-Reply-To: <57B1F2B3-5FB7-4406-A170-28849028EEF3@nomadiclab.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 5 Nov 2008 15:12:16 -0800 References: <490ACBA1.8030503@it.uc3m.es> <57B1F2B3-5FB7-4406-A170-28849028EEF3@nomadiclab.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 05 Nov 2008 23:12:16.0990 (UTC) FILETIME=[F20897E0:01C93F9B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=657; t=1225926737; x=1226790737; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[savi]=20Lower-Layer=20Binding=20Anchor s |Sender:=20; bh=zrdO6nDs34f8Fbxdm5B/1rXb4emn/4CSivMWWb82O2g=; b=jvE28tXG6IxLp5se08am9BNowZ+VpC9ov0SphdBDX6p3xcl67MCm8XjCWy nNkjzwDJQr4MBwnxYbyCZVnGoYqQEzHzW+sFy3sgGDsH6oz6P1CwcAhRutwH kN82j3UuKt; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: SAVI Mailing List Subject: Re: [savi] Lower-Layer Binding Anchors X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2008 23:12:38 -0000 On Oct 31, 2008, at 5:08 AM, Christian Vogt wrote: > But since the SAVI charter wants us to focus on Ethernet, we may use > MAC addresses as a default. not necessarily. Since we can't change the hosts, and in the local LAN context "host" includes "router", we're talking about switches or hubs. Hubs may as well be physical wires, which brings us back to switches. I think you'll find switches trusting their ports before they trust datagram content received on the ports. They want to say that a datagram received from some specific port should have some specific source address or from among some set of source addresses. From christian.vogt@ericsson.com Thu Nov 6 01:33:25 2008 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 5F1A23A697D for ; Thu, 6 Nov 2008 01:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.136 X-Spam-Level: X-Spam-Status: No, score=-6.136 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 yGQ1g4e5DW1l for ; Thu, 6 Nov 2008 01:33:24 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 5541C3A6989 for ; Thu, 6 Nov 2008 01:33:23 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A6C3722152; Thu, 6 Nov 2008 10:32:14 +0100 (CET) X-AuditID: c1b4fb3e-aef86bb00000537b-45-4912b99e7879 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8E15D22280; Thu, 6 Nov 2008 10:32:14 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Nov 2008 10:32:14 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Nov 2008 10:32:13 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 923262320; Thu, 6 Nov 2008 11:32:13 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 66AEA4DABE; Thu, 6 Nov 2008 11:32:13 +0200 (EET) Message-Id: <9FE20988-5F24-4B77-A150-CF33E7906F07@ericsson.com> From: Christian Vogt To: Fred Baker In-Reply-To: <5CB27A60-DF96-4115-9EA9-F82681A6B07F@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 6 Nov 2008 11:32:13 +0200 References: <490ACBA1.8030503@it.uc3m.es> <57B1F2B3-5FB7-4406-A170-28849028EEF3@nomadiclab.com> <5CB27A60-DF96-4115-9EA9-F82681A6B07F@cisco.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 06 Nov 2008 09:32:13.0947 (UTC) FILETIME=[8D25CCB0:01C93FF2] X-Brightmail-Tracker: AAAAAA== Cc: SAVI Mailing List Subject: Re: [savi] Lower-Layer Binding Anchors 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, 06 Nov 2008 09:33:25 -0000 On Nov 6, 2008, Fred Baker wrote: > not necessarily. Since we can't change the hosts, and in the local > LAN context "host" includes "router", we're talking about switches > or hubs. Hubs may as well be physical wires, which brings us back to > switches. Correct. Where SAVI is implemented on a switch, switch ports could also be used as a default lower-layer binding anchor. Or the default binding anchor could be the combination of a switch port and a MAC address. The combination of switch port and MAC address is actually my preference for a default binding anchor in this case. The reason is that, if we used only a switch port as a binding anchor, then the source address validation would be of very coarse granularity if multiple hosts are connected to a single switch port. Examples where this would be the case are (i) switch ports connected to other switches, or (ii) switch ports connected to Wi-Fi base stations. Using the MAC address in addition to the switch port in these cases will ensure that source address validation is still at the granularity of a single host. - Christian From christian.vogt@ericsson.com Thu Nov 6 01:40:24 2008 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 712033A69E6 for ; Thu, 6 Nov 2008 01:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.142 X-Spam-Level: X-Spam-Status: No, score=-6.142 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 3bFNP8S2rgib for ; Thu, 6 Nov 2008 01:40:23 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9DB353A6969 for ; Thu, 6 Nov 2008 01:40:23 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 268D420715; Thu, 6 Nov 2008 10:40:20 +0100 (CET) X-AuditID: c1b4fb3e-abf80bb00000537b-43-4912bb849e85 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1452A21263; Thu, 6 Nov 2008 10:40:20 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Nov 2008 10:40:19 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Nov 2008 10:40:19 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 0B8CC2320; Thu, 6 Nov 2008 11:40:19 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D5E794DABE; Thu, 6 Nov 2008 11:40:18 +0200 (EET) Message-Id: <978D870F-9C3E-4E56-A5EE-FE052D4D298E@ericsson.com> From: Christian Vogt To: David Harrington In-Reply-To: <661CD92A-9DCE-474A-B282-1987F4BEB0C8@nomadiclab.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 6 Nov 2008 11:40:18 +0200 References: <80FC6F68-D020-4D4F-B3A8-1EFC619C2290@nomadiclab.com> <074501c93f6d$912c1420$0500a8c0@china.huawei.com> <661CD92A-9DCE-474A-B282-1987F4BEB0C8@nomadiclab.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 06 Nov 2008 09:40:19.0287 (UTC) FILETIME=[AE6ECE70:01C93FF3] X-Brightmail-Tracker: AAAAAA== Cc: SAVI Mailing List Subject: Re: [savi] Lower-Layer Binding Anchors 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, 06 Nov 2008 09:40:24 -0000 On Nov 6, 2008, Christian Vogt wrote: > Of course, it is certainly conceivable that, on the long run, one > could devise a SAVI extension that makes use of the extra link layer > security -- for those scenarios where it is available. Let me actually make an addition here: Perhaps we don't even need an extension to SAVI in order to benefit from 802.1X-secured MAC addresses, because 802.1X and SAVI are completely independent of each other. Still, if you deploy both and configure SAVI to use MAC addresses as binding anchors, then SAVI provides extra IP source address security thanks to the MAC addresses now being 802.1X-secured. Comments? - Christian From fred@cisco.com Thu Nov 6 07:08:54 2008 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 88DA43A6887 for ; Thu, 6 Nov 2008 07:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQuIu+shpyuT for ; Thu, 6 Nov 2008 07:08:49 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 3020A3A6834 for ; Thu, 6 Nov 2008 07:08:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,557,1220227200"; d="scan'208";a="24251723" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 06 Nov 2008 15:07:42 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id mA6F7fTh004929; Thu, 6 Nov 2008 07:07:41 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mA6F7flJ002723; Thu, 6 Nov 2008 15:07:41 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Nov 2008 07:07:40 -0800 Received: from stealth-10-32-244-221.cisco.com ([10.32.244.221]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Nov 2008 07:07:40 -0800 Message-Id: From: Fred Baker To: Christian Vogt In-Reply-To: <9FE20988-5F24-4B77-A150-CF33E7906F07@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 6 Nov 2008 07:07:39 -0800 References: <490ACBA1.8030503@it.uc3m.es> <57B1F2B3-5FB7-4406-A170-28849028EEF3@nomadiclab.com> <5CB27A60-DF96-4115-9EA9-F82681A6B07F@cisco.com> <9FE20988-5F24-4B77-A150-CF33E7906F07@ericsson.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 06 Nov 2008 15:07:40.0037 (UTC) FILETIME=[693B6B50:01C94021] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=281; t=1225984061; x=1226848061; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[savi]=20Lower-Layer=20Binding=20Anchor s |Sender:=20; bh=ULLWUkjvSLQmn+SnYE/TRUrriP+XL5O7pG8dluG2MMo=; b=Lqee9zrIRhGpx/5BEIpKfXVNlz761E20h1mgs8FuC/m7jFCtYUHCqh8yDi Z958UfPMVKfv9OxWLxBc81yktDur4mv4xdRC/4fshs8qaneF5KnFhZjyuXcd FhVod461A7; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: SAVI Mailing List Subject: Re: [savi] Lower-Layer Binding Anchors 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, 06 Nov 2008 15:08:54 -0000 On Nov 6, 2008, at 1:32 AM, Christian Vogt wrote: > The combination of switch port and MAC address is actually my > preference for a default binding anchor in this case. That makes sense, especially when the port in question is a trunk port - one to another switch. From fred@cisco.com Thu Nov 6 07:08:59 2008 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 A64D13A686A for ; Thu, 6 Nov 2008 07:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.574 X-Spam-Level: X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PA7OVx599llM for ; Thu, 6 Nov 2008 07:08:56 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id F310D3A690D for ; Thu, 6 Nov 2008 07:08:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,557,1220227200"; d="scan'208";a="113618511" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 06 Nov 2008 15:08:08 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mA6F86jt031172; Thu, 6 Nov 2008 07:08:06 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id mA6F86xp028336; Thu, 6 Nov 2008 15:08:06 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Nov 2008 07:08:06 -0800 Received: from stealth-10-32-244-221.cisco.com ([10.32.244.221]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Nov 2008 07:08:05 -0800 Message-Id: From: Fred Baker To: Christian Vogt In-Reply-To: <978D870F-9C3E-4E56-A5EE-FE052D4D298E@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 6 Nov 2008 07:08:05 -0800 References: <80FC6F68-D020-4D4F-B3A8-1EFC619C2290@nomadiclab.com> <074501c93f6d$912c1420$0500a8c0@china.huawei.com> <661CD92A-9DCE-474A-B282-1987F4BEB0C8@nomadiclab.com> <978D870F-9C3E-4E56-A5EE-FE052D4D298E@ericsson.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 06 Nov 2008 15:08:05.0927 (UTC) FILETIME=[78A9EB70:01C94021] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=498; t=1225984086; x=1226848086; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[savi]=20Lower-Layer=20Binding=20Anchor s |Sender:=20; bh=rnWQXnVVMGPm3F0pfb8enpLPKL37jrIsDWJC/naMGGc=; b=qNmIeds3ZfqjIGFHBpuWsvrASQRgiw183CqgAEtD2CMhZKFpizNcES2GHH zW9sztchw3y2lkv0dZAQVOUy/kKTQ4qnfRdZXNKnuo2WYoi8FbHFp2tfuHVI K/xI87Wh0+; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: SAVI Mailing List Subject: Re: [savi] Lower-Layer Binding Anchors 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, 06 Nov 2008 15:08:59 -0000 On Nov 6, 2008, at 1:40 AM, Christian Vogt wrote: > Perhaps we don't even need an extension to SAVI in order to benefit > from 802.1X-secured MAC addresses, because 802.1X and SAVI are > completely independent of each other. Still, if you deploy both and > configure SAVI to use MAC addresses as binding anchors, then SAVI > provides extra IP source address security thanks to the MAC > addresses now being 802.1X-secured. It is stronger than one that is not secured, yes. From ietfdbh@comcast.net Thu Nov 6 07:34:29 2008 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 94B6F3A6A0D for ; Thu, 6 Nov 2008 07:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBDFi6tNMaH0 for ; Thu, 6 Nov 2008 07:34:28 -0800 (PST) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 688293A69B5 for ; Thu, 6 Nov 2008 07:34:25 -0800 (PST) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA01.westchester.pa.mail.comcast.net with comcast id bqvQ1a0010QuhwU51rYvdi; Thu, 06 Nov 2008 15:33:14 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA02.westchester.pa.mail.comcast.net with comcast id brYe1a0074HwxpC3NrYep9; Thu, 06 Nov 2008 15:32:38 +0000 X-Authority-Analysis: v=1.0 c=1 a=SqQCI2xKtNwA:10 a=8g23-aP7cGnNrjNoyGQA:9 a=Vud6vMDqAqW49JV7_LUA:7 a=N32BN2rF6ltTU4ddrWbRriQO3MYA:4 a=JfD0Fch1gWkA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Fred Baker'" , "'Christian Vogt'" References: <80FC6F68-D020-4D4F-B3A8-1EFC619C2290@nomadiclab.com> <074501c93f6d$912c1420$0500a8c0@china.huawei.com> <661CD92A-9DCE-474A-B282-1987F4BEB0C8@nomadiclab.com> <978D870F-9C3E-4E56-A5EE-FE052D4D298E@ericsson.com> Date: Thu, 6 Nov 2008 10:32:38 -0500 Message-ID: <079801c94024$e67e7fa0$0500a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AclAIXp+LeRhLm6bThWyEKkH/vCEwAAAGHjw Cc: 'SAVI Mailing List' Subject: Re: [savi] Lower-Layer Binding Anchors 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, 06 Nov 2008 15:34:29 -0000 Hi, I guess my concern is the other side of the coin: if you deploy only SAVI and configure SAVI to use MAC addresses as binding anchors, then SAVI does not provide extra IP source address security if the MAC addresses are not being 802.1X-secured. And even when 802.1X is used, 802.1X has had the problems of multiple hosts being represented by a single MAC, MAC cloning, and other MAC spoofing issues. We need to be sure we do not mislead people into thinking that SAVI makes IP source addresses more secure, when it does not necessarily do that if the MAC is not secured. I guess this raises the question of whether MAC-binding can be a viable approach for validating IP src addresses, if we have no reliable mechanisms for MAC address validation. dbh > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Thursday, November 06, 2008 10:08 AM > To: Christian Vogt > Cc: David Harrington; SAVI Mailing List > Subject: Re: [savi] Lower-Layer Binding Anchors > > > On Nov 6, 2008, at 1:40 AM, Christian Vogt wrote: > > > Perhaps we don't even need an extension to SAVI in order to > benefit > > from 802.1X-secured MAC addresses, because 802.1X and SAVI are > > completely independent of each other. Still, if you deploy > both and > > configure SAVI to use MAC addresses as binding anchors, then SAVI > > provides extra IP source address security thanks to the MAC > > addresses now being 802.1X-secured. > > It is stronger than one that is not secured, yes. > From marcelo@it.uc3m.es Thu Nov 6 07:50:47 2008 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 0C31B3A6859 for ; Thu, 6 Nov 2008 07:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=1.216, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 K3wBrlgUdDEG for ; Thu, 6 Nov 2008 07:50:46 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id A23BC3A690D for ; Thu, 6 Nov 2008 07:50:45 -0800 (PST) Received: from dummyhost1.it.uc3m.es (dummyhost33.it.uc3m.es [163.117.139.223])by smtp03.uc3m.es (Postfix) with ESMTP id E079C6AF294;Thu, 6 Nov 2008 16:50:40 +0100 (CET) Message-ID: <4913124D.2070804@it.uc3m.es> Date: Thu, 06 Nov 2008 16:50:37 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: David Harrington References: <80FC6F68-D020-4D4F-B3A8-1EFC619C2290 @ nomadiclab.com><074501c93f6d$912c1420$0500a8c0@china.huawei.com><661CD92A -9 DCE-474A-B282-1987F4BEB0C8@nomadiclab.com><978D870F-9C3E-4E56-A5EE-FE052 D4D 298E@ericsson.com> <079801c94024$e67e7fa0$0500a8c0@china.huawei.com> In-Reply-To: <079801c94024$e67e7fa0$0500a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-21.7268 TC:1F TRN:41 TV:5.5.1026(16264.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: 'SAVI Mailing List' , 'Christian Vogt' Subject: Re: [savi] Lower-Layer Binding Anchors 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, 06 Nov 2008 15:50:47 -0000 Hi, I think that maybe one option is to define a the SAVI base spec with two parts: First a general framework, where the SAVI functions binds the IP source address to a generic lower layer anchors left unspecified in the general framework). Second, a set of annexes where we define what are those anchors for some well know technologies (such as the list Fred has defined) Additionally, we can support for new layer 2 technologies in additional document if needed does this sounds like a feasible approach? regards, marcelo David Harrington escribió: > Hi, > > I guess my concern is the other side of the coin: > if you deploy only SAVI and configure SAVI to use MAC addresses as > binding anchors, then SAVI does not provide extra IP source address > security if the MAC addresses are not being 802.1X-secured. > > And even when 802.1X is used, 802.1X has had the problems of multiple > hosts being represented by a single MAC, MAC cloning, and other MAC > spoofing issues. > > We need to be sure we do not mislead people into thinking that SAVI > makes IP source addresses more secure, when it does not necessarily do > that if the MAC is not secured. > > I guess this raises the question of whether MAC-binding can be a > viable approach for validating IP src addresses, if we have no > reliable mechanisms for MAC address validation. > > dbh > > >> -----Original Message----- >> From: Fred Baker [mailto:fred@cisco.com] >> Sent: Thursday, November 06, 2008 10:08 AM >> To: Christian Vogt >> Cc: David Harrington; SAVI Mailing List >> Subject: Re: [savi] Lower-Layer Binding Anchors >> >> >> On Nov 6, 2008, at 1:40 AM, Christian Vogt wrote: >> >> >>> Perhaps we don't even need an extension to SAVI in order to >>> >> benefit >> >>> from 802.1X-secured MAC addresses, because 802.1X and SAVI are >>> completely independent of each other. Still, if you deploy >>> >> both and >> >>> configure SAVI to use MAC addresses as binding anchors, then SAVI >>> > > >>> provides extra IP source address security thanks to the MAC >>> addresses now being 802.1X-secured. >>> >> It is stronger than one that is not secured, yes. >> >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > > From christian.vogt@ericsson.com Thu Nov 6 09:25:20 2008 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 933313A6A24 for ; Thu, 6 Nov 2008 09:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.161 X-Spam-Level: X-Spam-Status: No, score=-6.161 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 HwZqEE+i0uIt for ; Thu, 6 Nov 2008 09:25:14 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 614C03A69B5 for ; Thu, 6 Nov 2008 09:25:12 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8CC062130E; Thu, 6 Nov 2008 18:24:30 +0100 (CET) X-AuditID: c1b4fb3e-ae785bb00000537b-cb-4913284e2798 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6F30F206FA; Thu, 6 Nov 2008 18:24:30 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Nov 2008 18:24:30 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Nov 2008 18:24:29 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8FFB92325; Thu, 6 Nov 2008 19:24:29 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5B9064DABE; Thu, 6 Nov 2008 19:24:29 +0200 (EET) Message-Id: <2B138C08-D3C1-4951-9091-F92E01F1274F@ericsson.com> From: Christian Vogt To: marcelo bagnulo braun In-Reply-To: <4913124D.2070804@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 6 Nov 2008 19:24:28 +0200 References: <80FC6F68-D020-4D4F-B3A8-1EFC619C2290 @ nomadiclab.com><074501c93f6d$912c1420$0500a8c0@china.huawei.com><661CD92A -9 DCE-474A-B282-1987F4BEB0C8@nomadiclab.com><978D870F-9C3E-4E56-A5EE-FE052 D4D 298E@ericsson.com> <079801c94024$e67e7fa0$0500a8c0@china.huawei.com> <4913124D.2070804@it.uc3m.es> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 06 Nov 2008 17:24:29.0984 (UTC) FILETIME=[86BDEA00:01C94034] X-Brightmail-Tracker: AAAAAA== Cc: 'SAVI Mailing List' Subject: Re: [savi] Lower-Layer Binding Anchors 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, 06 Nov 2008 17:25:20 -0000 Marcelo - Yes, this modularization of the document would be really good. And the list of possible binding anchors should have a brief statement for each binding anchor about the level of security provided. The binding anchor list from Fred's document would be a good starting point. - Christian marcelo bagnulo braun wrote: > Hi, > > I think that maybe one option is to define a the SAVI base spec with > two parts: > First a general framework, where the SAVI functions binds the IP > source address to a generic lower layer anchors left unspecified in > the general framework). > Second, a set of annexes where we define what are those anchors for > some well know technologies (such as the list Fred has defined) > > Additionally, we can support for new layer 2 technologies in > additional document if needed > > does this sounds like a feasible approach? > > regards, marcelo From ietfdbh@comcast.net Thu Nov 6 09:45:39 2008 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 AE38D3A6A2A for ; Thu, 6 Nov 2008 09:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmve7xpQ3VtE for ; Thu, 6 Nov 2008 09:45:38 -0800 (PST) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 8D5E43A6A24 for ; Thu, 6 Nov 2008 09:45:38 -0800 (PST) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA02.westchester.pa.mail.comcast.net with comcast id btdS1a0090Fqzac52tlReH; Thu, 06 Nov 2008 17:45:25 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA08.westchester.pa.mail.comcast.net with comcast id btXu1a00L4HwxpC3UtXuja; Thu, 06 Nov 2008 17:31:55 +0000 X-Authority-Analysis: v=1.0 c=1 a=SqQCI2xKtNwA:10 a=U8HLkUZOGDwFw6nLtlUA:9 a=_kb3BDagZuSblCARSPoA:7 a=Hxm00DFNVvsQsiJLQ2Vqu3lBD7AA:4 a=f7GxY0FH8QIA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Christian Vogt'" , "'marcelo bagnulo braun'" References: <80FC6F68-D020-4D4F-B3A8-1EFC619C2290 @ nomadiclab.com><074501c93f6d$912c1420$0500a8c0@china.huawei.com><661CD92A -9 DCE-474A-B282-1987F4BEB0C8@nomadiclab.com><978D870F-9C3E-4E56-A5EE-FE052 D4D 298E@ericsson.com> <079801c94024$e67e7fa0$0500a8c0@china.huawei.com> <4913124D.2070804@it.uc3m.es> <2B138C08-D3C1-4951-9091-F92E01F1274F@ericsson.com> Date: Thu, 6 Nov 2008 12:31:54 -0500 Message-ID: <07a201c94035$9032ea30$0500a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <2B138C08-D3C1-4951-9091-F92E01F1274F@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AclANIiKQOw9KVR9SDezD+7oSkyNUQAAC8cA Cc: 'SAVI Mailing List' Subject: Re: [savi] Lower-Layer Binding Anchors 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, 06 Nov 2008 17:45:39 -0000 Hi, Be careful about trying to quantify "level of security provided". This is highly dependent on the environment in which the solution is deployed, and can be dramatically changed if a crypto algorithm is "broken". If you want to list potential binding anchors and their properties, then you should focus on what threats are mitigated by each binding anchor, the known security vulnerabilities for each binding anchor, how those impact SAVI, and RECOMMENDED deployment approaches for use with SAVI. dbh > -----Original Message----- > From: Christian Vogt [mailto:christian.vogt@ericsson.com] > Sent: Thursday, November 06, 2008 12:24 PM > To: marcelo bagnulo braun > Cc: David Harrington; 'Fred Baker'; 'SAVI Mailing List' > Subject: Re: [savi] Lower-Layer Binding Anchors > > Marcelo - > > Yes, this modularization of the document would be really good. And > the list of possible binding anchors should have a brief > statement for > each binding anchor about the level of security provided. > > The binding anchor list from Fred's document would be a good > starting > point. > > - Christian > > > > marcelo bagnulo braun wrote: > > > Hi, > > > > I think that maybe one option is to define a the SAVI base > spec with > > two parts: > > First a general framework, where the SAVI functions binds the IP > > source address to a generic lower layer anchors left > unspecified in > > the general framework). > > Second, a set of annexes where we define what are those > anchors for > > some well know technologies (such as the list Fred has defined) > > > > Additionally, we can support for new layer 2 technologies in > > additional document if needed > > > > does this sounds like a feasible approach? > > > > regards, marcelo > > > From christian.vogt@ericsson.com Thu Nov 6 10:16:53 2008 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 C8C863A6A28 for ; Thu, 6 Nov 2008 10:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.167 X-Spam-Level: X-Spam-Status: No, score=-6.167 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 TVzNNqvjAnKf for ; Thu, 6 Nov 2008 10:16:53 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 80A0C3A68AA for ; Thu, 6 Nov 2008 10:16:52 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3CA20200C3; Thu, 6 Nov 2008 19:16:06 +0100 (CET) X-AuditID: c1b4fb3e-abf80bb00000537b-e6-491334665fcf Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2052C20194; Thu, 6 Nov 2008 19:16:06 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Nov 2008 19:16:06 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Nov 2008 19:16:05 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A2A612325; Thu, 6 Nov 2008 20:16:05 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 694144DABE; Thu, 6 Nov 2008 20:16:05 +0200 (EET) Message-Id: <393E0450-CDC1-4BCC-9C37-018FECB3B619@ericsson.com> From: Christian Vogt To: David Harrington In-Reply-To: <07a201c94035$9032ea30$0500a8c0@china.huawei.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 6 Nov 2008 20:16:05 +0200 References: <80FC6F68-D020-4D4F-B3A8-1EFC619C2290 @ nomadiclab.com><074501c93f6d$912c1420$0500a8c0@china.huawei.com><661CD92A -9 DCE-474A-B282-1987F4BEB0C8@nomadiclab.com><978D870F-9C3E-4E56-A5EE-FE052 D4D 298E@ericsson.com> <079801c94024$e67e7fa0$0500a8c0@china.huawei.com> <4913124D.2070804@it.uc3m.es> <2B138C08-D3C1-4951-9091-F92E01F1274F@ericsson.com> <07a201c94035$9032ea30$0500a8c0@china.huawei.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 06 Nov 2008 18:16:05.0864 (UTC) FILETIME=[BC07B680:01C9403B] X-Brightmail-Tracker: AAAAAA== Cc: 'SAVI Mailing List' Subject: Re: [savi] Lower-Layer Binding Anchors 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, 06 Nov 2008 18:16:53 -0000 David Harrington wrote: > Be careful about trying to quantify "level of security provided". This > is highly dependent on the environment in which the solution is > deployed, and can be dramatically changed if a crypto algorithm is > "broken". > > If you want to list potential binding anchors and their properties, > then you should focus on what threats are mitigated by each binding > anchor, the known security vulnerabilities for each binding anchor, > how those impact SAVI, and RECOMMENDED deployment approaches for use > with SAVI. Right, I agree. Recommending deployment approaches for use with SAVI is a good idea as well. - Christian From zhangdong_rh@huaweisymantec.com Thu Nov 6 18:25:26 2008 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 47C043A6AE3 for ; Thu, 6 Nov 2008 18:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.546 X-Spam-Level: *** X-Spam-Status: No, score=3.546 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_GB2312=1.345] 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 ohTviemweJGD for ; Thu, 6 Nov 2008 18:25:25 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id 643B43A6AC6 for ; Thu, 6 Nov 2008 18:25:25 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0K9X00D3ZYQ63O30@hstga02-in.huaweisymantec.com> for savi@ietf.org; Fri, 07 Nov 2008 10:25:19 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0K9X008KYYQ4TA00@hstml02-in.huaweisymantec.com> for savi@ietf.org; Fri, 07 Nov 2008 10:25:17 +0800 (CST) Received: from [10.27.141.13] by hstml02-in.huaweisymantec.com (mshttpd); Fri, 07 Nov 2008 10:25:16 +0800 From: ZhangDong To: Christian Vogt Message-id: Date: Fri, 07 Nov 2008 10:25:16 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <978D870F-9C3E-4E56-A5EE-FE052D4D298E@ericsson.com> References: <80FC6F68-D020-4D4F-B3A8-1EFC619C2290@nomadiclab.com> <074501c93f6d$912c1420$0500a8c0@china.huawei.com> <661CD92A-9DCE-474A-B282-1987F4BEB0C8@nomadiclab.com> <978D870F-9C3E-4E56-A5EE-FE052D4D298E@ericsson.com> Cc: SAVI Mailing List Subject: [savi] =?gb2312?b?u9i4tDogUmU6ICBMb3dlci1MYXllciBCaW5kaW5nIEFu?= =?gb2312?b?Y2hvcnM=?= 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, 07 Nov 2008 02:25:26 -0000 > On Nov 6, 2008, Christian Vogt wrote: > > Let me actually make an addition here: > > Perhaps we don't even need an extension to SAVI in order to benefit > from 802.1X-secured MAC addresses, because 802.1X and SAVI are > completely independent of each other. Still, if you deploy both and > configure SAVI to use MAC addresses as binding anchors, then SAVI > provides extra IP source address security thanks to the MAC addresses > now being 802.1X-secured. First of all, any lower-layer anchors used by SAVI solution for binding must be secure. Especially for MAC addresses, they may be forged easily. Dong Zhang From danny@tcb.net Mon Nov 10 21:33:43 2008 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 A37BE3A69D4 for ; Mon, 10 Nov 2008 21:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.125 X-Spam-Level: ** X-Spam-Status: No, score=2.125 tagged_above=-999 required=5 tests=[DNS_FROM_RFC_BOGUSMX=2.125] 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 i-cOEnBGjwkF for ; Mon, 10 Nov 2008 21:33:43 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 187023A69C3 for ; Mon, 10 Nov 2008 21:33:43 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id EE0442684EA; Mon, 10 Nov 2008 22:33:43 -0700 (MST) Received: from [192.168.3.224] (204.181.64.59 [204.181.64.59]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 10 Nov 2008 22:33:43 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=204.181.64.59; client-port=35748; syn-fingerprint=65535:50:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: <2D0EA8A8-BAA2-45A5-93F0-947CA7B98105@tcb.net> From: Danny McPherson To: Christian Vogt In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 10 Nov 2008 22:28:19 -0700 References: X-Mailer: Apple Mail (2.929.2) Cc: SAVI Mailing List Subject: Re: [savi] Another review of SAVI Threat Scope document X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2008 05:33:43 -0000 On Oct 11, 2008, at 6:48 PM, Christian Vogt wrote: > > Ingress filtering may yield false negatives in deterministic manner. > Packets with a legitimate IP source address prefix, but a spoofed > interface identifier, pass ingress filtering checks. Can you tell me what you mean by the above, WRT spoofed interface identifier? -danny From christian.vogt@ericsson.com Mon Nov 10 23:47:01 2008 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 0A5F73A689D for ; Mon, 10 Nov 2008 23:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 yXspOT3bm9zn for ; Mon, 10 Nov 2008 23:47:00 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 427553A6861 for ; Mon, 10 Nov 2008 23:46:57 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DB26622188; Tue, 11 Nov 2008 08:46:56 +0100 (CET) X-AuditID: c1b4fb3e-af787bb00000537b-2e-49193870ca2b Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C68B522138; Tue, 11 Nov 2008 08:46:56 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Nov 2008 08:46:56 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Nov 2008 08:46:56 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id EBA3B245E; Tue, 11 Nov 2008 09:46:55 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id BFAF04DABE; Tue, 11 Nov 2008 09:46:55 +0200 (EET) Message-Id: <1E7DCF6A-831A-4E95-BF64-F120B43B6301@ericsson.com> From: Christian Vogt To: Danny McPherson In-Reply-To: <2D0EA8A8-BAA2-45A5-93F0-947CA7B98105@tcb.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 11 Nov 2008 09:46:55 +0200 References: <2D0EA8A8-BAA2-45A5-93F0-947CA7B98105@tcb.net> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 11 Nov 2008 07:46:56.0190 (UTC) FILETIME=[AB8955E0:01C943D1] X-Brightmail-Tracker: AAAAAA== Cc: SAVI Mailing List Subject: Re: [savi] Another review of SAVI Threat Scope document X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2008 07:47:01 -0000 Danny McPherson wrote: >> Ingress filtering may yield false negatives in deterministic manner. >> Packets with a legitimate IP source address prefix, but a spoofed >> interface identifier, pass ingress filtering checks. > > Can you tell me what you mean by the above, WRT spoofed > interface identifier? Hi Danny, my above statement is referring to the limitation of ingress filtering that only a prefix is validated, i.e., at most the 64 most significant bits. The 64 least significant bits are what I call the "interface identifier". These don't get validated by ingress filtering. If you spoof the interface identifier, but not the prefix of an IP address, ingress filtering will pass the IP address, yielding a false negative. - Christian From zhangdong_rh@huaweisymantec.com Tue Nov 11 23:50:50 2008 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 5DB443A6842 for ; Tue, 11 Nov 2008 23:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.19 X-Spam-Level: X-Spam-Status: No, score=0.19 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5agCdH4fKZlQ for ; Tue, 11 Nov 2008 23:50:49 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id 2C5433A681D for ; Tue, 11 Nov 2008 23:50:48 -0800 (PST) MIME-version: 1.0 Content-disposition: inline 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-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KA70052ON4J6A60@hstga02-in.huaweisymantec.com> for savi@ietf.org; Wed, 12 Nov 2008 15:50:45 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KA700825N4ISS10@hstml02-in.huaweisymantec.com> for savi@ietf.org; Wed, 12 Nov 2008 15:50:43 +0800 (CST) Received: from [10.27.141.13] by hstml02-in.huaweisymantec.com (mshttpd); Wed, 12 Nov 2008 15:50:42 +0800 From: ZhangDong To: marcelo bagnulo braun Message-id: Date: Wed, 12 Nov 2008 15:50:42 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <490498C5.3080706@it.uc3m.es> References: <490498C5.3080706@it.uc3m.es> Content-transfer-encoding: quoted-printable Cc: SAVI Mailing List Subject: [savi] some comments in language: [Fwd: I-D Action:draft-bagnulo-savi-send-00.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: Wed, 12 Nov 2008 07:50:50 -0000 Hi Marcelo=2C I have gone through the draft=2E Firstly=2C I want to ask a question abo= ut two concept=2E What are on-link and off-link=3F Do you mean on-link i= s local traffic and off-link is transit traffic=3F Then for I am a non-native English speaker=2C so I will point out severa= l language problems that affect my reading=2E =3E2=2E3=2E Address ownership proof =3E =3E The main function performed by SeND SAVI is to verify that the sour= ce =3E address used in data packets actually belongs to the originator of= =3E the packet=2E Since SeND SAVI scope is limited to the local-link=2C= the =3E originator of the packet is attached to the local-link=2E In orde= r to =3E to define any source address validation solution=2C we need to def= ine There is redundant word =22to=22=2E = =3E some address ownership proof concept i=2Ee=2E what it means to be = able to =3E proof that a given host owns a given address in the sense that the= =3E host is entitled to send packet with that source address=2E =3E =3E Since no hast changes are acceptable=2C we need to find the means = to What does =22hast=22 mean=3F have or has=3F =3E proof address ownership without requiring a new protocol=2E In Se= ND =3E SAVI the address ownership proof is based in the tools used by SeN= D=2C =3E namely CGAs and certificates=2E CGAs are used to verify that the =3E generator of a packet containing an on-link source address is =3E actually the owner of the address=2E Certificates are used to ver= ify =3E that a node sending packets with off-link source address is an =3E authorized router=2E By using these two tools=2C we can verify th= e =3E source address used in any packet flowing through the local-link i= s =3E either generated by the host owner of the on-link source address o= r =3E is generated by an authorized router=2E =3E =3E In both cases=2C the verification performed applies to the layer-2= =3E address used in the data packets=2E In the case of the CGA =3E verification=2C we use CGas and the SeND protocol to verify the =3E Neighbor Advertisement message which contains the binding between = the =3E CGA source address and the layer-2 address which will later be use= d =3E in data packets=2E By this mean we can verify that is the owner o= f the =3E CGA source address the one that is claiming to be willing to use t= he =3E layer-2 address in data packets=2E We assume that data packets =22By this mean we can verify that is the owner of the CGA source addres= s the one that is claiming to be willing to use the layer-2 address in d= ata packets=2E=22 I assume that this sentence is not very clear=2C one clause in another c= aluse=2E =3E containing this layer-2 information are valid=2E In the case of t= he =3E certificate validation=2C we use the certificate to validate that = a =3E given node is an authorized router=2E Then we use the CGA of that= =3E router to verify the binding between the address of the authorized= =3E router and the layer-2 information for that router=2E After these= two =3E checks=2C we assume that packets containing off-link addresses com= ing =3E from that layer-2 address are valid=2C since they come from the la= yer-2 =3E address of an authorized router=2E =3E =3E3=2E1=2E SeND SAVI Data structures =3E SeND SAVI function relies on state information binding the source =3E address used in data packets to the layer-2 information that =3E contained the first packet that used that source IP address=2E Su= ch Perhaps making the first sentence is more better=2E Thank you=2E Dong Zhang ----- =D4=AD=CA=BC=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A marcelo bagnulo braun =3Cmarcelo=40it=2Euc3m=2Ees=3E= =C8=D5=C6=DA=3A 2008=C4=EA 10=D4=C2 27=C8=D5=2C =D0=C7=C6=DA=D2=BB=2C =C9= =CF=CE=E712=3A20 =D6=F7=CC=E2=3A =5Bsavi=5D =5BFwd=3A I-D Action=3Adraft-bagnulo-savi-sen= d-00=2Etxt=5D =CA=D5=BC=FE=C8=CB=3A SAVI Mailing List =3Csavi=40ietf=2Eorg=3E =3E Hi=2C =3E = =3E I have submitted a draft describing how to build a SAVI solution = =3E using = =3E the SeND protocol without any change to the hosts nor to the SeND = =3E protocol=2E I think the resulting security level is pretty good=2E =3E = =3E Comments would be appreciated=2E =3E = =3E Regards=2C marcelo =3E = =3E = =3E = =3E -------- Mensaje original -------- =3E Asunto=3A I-D Action=3Adraft-bagnulo-savi-send-00=2Etxt =3E Fecha=3A Sun=2C 26 Oct 2008 09=3A15=3A01 -0700 (PDT) =3E De=3A Internet-Drafts=40ietf=2Eorg =3E Responder a=3A internet-drafts=40ietf=2Eorg =3E Para=3A i-d-announce=40ietf=2Eorg =3E = =3E = =3E = =3E A New Internet-Draft is available from the on-line Internet-Drafts = directories=2E =3E = =3E Title =3A SeND-based Source-Address Validation Implement= ation =3E Author(s) =3A M=2E Bagnulo =3E Filename =3A draft-bagnulo-savi-send-00=2Etxt =3E Pages =3A 10 =3E Date =3A 2008-10-26 =3E = =3E This memo describes SeND SAVI=2C a mechanism to provide source addr= ess =3E validation using the SeND protocol=2E The proposed mechanism is =3E intended to complement ingress filtering techniques to provide a =3E higher granularity on the control of the source addresses used=2E =3E = =3E A URL for this Internet-Draft is=3A =3E http=3A//www=2Eietf=2Eorg/internet-drafts/draft-bagnulo-savi-send-0= 0=2Etxt =3E = =3E Internet-Drafts are also available by anonymous FTP at=3A =3E ftp=3A//ftp=2Eietf=2Eorg/internet-drafts/ =3E = =3E Below is the data which will enable a MIME compliant mail reader =3E implementation to automatically retrieve the ASCII version of the =3E Internet-Draft=2E =3E = =3E = =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =3E I-D-Announce mailing list =3E I-D-Announce=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/i-d-announce =3E Internet-Draft directories=3A http=3A//www=2Eietf=2Eorg/shadow=2Eht= ml =3E or ftp=3A//ftp=2Eietf=2Eorg/ietf/1shadow-sites=2Etxt =3E = =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =3E savi mailing list =3E savi=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/savi =3E From christian.vogt@ericsson.com Thu Nov 13 07:41:14 2008 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 93AF428C105 for ; Thu, 13 Nov 2008 07:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 tfQ2cc9a9-gD for ; Thu, 13 Nov 2008 07:41:13 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 7BFD828C0DE for ; Thu, 13 Nov 2008 07:41:13 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BC29A209CC; Thu, 13 Nov 2008 16:41:12 +0100 (CET) X-AuditID: c1b4fb3c-ab8c9bb0000015b5-c3-491c4a987bad Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 98A3E207D2; Thu, 13 Nov 2008 16:41:12 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 16:41:12 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 16:41:12 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 21B8B231A; Thu, 13 Nov 2008 17:41:12 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 099084DBE9; Thu, 13 Nov 2008 17:41:12 +0200 (EET) Message-Id: From: Christian Vogt To: marcelo bagnulo braun In-Reply-To: <490B1D50.5030500@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 13 Nov 2008 17:41:11 +0200 References: <29B0AB6A-A250-427F-BFBB-AF63D405D633@nomadiclab.com> <490B1D50.5030500@it.uc3m.es> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 13 Nov 2008 15:41:12.0570 (UTC) FILETIME=[41AFD5A0:01C945A6] X-Brightmail-Tracker: AAAAAA== Cc: SAVI Mailing List Subject: Re: [savi] Identifying First-Hop Vs. Forwarded Traffic 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, 13 Nov 2008 15:41:14 -0000 >> As for myself, I see two possible approaches to distinguish between >> first-hop traffic and forwarded traffic: >> >> (1) Based on whether or not a packet's source address is from an on- >> link >> subnet prefix. >> >> (2) Based on whether or not the sending node is an authorized router. > > coming back to this original question, i think that in any case we > need > both. I mean, we need the list of onlink prefixes, if not SAVI does > not > know which source addresses can be generated by onlink nodes We need > the > list of routers cause if not we don't know which of the directly > connected devices can generate packets with off-link source addresses. Marcelo - Sorry for coming back late to this. I agree that SAVI devices need to know the on-link prefixes in any case. But I also believe that SAVI devices could do without knowing which neighbors are routers. The reason is that we could rely on ingress filtering to detect spoofed off-link source addresses. In that case, a SAVI device would not validate any packets with off-link source addresses; only when a packet goes through ingress filtering would a spoofed off-link source address be detected. This would provide somewhat lower, but still acceptable security IMO. The reason why the security would be lower if we rely on ingress filtering is that packets with off-link source addresses would not be checked if directly transmitted between neighbors. They would only be checked if relayed through a router, because only routers perform ingress filtering. - Christian From christian.vogt@ericsson.com Thu Nov 13 08:51:30 2008 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 97D973A67AC for ; Thu, 13 Nov 2008 08:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.928 X-Spam-Level: X-Spam-Status: No, score=-5.928 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 w1xsMtpVoDTx for ; Thu, 13 Nov 2008 08:51:29 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 57F4D3A63EB for ; Thu, 13 Nov 2008 08:51:29 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1CD312138E; Thu, 13 Nov 2008 17:50:18 +0100 (CET) X-AuditID: c1b4fb3e-ae785bb00000537b-1c-491c5ac9220c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 042E4213BD; Thu, 13 Nov 2008 17:50:17 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 17:50:17 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 17:50:16 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 76C35245E; Thu, 13 Nov 2008 18:50:16 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 554864DBE9; Thu, 13 Nov 2008 18:50:16 +0200 (EET) Message-Id: From: Christian Vogt To: SAVI Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 13 Nov 2008 18:50:15 +0200 X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 13 Nov 2008 16:50:16.0915 (UTC) FILETIME=[E7E8B230:01C945AF] X-Brightmail-Tracker: AAAAAA== Subject: [savi] Summary Document on SAVI Design Decisions So Far 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, 13 Nov 2008 16:51:30 -0000 Dear SAVI Folks - Over the past weeks, the SAVI working group made important decisions regarding the design of its solutions. I have captured the discussion and related conclusions in the document linked below, as guidance and as a reference for the subsequent design process. http://users.piuha.net/chvogt/pub/2008/draft-vogt-savi-rationale-00.txt The document will evolve as the design process in the SAVI working group continues. So any feedback will be very welcome, be it before or after the IETF meeting. - Christian From christian.vogt@ericsson.com Thu Nov 13 10:21:43 2008 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 DC3043A6966 for ; Thu, 13 Nov 2008 10:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.968 X-Spam-Level: X-Spam-Status: No, score=-5.968 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 Xt1KDMnsPKAi for ; Thu, 13 Nov 2008 10:21:43 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id DF4E83A6949 for ; Thu, 13 Nov 2008 10:21:42 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0124E20267; Thu, 13 Nov 2008 19:20:41 +0100 (CET) X-AuditID: c1b4fb3e-ab77fbb00000537b-93-491c6ff9fac6 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DA7CE20014; Thu, 13 Nov 2008 19:20:41 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 19:20:42 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 19:20:41 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 70D8F2460; Thu, 13 Nov 2008 20:20:41 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 58C214DBE9; Thu, 13 Nov 2008 20:20:41 +0200 (EET) Message-Id: <0E92243D-7B0A-450D-816C-31410A6B342D@ericsson.com> From: Christian Vogt To: SAVI Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 13 Nov 2008 20:20:41 +0200 X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 13 Nov 2008 18:20:41.0941 (UTC) FILETIME=[8979F850:01C945BC] X-Brightmail-Tracker: AAAAAA== Subject: [savi] Protection for Unused IP Addresses? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2008 18:21:43 -0000 Folks, one design question for SAVI that we haven't explicitly addressed so far is whether SAVI should prevent the spoofing of unused IP addresses. I would like to solicit your comments on this topic. Please consider both, the benefits and the costs, which the protection of unused IP addresses would yield or entail, respectively. Note that there are good arguments for both approaches: Preventing spoofing of unused IP addresses will certainly help combating DDoS attacks. OTOH, it has the disadvantage that it may make a SAVI solution more complex. Also, in IPv6, the ability for hosts to obtain a new IP address autonomously (via SLAAC) reduces the benefit of protecting unused IP addresses, because an unused IP address can easily be turned into a used one. Comments and thoughts are welcome. - Christian From xiayangsong@huawei.com Thu Nov 13 10:33:24 2008 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 D79123A69D6 for ; Thu, 13 Nov 2008 10:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7D2ad2kkkKSX for ; Thu, 13 Nov 2008 10:33:19 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 5EA703A69CE for ; Thu, 13 Nov 2008 10:33:18 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KAA00M11BJIIC@usaga04-in.huawei.com> for savi@ietf.org; Thu, 13 Nov 2008 12:33:18 -0600 (CST) Received: from X24512z ([10.124.12.63]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KAA00J3KBJHXR@usaga04-in.huawei.com> for savi@ietf.org; Thu, 13 Nov 2008 12:33:18 -0600 (CST) Date: Thu, 13 Nov 2008 12:33:16 -0600 From: Frank Xia To: Christian Vogt , SAVI Mailing List Message-id: <000901c945be$4bee21d0$3f0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [savi] Summary Document on SAVI Design Decisions So Far 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, 13 Nov 2008 18:33:24 -0000 Hi Christian Something is not clear to me. Here are the quoted texts " On the other hand, a disadvantage of class (1) is that SAVI may erroneously discard legitimate packets. This happens when a host sends a packet to a neighbor via the local router instead of sending it to the neighbor directly. The packet is then dropped when forwarded by the local router because it is considered a first-hop packet based on the subnet prefix of its source address. " What is the criteria to drop the packtes? Based on source address, the router can only decide if it is the first-hop packet or not. BR Frank ----- Original Message ----- From: "Christian Vogt" To: "SAVI Mailing List" Sent: Thursday, November 13, 2008 10:50 AM Subject: [savi] Summary Document on SAVI Design Decisions So Far > Dear SAVI Folks - > > Over the past weeks, the SAVI working group made important decisions > regarding the design of its solutions. I have captured the discussion > and related conclusions in the document linked below, as guidance and as > a reference for the subsequent design process. > > http://users.piuha.net/chvogt/pub/2008/draft-vogt-savi-rationale-00.txt > > The document will evolve as the design process in the SAVI working group > continues. So any feedback will be very welcome, be it before or after > the IETF meeting. > > - Christian > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From christian.vogt@ericsson.com Thu Nov 13 10:55:24 2008 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 DC8383A6977 for ; Thu, 13 Nov 2008 10:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 J7NJCIrf29rb for ; Thu, 13 Nov 2008 10:55:24 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id B4FA73A6962 for ; Thu, 13 Nov 2008 10:55:23 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C93F42045C; Thu, 13 Nov 2008 19:55:22 +0100 (CET) X-AuditID: c1b4fb3c-b00d2bb0000015b5-68-491c781a19de Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7D42820576; Thu, 13 Nov 2008 19:55:22 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 19:55:22 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 19:55:21 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9394B24C0; Thu, 13 Nov 2008 20:55:21 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 711FF4DBE9; Thu, 13 Nov 2008 20:55:21 +0200 (EET) From: Christian Vogt To: Frank Xia In-Reply-To: <000901c945be$4bee21d0$3f0c7c0a@china.huawei.com> X-Priority: 3 References: <000901c945be$4bee21d0$3f0c7c0a@china.huawei.com> Message-Id: <706A10C9-7534-4DAD-9B68-D332DDA4CCD0@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 13 Nov 2008 20:55:21 +0200 X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 13 Nov 2008 18:55:21.0857 (UTC) FILETIME=[6133F710:01C945C1] X-Brightmail-Tracker: AAAAAA== Cc: SAVI Mailing List Subject: Re: [savi] Summary Document on SAVI Design Decisions So Far 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, 13 Nov 2008 18:55:24 -0000 Frank, the scenario here is that the SAVI device is implemented on a switch that connects the router with the packet recipient. Therefore, the SAVI device, when receiving the packet from the router, believes that the router is spoofing the IP source address of the sending host. You are right; this should be clarified in the text. - Christian On Nov 13, 2008, Frank Xia wrote: > Hi Christian > > Something is not clear to me. > > Here are the quoted texts " On the other hand, a disadvantage of > class (1) is that SAVI may > erroneously discard legitimate packets. This happens when a host > sends a packet to a neighbor via the local router instead of sending > it to the neighbor directly. The packet is then dropped when > forwarded by the local router because it is considered a first-hop > packet based on the subnet prefix of its source address. " > > What is the criteria to drop the packtes? > Based on source address, the router can only decide if it > is the first-hop packet or not. > BR > Frank From christian.vogt@ericsson.com Thu Nov 13 12:17:22 2008 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 A85673A6963 for ; Thu, 13 Nov 2008 12:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.972 X-Spam-Level: X-Spam-Status: No, score=-5.972 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 tmugPohDy5Gf for ; Thu, 13 Nov 2008 12:17:21 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C76AC3A6405 for ; Thu, 13 Nov 2008 12:17:21 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AC55E20430; Thu, 13 Nov 2008 21:17:20 +0100 (CET) X-AuditID: c1b4fb3c-af8d1bb0000015b5-6f-491c8b502266 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8D2E820006; Thu, 13 Nov 2008 21:17:20 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 21:17:20 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 21:17:18 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 93F6924C0; Thu, 13 Nov 2008 22:17:17 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6F7264DBE9; Thu, 13 Nov 2008 22:17:17 +0200 (EET) Message-Id: <5C979E3E-1CA3-4F45-AA34-D20F7B58536A@ericsson.com> From: Christian Vogt To: SAVI Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 13 Nov 2008 22:17:17 +0200 X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 13 Nov 2008 20:17:18.0185 (UTC) FILETIME=[D3901590:01C945CC] X-Brightmail-Tracker: AAAAAA== Subject: [savi] SAVI Meeting Agenda for IETF 73 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, 13 Nov 2008 20:17:22 -0000 Dear SAVI Folks, below the agenda for our upcoming meeting in Minneapolis. CU soon, Christian ----------------------------------------------------------- Agenda of the SAVI working group meeting at IETF 73 Monday, November 17, 2008, 9:00 am - 11:30 am, Salon AB ----------------------------------------------------------- Introduction and agenda bashing 9:00 am Bill Fenner and Christian Vogt Summary of design decisions so far 9:10 am Christian Vogt First-come-first-serve SAVI for IPv4 + IPv6 9:30 am Marcelo Bagnulo SAVI for IPv6 Secure Neighbor Discovery 10:00 am Marcelo Bagnulo Thoughts about SAVI in Ethernet-based broadband 10:30 am David Miles and Wojciech Dec SAVI scenarios and solution space 11:00 am Jun Bi end at 11:30 am From christian.vogt@ericsson.com Thu Nov 13 12:40:52 2008 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 4EBAD3A69CE for ; Thu, 13 Nov 2008 12:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 uaF41jophm6P for ; Thu, 13 Nov 2008 12:40:51 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 241053A68BA for ; Thu, 13 Nov 2008 12:40:47 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8D7B320505 for ; Thu, 13 Nov 2008 21:40:46 +0100 (CET) X-AuditID: c1b4fb3e-aaf7ebb00000537b-b4-491c90ce9f3b Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7658820124 for ; Thu, 13 Nov 2008 21:40:46 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 21:40:46 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 21:40:45 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D7A4524C0 for ; Thu, 13 Nov 2008 22:40:45 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C61C74DBE9 for ; Thu, 13 Nov 2008 22:40:45 +0200 (EET) Message-Id: <74CCF69D-7022-4EE2-9078-87BB23AE727C@ericsson.com> From: Christian Vogt To: SAVI Mailing List In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 13 Nov 2008 22:40:45 +0200 References: <5AFF2C66-D235-4A69-9312-C22F03F94991@ericsson.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 13 Nov 2008 20:40:45.0976 (UTC) FILETIME=[1AABF180:01C945D0] X-Brightmail-Tracker: AAAAAA== Subject: Re: [savi] Request to IESG: Additional SAVI working group documents 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, 13 Nov 2008 20:40:52 -0000 Christian Vogt wrote: > FYI: We have requested from IESG the addition of a Rationale > document and > a SeND-based Solution document to the SAVI charter. [...] ...and we got both. Here are the new milestones from the SAVI charter: [...] Dec 2008 First WG draft on SAVI solution rationale Dec 2008 First WG draft on SeND-based SAVI extension [...] May 2009 Submit SAVI solution rationale to IESG for Informational RFC May 2009 Submit SeND-based SAVI extension to IESG for Informational RFC [...] - Christian From christian.vogt@ericsson.com Fri Nov 14 02:37:27 2008 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 13C133A6A3F for ; Fri, 14 Nov 2008 02:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.014 X-Spam-Level: X-Spam-Status: No, score=-6.014 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 0R7w3eZVrVxg for ; Fri, 14 Nov 2008 02:37:26 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4A4B23A6A34 for ; Fri, 14 Nov 2008 02:37:26 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6829C201CF for ; Fri, 14 Nov 2008 11:37:25 +0100 (CET) X-AuditID: c1b4fb3e-aaf7ebb00000537b-90-491d54e5c29f Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 515FE20138 for ; Fri, 14 Nov 2008 11:37:25 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Nov 2008 11:37:25 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Nov 2008 11:37:24 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9B9082339 for ; Fri, 14 Nov 2008 12:37:24 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8740E4DBE9 for ; Fri, 14 Nov 2008 12:37:24 +0200 (EET) Message-Id: <453B6DEA-7DEB-4200-9E2C-1928EC7ACEC1@ericsson.com> From: Christian Vogt To: SAVI Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 14 Nov 2008 12:37:23 +0200 X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 14 Nov 2008 10:37:24.0814 (UTC) FILETIME=[FB82BEE0:01C94644] X-Brightmail-Tracker: AAAAAA== Subject: [savi] Minute Takers for Monday? 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, 14 Nov 2008 10:37:27 -0000 Any volunteers for taking minutes at the SAVI meeting on Monday? - Christian From xiayangsong@huawei.com Sat Nov 15 19:44:28 2008 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 F1DD33A680D for ; Sat, 15 Nov 2008 19:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBpAKbFfM2bl for ; Sat, 15 Nov 2008 19:44:23 -0800 (PST) Received: from nlpi087.prodigy.net (nlpi087.prodigy.net [207.115.36.103]) by core3.amsl.com (Postfix) with ESMTP id ECBEA3A681A for ; Sat, 15 Nov 2008 19:44:22 -0800 (PST) X-ORBL: [70.244.165.249] Received: from X24512z (ppp-70-244-165-249.dsl.rcsntx.swbell.net [70.244.165.249]) by nlpi087.prodigy.net (8.13.8 out.ldap.dk.spool/8.13.8) with ESMTP id mAG3iHPd018094; Sat, 15 Nov 2008 21:44:20 -0600 Message-ID: <009001c9479d$9ac662a0$0501a8c0@china.huawei.com> From: "Frank Xia" To: "Christian Vogt" , "SAVI Mailing List" References: <5C979E3E-1CA3-4F45-AA34-D20F7B58536A@ericsson.com> Date: Sat, 15 Nov 2008 21:44:15 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: Re: [savi] SAVI Meeting Agenda for IETF 73 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2008 03:44:29 -0000 Hi Folks We prepared a contribution for IETF and Broadband Forum, unfortunately, we missed the submission cutoff time. Here is the weblink: http://www-etud.iro.umontreal.ca/~sarikaya/drafts/draft-kaippallimalil-savi-ipv6-bbnet-00.txt Comments are very welcome. BR Frank ----- Original Message ----- From: "Christian Vogt" To: "SAVI Mailing List" Sent: Thursday, November 13, 2008 2:17 PM Subject: [savi] SAVI Meeting Agenda for IETF 73 > Dear SAVI Folks, > > below the agenda for our upcoming meeting in Minneapolis. > > CU soon, Christian > > > ----------------------------------------------------------- > Agenda of the SAVI working group meeting at IETF 73 > Monday, November 17, 2008, 9:00 am - 11:30 am, Salon AB > ----------------------------------------------------------- > > Introduction and agenda bashing 9:00 am > Bill Fenner and Christian Vogt > > Summary of design decisions so far 9:10 am > Christian Vogt > > First-come-first-serve SAVI for IPv4 + IPv6 9:30 am > Marcelo Bagnulo > > SAVI for IPv6 Secure Neighbor Discovery 10:00 am > Marcelo Bagnulo > > Thoughts about SAVI in Ethernet-based broadband 10:30 am > David Miles and Wojciech Dec > > SAVI scenarios and solution space 11:00 am > Jun Bi > > end at 11:30 am > > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From christian.vogt@ericsson.com Sun Nov 16 11:06:09 2008 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 750613A6905 for ; Sun, 16 Nov 2008 11:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.031 X-Spam-Level: X-Spam-Status: No, score=-6.031 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 oVomXVMWmTiy for ; Sun, 16 Nov 2008 11:06:08 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 888443A6904 for ; Sun, 16 Nov 2008 11:06:08 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F22B42012A; Sun, 16 Nov 2008 20:06:06 +0100 (CET) X-AuditID: c1b4fb3e-aff88bb00000537b-84-49206f1e5c24 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D5B112018A; Sun, 16 Nov 2008 20:06:06 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Nov 2008 20:06:06 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Nov 2008 20:06:06 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2AB332460; Sun, 16 Nov 2008 21:06:06 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9F4CE4DBE9; Sun, 16 Nov 2008 21:06:05 +0200 (EET) Message-Id: <9C80276B-9B9B-429E-8F8C-8BC3FA8B3C9B@ericsson.com> From: Christian Vogt To: marcelo bagnulo braun In-Reply-To: <490B1CA1.7010103@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 16 Nov 2008 13:06:04 -0600 References: <29B0AB6A-A250-427F-BFBB-AF63D405D633@nomadiclab.com> <490ACD36.4000700@it.uc3m.es> <490ADEE7.6080505@it.uc3m.es> <4FFCABE7-BB56-4EE2-8F79-4225A2DC358D@nomadiclab.com> <490AFC77.5000601@it.uc3m.es> <490B1CA1.7010103@it.uc3m.es> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 16 Nov 2008 19:06:06.0425 (UTC) FILETIME=[60A27C90:01C9481E] X-Brightmail-Tracker: AAAAAA== Cc: SAVI Mailing List Subject: Re: [savi] Identifying First-Hop Vs. Forwarded Traffic X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2008 19:06:09 -0000 On Oct 31, 2008, marcelo bagnulo braun wrote: >> The reason I am saying that approach (1) is "opt-in" is this: Before >> the attack, the SAVI device does not even perform any validation at >> all. > > what do you mean? AFAIU, the SAVI device by default drops all the > packets except those coming with a source address containing one of > the > on-link prefixes. So a SAVI device by default drops all packets from off-link prefixes? But the validation of these packets is exactly what we want to leave to ingress filtering, right? Then, since we leave to ingress filtering the validation of packets with off-link prefixes, the SAVI device should let these packets pass IMO. - Christian From marcelo@it.uc3m.es Sun Nov 16 12:51:00 2008 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 6BACD3A67AA for ; Sun, 16 Nov 2008 12:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.762 X-Spam-Level: X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 JZ8oQhWOEPyy for ; Sun, 16 Nov 2008 12:50:59 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 5826A3A6405 for ; Sun, 16 Nov 2008 12:50:59 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [130.129.31.6])by smtp02.uc3m.es (Postfix) with ESMTP id 856065CB84F;Sun, 16 Nov 2008 21:50:56 +0100 (CET) Message-ID: <491D8C0B.9080501@it.uc3m.es> Date: Fri, 14 Nov 2008 15:32:43 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Christian Vogt , SAVI Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-12.6915 TC:1F TRN:31 TV:5.5.1026(16284.001) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [savi] about draft-vogt-savi-rationale-00.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: Sun, 16 Nov 2008 20:51:00 -0000 Hi Christain, i think the document is a very good starting point to document the desig choices we are making. Some comments below... The abstract reads: The IETF working group on Source Address Validation Improvements, SAVI, is chartered to design methods for IP source address validation that complement ingress filtering with finer-grained protection. Not that i am disagreeing here, but it seems from the phrasing that this was decided in the charter, while i understand that the choice of relying on ingress filtering was a design choice made by the wg i.e. it ia conclusion rather than a starting point. Later on, 3. Packet Classification The prerequisite that a SAVI solution should be complementary to ingress filtering, and not substitute it, implies that SAVI should not validate packets that are forwarded by routers. This calls for a method for SAVI to classify first-hop packets from forwarded packets (where "first-hop packets" are transmitted by the originating host, and "forwarded packets" are relayed by a router). Techniques to achieve such packet classification can be divided into the following classes: 1. Packets are classified based on whether or not their source address is from an on-link subnet prefix. 2. Packets are classified based on whether or not the sending node is an authorized router. i think that in any case we need both. I mean, we need the list of onlink prefixes, if not SAVI does not know which source addresses can be generated by onlink nodes We need the list of routers cause if not we don't know which of the directly connected devices can generate packets with off-link source addresses. I am don't see how you can build a savi solution with only one of those I don't see these as one or the other, but i think you need one _and_ the other. Besides, i found the following typos in the document (perform a search for these) scurity EIn EOr Regards, marcelo From junbi@cernet.edu.cn Sun Nov 16 23:12:00 2008 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 BCB403A6774 for ; Sun, 16 Nov 2008 23:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.493 X-Spam-Level: * X-Spam-Status: No, score=1.493 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696, MIME_QP_LONG_LINE=1.396] 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 dZW6LkF5Wlgc for ; Sun, 16 Nov 2008 23:11:59 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id BB9813A6811 for ; Sun, 16 Nov 2008 23:11:57 -0800 (PST) Received: from userPC([130.129.78.238]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm549213101; Mon, 17 Nov 2008 15:11:54 +0800 Message-ID: <3D3D6E8E96654BAAB02AC5EA51243DA0@userPC> From: "Jun Bi" To: References: <5C979E3E-1CA3-4F45-AA34-D20F7B58536A@ericsson.com> <009001c9479d$9ac662a0$0501a8c0@china.huawei.com> In-Reply-To: <009001c9479d$9ac662a0$0501a8c0@china.huawei.com> Date: Mon, 17 Nov 2008 01:11:11 -0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_029E_01C94851.61269880" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: NeERyBVB Subject: Re: [savi] SAVI Meeting Agenda for IETF 73 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, 17 Nov 2008 07:12:00 -0000 ÕâÊÇ MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_029E_01C94851.61269880 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit Dear SAVI Folks, The attached file is the SAVI scenarios draft. Here the term "lower layer mobility" presents all the situations including changing ports, moving form one AP to another AP, and some special situations such as multiple links per host, multiple MAC addresses per link, etc. Best Regards, Jun Bi > ----- Original Message ----- > From: "Christian Vogt" > To: "SAVI Mailing List" > Sent: Thursday, November 13, 2008 2:17 PM > Subject: [savi] SAVI Meeting Agenda for IETF 73 > > >> Dear SAVI Folks, >> >> below the agenda for our upcoming meeting in Minneapolis. >> >> CU soon, Christian >> >> >> ----------------------------------------------------------- >> Agenda of the SAVI working group meeting at IETF 73 >> Monday, November 17, 2008, 9:00 am - 11:30 am, Salon AB >> ----------------------------------------------------------- >> >> Introduction and agenda bashing 9:00 am >> Bill Fenner and Christian Vogt >> >> Summary of design decisions so far 9:10 am >> Christian Vogt >> >> First-come-first-serve SAVI for IPv4 + IPv6 9:30 am >> Marcelo Bagnulo >> >> SAVI for IPv6 Secure Neighbor Discovery 10:00 am >> Marcelo Bagnulo >> >> Thoughts about SAVI in Ethernet-based broadband 10:30 am >> David Miles and Wojciech Dec >> >> SAVI scenarios and solution space 11:00 am >> Jun Bi >> >> end at 11:30 am >> >> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > > ------=_NextPart_000_029E_01C94851.61269880 Content-Type: text/plain; format=flowed; name="draft-wu-savi-Scenarios-00.txt"; reply-type=response Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-wu-savi-Scenarios-00.txt" Source Address Validation Improvements J. Wu, J. Bi, G. Yao =0A= Internet Draft CERNET =0A= Intended status: Informational =0A= Expires: May 2009 November 17, 2008 =0A= =0A= =0A= =0A= Considerations on SAVI Scenarios and Solutions Space =0A= draft-wu-savi-Scenarios-00.txt =0A= =0A= =0A= Status of this Memo =0A= =0A= By submitting this Internet-Draft, each author represents that =0A= any applicable patent or other IPR claims of which he or she is =0A= aware have been or will be disclosed, and any of which he or she = =0A= becomes aware will be disclosed, in accordance with Section 6 of = =0A= BCP 79. =0A= =0A= This document may not be modified, and derivative works of it may not =0A= be created, except to publish it as an RFC and to translate it into =0A= languages other than English. =0A= =0A= Internet-Drafts are working documents of the Internet Engineering =0A= Task Force (IETF), its areas, and its working groups. Note that =0A= other groups may also distribute working documents as = Internet-Drafts. =0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months =0A= and may be updated, replaced, or obsoleted by other documents at any =0A= time. It is inappropriate to use Internet-Drafts as reference =0A= material or to cite them other than as "work in progress." =0A= =0A= The list of current Internet-Drafts can be accessed at =0A= http://www.ietf.org/ietf/1id-abstracts.txt =0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at =0A= http://www.ietf.org/shadow.html =0A= =0A= This Internet-Draft will expire on May 17, 2009. =0A= =0A= Abstract =0A= =0A= This document describes the Scenarios may appear in SAVI deployment. =0A= These Scenarios are intent to help design the SAVI solution. Possible =0A= solutions for some Scenarios are also given. =0A= =0A= =0A= =0A= =0A= =0A= =0A= Wu Expires May 17, 2009 [Page 1] =0A= =0C=0A= Internet-Draft Situations in SAVI November 2008 =0A= =0A= =0A= Table of Contents =0A= =0A= =0A= 1. Introduction ................................................ 2 =0A= 2. Conventions used in this document............................ 3 =0A= 3. Scenarios ................................................... 3 =0A= 3.1. Address Allocation Methods.............................. 3 =0A= 3.2. Secure Lower Layer...................................... 3 =0A= 3.3. Lower Layer Mobility.................................... 4 =0A= 3.4. Host change ............................................ 4 =0A= 3.5. Other elements ......................................... 4 =0A= 4. Possible Solution Space...................................... 5 =0A= 5. Deployment Approaches........................................ 7 =0A= 6. Security Considerations...................................... 8 =0A= 7. IANA Considerations ......................................... 8 =0A= 8. Conclusions ................................................. 8 =0A= 9. Acknowledgments ............................................. 8 =0A= 10. References ................................................. 9 =0A= 10.1. Normative References................................... 9 =0A= 10.2. Informative References................................. 9 =0A= =0A= 1. Introduction =0A= =0A= The charter of SAVI puts forward a number of requirements for =0A= possible SAVI solutions. Some of the requirements are not easy to =0A= meet, and it is most possible that there can be only a flexible but =0A= complex method that has the ability to suit all the environments. =0A= However, a solution with wide usability but great cost and complexity =0A= is not the very solution in a lot of common Scenarios, e.g., a fixed =0A= switch LAN with strict one-one mapping from host to port. =0A= =0A= Design solutions for each specified environment is a good start = point. =0A= Requirements charter actually point out most possible elements that =0A= impact source address validation. Some of those network elements =0A= affect the SAVI solution greatly, and those critical can be used to =0A= devise possible scenarios. Based on the consensus of SAVI discussion, =0A= it is not necessary for one solution to cover all scenarios. SAVI may =0A= design the most proper solution for each scenario and recommend =0A= deployment approaches to network administrators for use with SAVI. =0A= =0A= Strict security is important for source address validation, which =0A= means a host can never successfully send a packet with an =0A= unauthorized source address ("unauthorized" means the address is not =0A= assigned by the appointed address allocation method). However, there =0A= are some scenarios in which no strict security can be achieved, =0A= unless host change. In these scenarios, a solution that improves the =0A= security of source address at utmost and a solution that employs host =0A= =0A= =0A= Wu Expires May 17, 2009 [Page 2] =0A= =0C=0A= Internet-Draft Situations in SAVI November 2008 =0A= =0A= =0A= change to achieve strict security are competitive. It is suggested =0A= that the tradeoff between weak security and host change should be =0A= left for the administrator of each specified network when use of = SAVI. =0A= =0A= 2. Conventions used in this document =0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", =0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this =0A= document are to be interpreted as described in RFC-2119. =0A= =0A= 3. Scenarios =0A= =0A= 3.1. Address Allocation Methods =0A= =0A= Address allocation method determines the assignment of the ownership =0A= of a specified address, and the meaning of IP spoofing in the = network. =0A= The SAVI device will not care much about how the address is generated =0A= (privacy, cryptographically, or directly), but much more about who =0A= will get the ownership of an appearing address. Following address =0A= allocation methods distinguish different scenarios: =0A= =0A= 1. Stateless: Ownership is assigned according to the principle "First =0A= Come, First Served"; =0A= =0A= 2. DHCP: Ownership is assigned by DHCP server using DHCP protocol; =0A= =0A= 3. Manual Configuration: Ownership is assigned previously and =0A= statically; =0A= =0A= 4. SeND: Although SeND is a FCFS mechanism, it is different from =0A= plain ND when acting in source address validation. =0A= =0A= 3.2. Secure Lower Layer =0A= =0A= The validation of IP source address must rely on other source of =0A= trust. In layer-2 and layer-1, there are some reliable elements. For =0A= example, the switch port and the secure layer-2 address are the =0A= natural anchors for binding the source address. =0A= =0A= If the lower layer used in binding is port and MAC address, note that =0A= only the following scenarios can be considered having secure lower =0A= layer: =0A= =0A= o A Port is exclusive for one host; =0A= =0A= o A Port is shared, but MAC address is unspoofable (by some link =0A= layer security mechanism). =0A= =0A= =0A= Wu Expires May 17, 2009 [Page 3] =0A= =0C=0A= Internet-Draft Situations in SAVI November 2008 =0A= =0A= =0A= There may be other natural secure lower layers and binding IP address =0A= to them will achieve the same effect. =0A= =0A= Values of element "Secure Lower Layer": =0A= =0A= Yes: All the lower layers in the network are secure. For instance, =0A= exclusive switch port or unspoofable MAC address. =0A= =0A= No: Not all the lower layers in the network are secure. For instance, =0A= shared switch port, hub, and wireless AP. =0A= =0A= 3.3. Lower Layer Mobility =0A= =0A= A host may change switch port or move from an AP to another AP =0A= without changing IP address. =0A= =0A= Values of element "Lower Layer Mobility": =0A= =0A= Yes: need to support lower layer mobility. =0A= =0A= No: don't need to support lower layer mobility. =0A= =0A= 3.4. Host change =0A= =0A= There will surely be a lot of controversy on host change. Host change =0A= is not allowed in current charter, but host change will allow a most =0A= secure and efficient mechanism in some scenarios that no strict =0A= security can be achieved. We think we can calm the argument on host =0A= change by this way: no host change is considered firstly, and if no =0A= mechanism is able to achieve strict security, a host change mechanism =0A= can be given as a reference to the network administrators. =0A= =0A= 3.5. Other elements =0A= =0A= Many other elements are considered in the charter. This section =0A= explains why these elements are not used in this study. =0A= =0A= o Multiple addresses on one interface =0A= =0A= Generally, it is not hard for a mechanism to handle this scenario. A =0A= mechanism can just increase the entry number in the binding table. =0A= =0A= o Multiple link layer addresses on one interface =0A= =0A= This element will only trouble the mechanisms using link layer =0A= address in binding. If a mechanism uses the binding between link =0A= layer address and IP address to verify packets, it must assure that =0A= =0A= =0A= Wu Expires May 17, 2009 [Page 4] =0A= =0C=0A= Internet-Draft Situations in SAVI November 2008 =0A= =0A= =0A= link layer address is unspoofable. Thus, a network can only have a =0A= number of fixed link layer addresses during a time. =0A= =0A= In a fixed network, the link layer addresses are definite, and the =0A= mechanism can record all the link layer addresses owned by one =0A= interface or host, and bind all the link layer address to the =0A= assigned IP address. =0A= =0A= In a network with frequent host adding and removing, this scenario =0A= can be regarded the same as the "Lower Layer Mobility". An interface =0A= using multiple link layer addresses actually can be regarded as =0A= frequently changing between link layer addresses. This means, if a =0A= solution can handle "Lower Layer Mobility", a similar solution can be =0A= designed for "Multiple link layer addresses", using link layer =0A= address to replace port. =0A= =0A= o Multiple interfaces to the same link =0A= =0A= If all the interfaces are connected to a port, it can be regarded the =0A= same as "Multiple addresses on one interface". A simple binding with =0A= multiple entries can handle this scenario. =0A= =0A= If the interfaces are connected to different ports, it can be =0A= regarded the same as "Multiple link layer addresses". This means, if =0A= these interface are connected to fixed ports, it can be handled by =0A= configuration; if these interfaces are connected to changeable ports, =0A= a solution handle "lower layer mobility" can handle this scenario, =0A= for using multiple ports can be regarded the same as frequently =0A= changing between ports. =0A= =0A= 4. Possible Solution Space =0A= =0A= There are possibly three kinds of solutions: =0A= =0A= 1. Static Lower Layer Binding (SLLB): =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Wu Expires May 17, 2009 [Page 5] =0A= =0C=0A= Internet-Draft Situations in SAVI November 2008 =0A= =0A= =0A= The address is bound with lower layer when the address is =0A= allocated. The binding association changing, such as lower layer =0A= mobility or supporting the multiple lower layer entities (MAC, =0A= interface), is not considered to be supported. When a host changes =0A= its lower layer in association, it cannot keep it original IP address =0A= and must re-allocate an IP address. [draft-baker-sava-cisco-ip-=0A= source-guard-00.txt], [draft-bagnulo-savi-fcfs-00.txt] and [draft-wu-=0A= sava-solution-firsthop-eap-01.txt]are examples of this kind. This =0A= kind of solution is the most cost-effective way. Although currently =0A= there is no one solution to support all IPv6 address assignment =0A= methods, but it's feasible to have one unified static binding =0A= solution for all address assignment situations in SAVI future work. =0A= =0A= 2. Dynamic Lower Layer Binding (DLLB): =0A= =0A= The address is bound with lower layer when the address is =0A= allocated, and once the binding association is changed (e.g. =0A= mobility), some protocol can be used to set up new binding and the =0A= original IP address can be kept. [draft-bagnulo-savi-send-00] is an =0A= example of this kind. SEND-Extension and HIP-SAVI are other =0A= alternatives. In addition, if the security of link layer address is =0A= assured by some cryptographic method, the key bound with the link =0A= layer address can also be used to rebuild the binding. In SAVI future =0A= work, it's feasible to enhance and devise a solution to covers all =0A= address assignment situations. Moreover, a low cost solution without =0A= evolving SEND/HIP need to be further investigated. =0A= =0A= SEND-Extension is a solution that extends SeND protocol to handle =0A= other address allocation methods. =0A= =0A= HIP-SAVI is a solution that employs HIP to handle the mobility of =0A= lower layer. =0A= =0A= 3. Lightweight Cryptographic Method based ID Binding (IDB) =0A= =0A= When the lower layer binding is not secure, the IP address could =0A= be bound with some secret associated with a host identifier in =0A= packets. This will involve some degree of host change. [draft-bi-=0A= savi-csa-00.txt] is an example of this kind. SEND-CSA and a HIP-CSA =0A= are other alternatives to minimize the host change in SAVI future =0A= work. =0A= =0A= SEND-CSA is a solution that uses SeND similar protocol to replace =0A= the phase 1 of CSA, and uses MD5 hash to generate tags in phase 2. =0A= =0A= HIP-CSA is a solution that uses HIP to replace the phase 1 of CSA. =0A= =0A= =0A= =0A= Wu Expires May 17, 2009 [Page 6] =0A= =0C=0A= Internet-Draft Situations in SAVI November 2008 =0A= =0A= =0A= 5. Deployment Approaches =0A= =0A= In this section, all the scenarios are given and the current possible =0A= solutions are discussed. =0A= =0A= = =0A= +------------------+------------------+-------------------+ =0A= | | | | =0A= | | | | =0A= +------------------+------------------+-------------------+ =0A= | | | | =0A= | |SLLB | No Need | =0A= | | | | =0A= | | | | =0A= +------------------+------------------+-------------------+ =0A= | | | | =0A= | | | | =0A= | |DLLB | No Need | =0A= | | | | =0A= | | | | =0A= | | | | =0A= +------------------+------------------+-------------------+ =0A= | | | | =0A= | |No Solution yet, | IDB | =0A= | |unless host change| | =0A= | |is allowed | | =0A= | | | | =0A= +------------------+------------------+-------------------+ =0A= | | | | =0A= | |No Solution yet, | IDB | =0A= | |unless host change| | =0A= | |is allowed | | =0A= | | | | =0A= | | | | =0A= +------------------+------------------+-------------------+ =0A= Figure 1 Scenario and Solution Table =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Wu Expires May 17, 2009 [Page 7] =0A= =0C=0A= Internet-Draft Situations in SAVI November 2008 =0A= =0A= =0A= 6. Security Considerations =0A= =0A= 7. IANA Considerations =0A= =0A= 8. Conclusions =0A= =0A= 9. Acknowledgments =0A= =0A= Thanks to Christian Vogt, Fred Baker, Jari Arkko, David Harrington, =0A= Marcelo Bagnulo Braun, Pekka Savola, Xing Li, Lixia Zhang, Robert =0A= Raszuk, Tao Lin and Dong Zhang for their valuable contributions. =0A= =0A= This document was prepared using 2-Word-v2.0.template.dot. =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Wu Expires May 17, 2009 [Page 8] =0A= =0C=0A= Internet-Draft Situations in SAVI November 2008 =0A= =0A= =0A= 10. References =0A= =0A= 10.1. Normative References =0A= =0A= 10.2. Informative References =0A= =0A= Author's Addresses =0A= =0A= Jianping Wu =0A= CERNET =0A= Computer Science, Tsinghua University =0A= Beijing 100084 =0A= China =0A= Email: jianping@cernet.edu.cn =0A= =0A= =0A= Jun Bi =0A= CERNET =0A= Network Research Center, Tsinghua University =0A= Beijing 100084 =0A= China =0A= Email: junbi@cernet.edu.cn =0A= =0A= =0A= Guang Yao =0A= CERNET =0A= Network Research Center, Tsinghua University =0A= Beijing 100084 =0A= China =0A= Email: yaog@netarchlab.tsinghua.edu.cn =0A= =0A= =0A= Full Copyright Statement =0A= =0A= Copyright (C) The IETF Trust (2008). =0A= =0A= This document is subject to the rights, licenses and restrictions =0A= contained in BCP 78, and except as set forth therein, the authors =0A= retain all their rights. =0A= =0A= This document and the information contained herein are provided on an =0A= "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS =0A= OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND =0A= THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS =0A= OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF =0A= THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED =0A= WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. =0A= =0A= =0A= Wu Expires May 17, 2009 [Page 9] =0A= =0C=0A= Internet-Draft Situations in SAVI November 2008 =0A= =0A= =0A= Intellectual Property Statement =0A= =0A= The IETF takes no position regarding the validity or scope of any =0A= Intellectual Property Rights or other rights that might be claimed to =0A= pertain to the implementation or use of the technology described in =0A= this document or the extent to which any license under such rights =0A= might or might not be available; nor does it represent that it has =0A= made any independent effort to identify any such rights. Information =0A= on the procedures with respect to rights in RFC documents can be =0A= found in BCP 78 and BCP 79. =0A= =0A= Copies of IPR disclosures made to the IETF Secretariat and any =0A= assurances of licenses to be made available, or the result of an =0A= attempt made to obtain a general license or permission for the use of =0A= such proprietary rights by implementers or users of this =0A= specification can be obtained from the IETF on-line IPR repository at =0A= http://www.ietf.org/ipr. =0A= =0A= The IETF invites any interested party to bring to its attention any =0A= copyrights, patents or patent applications, or other proprietary =0A= rights that may cover technology that may be required to implement =0A= this standard. Please address the information to the IETF at =0A= ietf-ipr@ietf.org. =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Wu Expires May 17, 2009 [Page 10] =0A= =0C=0A= ------=_NextPart_000_029E_01C94851.61269880-- From pekkas@netcore.fi Tue Nov 18 11:57:58 2008 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 5985D28C15F for ; Tue, 18 Nov 2008 11:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=0.239, 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 luQpBuJLxWPO for ; Tue, 18 Nov 2008 11:57:57 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id E4DC728C115 for ; Tue, 18 Nov 2008 11:57:56 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id mAIJvq98006298 for ; Tue, 18 Nov 2008 21:57:52 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id mAIJvpp8006295 for ; Tue, 18 Nov 2008 21:57:52 +0200 Date: Tue, 18 Nov 2008 21:57:51 +0200 (EET) From: Pekka Savola To: savi@ietf.org Message-ID: User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.94.1/8644/Mon Nov 17 23:35:21 2008 on otso.netcore.fi X-Virus-Status: Clean Subject: [savi] FYI: Juniper support for SEND X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2008 19:57:58 -0000 FYI, FWIW, I noticed that the recently released JunOS software (9.3) supports SEND. I guess there must be loud users demanding this feature for it to be implemented. I guess we'll have some hope for SEND after all! However, it seems that certificate discovery etc. is not supported. A SEND-based SAVI solution would probably need this to authorize routers to send off-link traffic. http: //www.juniper.net/techpubs/en_US/junos9.3/information-products/topic-collections/release-notes/9.3/m-mx-t-series-new-features.html http: //www.juniper.net/techpubs/software/junos/junos93/swconfig-routing/secure-neighbor-discovery-configuration-guidelines.html -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From shemant@cisco.com Tue Nov 18 14:01:11 2008 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 274CD28C17E for ; Tue, 18 Nov 2008 14:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.246 X-Spam-Level: X-Spam-Status: No, score=-5.246 tagged_above=-999 required=5 tests=[AWL=1.352, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 2uqw3Xs7KmB9 for ; Tue, 18 Nov 2008 14:01:10 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2A9003A677E for ; Tue, 18 Nov 2008 14:01:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,627,1220227200"; d="scan'208,217";a="28269390" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Nov 2008 22:01:09 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAIM18mY000773 for ; Tue, 18 Nov 2008 17:01:08 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAIM18QI001836 for ; Tue, 18 Nov 2008 22:01:09 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 17:01:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C949C9.2934D7F8" Date: Tue, 18 Nov 2008 17:01:08 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: my feedback on draft-bagnulo-savi-fcfs-00 and IETF73 SAVI meeting Thread-Index: AclJySi9CEo8rVdBTFCLPyEGg9U0sg== From: "Hemant Singh (shemant)" To: X-OriginalArrivalTime: 18 Nov 2008 22:01:08.0938 (UTC) FILETIME=[29724AA0:01C949C9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2211; t=1227045668; x=1227909668; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20my=20feedback=20on=20draft-bagnulo-savi-fcfs-00 =20and=20IETF73=20SAVI=20meeting=20 |Sender:=20 |To:=20; bh=IZ8LaX40bsnWTkEiaLxdPx/rp84yB6aAjOurOVyJOdo=; b=vBrAUQl8C5kgWhO6lUNtRBBIieC+Wp83Bi+rb/kvcmmaZQW3XBlEiTFxWt jZrnayu2NbjZnCxP4CDPMkeKP+QoyZ6wE0FAFYRjLjLau019bu3WHvRXvlfV /dWZlwTHhv; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [savi] my feedback on draft-bagnulo-savi-fcfs-00 and IETF73 SAVI meeting X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2008 22:01:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C949C9.2934D7F8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 DHCPv6 snooping is not sufficient to fix all SAVI problems seen in an IPv6 deployment. Erik Nordmark was correct in the meeting to point out that if a host moves from a switched port A to port B, how does SAVI pick up this change in switched port information because the host may not reinitiate DHCPv6. The NS NUD message described in the fcfs draft is also needed as a solution to catch such host moves. I have yet to read any SAVI draft but going by what was presented in the slides at the meeting, the NS NUD solution is also needed. =20 Hemant ------_=_NextPart_001_01C949C9.2934D7F8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Folks,
 
DHCPv6 = snooping is=20 not sufficient to fix all SAVI problems seen in an IPv6 = deployment.  Erik=20 Nordmark was correct in the meeting to point out that if a host moves = from a=20 switched port A to port B, how does SAVI pick up this change in switched = port=20 information because the host may not reinitiate DHCPv6.  The NS NUD = message=20 described in the fcfs draft is also needed as a solution to catch such = host=20 moves.  I have yet to read any SAVI draft but going by what was = presented=20 in the slides at the meeting, the NS NUD solution is also=20 needed.
 
Hemant
------_=_NextPart_001_01C949C9.2934D7F8-- From zhangdong_rh@huaweisymantec.com Tue Nov 18 18:37:39 2008 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 912CC3A6B47 for ; Tue, 18 Nov 2008 18:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.19 X-Spam-Level: X-Spam-Status: No, score=0.19 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siyI6XaeHx2k for ; Tue, 18 Nov 2008 18:37:36 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id E5B7F3A6B3C for ; Tue, 18 Nov 2008 18:37:35 -0800 (PST) MIME-version: 1.0 Content-disposition: inline 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-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KAK002ZL7AK3840@hstga02-in.huaweisymantec.com> for savi@ietf.org; Wed, 19 Nov 2008 10:37:33 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KAK000M07AI7Z00@hstml02-in.huaweisymantec.com> for savi@ietf.org; Wed, 19 Nov 2008 10:37:32 +0800 (CST) Received: from [221.218.197.165] by hstml02-in.huaweisymantec.com (mshttpd) ; Wed, 19 Nov 2008 10:37:30 +0800 From: ZhangDong To: Pekka Savola Message-id: Date: Wed, 19 Nov 2008 10:37:30 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: References: Content-transfer-encoding: quoted-printable Cc: savi@ietf.org Subject: [savi] Reply: FYI: Juniper support for SEND X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 02:37:39 -0000 Thanks=2C Pwkka=2E It makes sense really=2Cespecially for me=2E I wonder that whether there is open source of SEND=2E Dong Zhang ----- =D4=AD=CA=BC=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A Pekka Savola =3Cpekkas=40netcore=2Efi=3E =C8=D5=C6=DA=3A 2008=C4=EA 11=D4=C2 19=C8=D5=2C =D0=C7=C6=DA=C8=FD=2C =C9= =CF=CE=E73=3A58 =D6=F7=CC=E2=3A =5Bsavi=5D FYI=3A Juniper support for SEND =CA=D5=BC=FE=C8=CB=3A savi=40ietf=2Eorg =3E FYI=2C FWIW=2C =3E = =3E I noticed that the recently released JunOS software (9=2E3) support= s SEND=2E =3E = =3E I guess there must be loud users demanding this feature for it to b= e = =3E = =3E implemented=2E I guess we=27ll have some hope for SEND after all! =3E = =3E However=2C it seems that certificate discovery etc=2E is not suppor= ted=2E = =3E A SEND-based SAVI solution would probably need this to authorize = =3E routers to send off-link traffic=2E =3E = =3E http=3A //www=2Ejuniper=2Enet/techpubs/en=5FUS/junos9=2E3/informati= on-products/topic-collections/release-notes/9=2E3/m-mx-t-series-new-feat= ures=2Ehtml =3E = =3E http=3A //www=2Ejuniper=2Enet/techpubs/software/junos/junos93/swcon= fig-routing/secure-neighbor-discovery-configuration-guidelines=2Ehtml =3E = =3E -- = =3E Pekka Savola =22You each name yourselves king=2C ye= t the =3E Netcore Oy kingdom bleeds=2E=22 =3E Systems=2E Networks=2E Security=2E -- George R=2ER=2E Martin=3A A C= lash of Kings =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =3E savi mailing list =3E savi=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/savi =3E From pekkas@netcore.fi Tue Nov 18 23:14:30 2008 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 BEA173A6A61 for ; Tue, 18 Nov 2008 23:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 AHcQ4EvKhIak for ; Tue, 18 Nov 2008 23:14:29 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 5C2753A6944 for ; Tue, 18 Nov 2008 23:14:29 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id mAJ7E2Ff024091; Wed, 19 Nov 2008 09:14:03 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id mAJ7DxGW024080; Wed, 19 Nov 2008 09:14:02 +0200 Date: Wed, 19 Nov 2008 09:13:59 +0200 (EET) From: Pekka Savola To: ZhangDong In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.94.1/8649/Wed Nov 19 00:31:11 2008 on otso.netcore.fi X-Virus-Status: Clean Cc: savi@ietf.org Subject: Re: [savi] Reply: FYI: Juniper support for SEND X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 07:14:30 -0000 On Wed, 19 Nov 2008, ZhangDong wrote: > It makes sense really,especially for me. > I wonder that whether there is open source of SEND. Yes, Docomo Labs have/had one; they might be willing to hand it over to someone http://www.ietf.org/mail-archive/web/cga-ext/current/msg00173.html http://www.docomolabs-usa.com/lab_opensource.html > ----- ???? ----- > ???: Pekka Savola > ??: 2008? 11? 19?, ???, ??3:58 > ??: [savi] FYI: Juniper support for SEND > ???: savi@ietf.org > > >> FYI, FWIW, >> >> I noticed that the recently released JunOS software (9.3) supports SEND. >> >> I guess there must be loud users demanding this feature for it to be >> >> implemented. I guess we'll have some hope for SEND after all! >> >> However, it seems that certificate discovery etc. is not supported. >> A SEND-based SAVI solution would probably need this to authorize >> routers to send off-link traffic. >> >> http: //www.juniper.net/techpubs/en_US/junos9.3/information-products/topic-collections/release-notes/9.3/m-mx-t-series-new-features.html >> >> http: //www.juniper.net/techpubs/software/junos/junos93/swconfig-routing/secure-neighbor-discovery-configuration-guidelines.html >> >> -- >> Pekka Savola "You each name yourselves king, yet the >> Netcore Oy kingdom bleeds." >> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From sshen@huawei.com Wed Nov 19 00:11:08 2008 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 7EB2D3A6A4E for ; Wed, 19 Nov 2008 00:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 6.251 X-Spam-Level: ****** X-Spam-Status: Yes, score=6.251 tagged_above=-999 required=5 tests=[AWL=1.216, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] X-Spam-Report: * 1.3 SARE_SUB_ENC_GB2312 Subject specifies display in non-English lang * 3.2 CHARSET_FARAWAY_HEADER A foreign language charset used in headers * 0.3 CN_BODY_35 BODY: Body contains "\323\312\274\376" * -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] * 2.5 MIME_CHARSET_FARAWAY MIME character set indicates foreign language * 0.3 MIME_8BIT_HEADER Message header contains 8-bit character * 1.2 AWL AWL: From: address is in the auto white-list 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 xIYYeUgJJv4U for ; Wed, 19 Nov 2008 00:11:07 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 86FCF3A67F5 for ; Wed, 19 Nov 2008 00:11:07 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KAK00KBBMQHZG@szxga03-in.huawei.com> for savi@ietf.org; Wed, 19 Nov 2008 16:11:05 +0800 (CST) Received: from huawei.com ([172.17.1.36]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KAK00DAIMQGPO@szxga03-in.huawei.com> for savi@ietf.org; Wed, 19 Nov 2008 16:11:05 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [130.129.78.146]) by szxmc04-in.huawei.com (mshttpd); Wed, 19 Nov 2008 02:11:01 -0600 Date: Wed, 19 Nov 2008 02:11:01 -0600 From: shenshuo 00102542 In-reply-to: To: ZhangDong Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: Cc: savi@ietf.org Subject: [savi] =?gb2312?b?KioqU1BBTSoqKiA2LjI1MSAoNSkgu9i4tCA6IFJlcGx5?= =?gb2312?b?OiAgRllJOglKdW5pcGVyIHN1cHBvcnQgZm9yIFNFTkQ=?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 08:11:08 -0000 Docomo USA had one open source implementation of SeND a few years ago=2E = But the project is no longer maintained=2E I believe many people still ha= ve the code=2C in case you can not find it=2C let me know=2E We just launched a project of a new implementation of SeND=2E We hope to = have a report by the next IETF=2E Best=2C = Sean FYI=3A Docomo SeND project http=3A//www=2Edocomolabs-usa=2Ecom/lab=5Fopensource=2Ehtml ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A ZhangDong =3Czhangdong=5Frh=40huaweisymantec=2Ecom=3E= =C8=D5=C6=DA=3A =D0=C7=C6=DA=B6=FE=2C =CA=AE=D2=BB=D4=C2 18=C8=D5=2C 2008= =CF=C2=CE=E78=3A37 =D6=F7=CC=E2=3A =5Bsavi=5D Reply=3A FYI=3A Juniper support for SEND =CA=D5=BC=FE=C8=CB=3A Pekka Savola =3Cpekkas=40netcore=2Efi=3E =B3=AD=CB=CD=3A savi=40ietf=2Eorg =3E Thanks=2C Pwkka=2E =3E = =3E It makes sense really=2Cespecially for me=2E =3E I wonder that whether there is open source of SEND=2E =3E = =3E = =3E = =3E Dong Zhang =3E = =3E = =3E ----- =D4=AD=CA=BC=D3=CA=BC=FE ----- =3E =B7=A2=BC=FE=C8=CB=3A Pekka Savola =3Cpekkas=40netcore=2Efi=3E =3E =C8=D5=C6=DA=3A 2008=C4=EA 11=D4=C2 19=C8=D5=2C =D0=C7=C6=DA=C8=FD=2C= =C9=CF=CE=E73=3A58 =3E =D6=F7=CC=E2=3A =5Bsavi=5D FYI=3A Juniper support for SEND =3E =CA=D5=BC=FE=C8=CB=3A savi=40ietf=2Eorg =3E = =3E = =3E =3E FYI=2C FWIW=2C =3E =3E = =3E =3E I noticed that the recently released JunOS software (9=2E3) = =3E supports SEND=2E =3E =3E = =3E =3E I guess there must be loud users demanding this feature for it = =3E to be = =3E =3E = =3E =3E implemented=2E I guess we=27ll have some hope for SEND after al= l! =3E =3E = =3E =3E However=2C it seems that certificate discovery etc=2E is not = =3E supported=2E = =3E =3E A SEND-based SAVI solution would probably need this to = =3E authorize = =3E =3E routers to send off-link traffic=2E =3E =3E = =3E =3E http=3A //www=2Ejuniper=2Enet/techpubs/en=5FUS/junos9=2E3/inform= ation- =3E products/topic-collections/release-notes/9=2E3/m-mx-t-series-new- =3E features=2Ehtml=3E = =3E =3E http=3A = =3E //www=2Ejuniper=2Enet/techpubs/software/junos/junos93/swconfig-routin= g/secure-neighbor-discovery-configuration-guidelines=2Ehtml =3E =3E = =3E =3E -- = =3E =3E Pekka Savola =22You each name yourselves king=2C= = =3E yet the =3E =3E Netcore Oy kingdom bleeds=2E=22 =3E =3E Systems=2E Networks=2E Security=2E -- George R=2ER=2E Martin=3A = A Clash of = =3E Kings=3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F =3E =3E savi mailing list =3E =3E savi=40ietf=2Eorg =3E =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/savi =3E =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E savi mailing list =3E savi=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/savi =3E From sshen@huawei.com Wed Nov 19 00:19:21 2008 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 0054A3A67F5 for ; Wed, 19 Nov 2008 00:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.22 X-Spam-Level: *** X-Spam-Status: No, score=3.22 tagged_above=-999 required=5 tests=[AWL=3.030, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iTX6Gl4Fu31 for ; Wed, 19 Nov 2008 00:19:20 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 09B5D3A6B0E for ; Wed, 19 Nov 2008 00:19:20 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KAK00KNGN45ZG@szxga03-in.huawei.com> for savi@ietf.org; Wed, 19 Nov 2008 16:19:18 +0800 (CST) Received: from huawei.com ([172.17.1.36]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KAK006CRN45S0@szxga03-in.huawei.com> for savi@ietf.org; Wed, 19 Nov 2008 16:19:17 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [130.129.78.146]) by szxmc04-in.huawei.com (mshttpd); Wed, 19 Nov 2008 02:19:14 -0600 Date: Wed, 19 Nov 2008 02:19:14 -0600 From: shenshuo 00102542 In-reply-to: To: savi@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: Subject: [savi] savi] ***SPAM*** 6.251 (5) : Reply: FYI: Juniper support for SEND X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 08:19:21 -0000 ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A shenshuo 00102542 =3Csshen=40huawei=2Ecom=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=C8=FD=2C =CA=AE=D2=BB=D4=C2 19=C8=D5=2C 2008= =C9=CF=CE=E72=3A11 =D6=F7=CC=E2=3A =5Bsavi=5D ***SPAM*** 6=2E251 (5) =BB=D8=B8=B4 =3A Reply=3A= FYI=3A Juniper support for SEND =CA=D5=BC=FE=C8=CB=3A ZhangDong =3Czhangdong=5Frh=40huaweisymantec=2Ecom=3E= =B3=AD=CB=CD=3A savi=40ietf=2Eorg =3E Docomo USA had one open source implementation of SeND a few years = =3E ago=2E But the project is no longer maintained=2E I believe many = =3E people still have the code=2C in case you can not find it=2C let me k= now=2E =3E We just launched a project of a new implementation of SeND=2E We = =3E hope to have a report by the next IETF=2E =3E Best=2C = =3E = =3E Sean =3E = =3E = =3E = =3E = =3E FYI=3A Docomo SeND project =3E http=3A//www=2Edocomolabs-usa=2Ecom/lab=5Fopensource=2Ehtml =3E = =3E = =3E = =3E ----- =D4=AD=D3=CA=BC=FE ----- =3E =B7=A2=BC=FE=C8=CB=3A ZhangDong =3Czhangdong=5Frh=40huaweisymantec=2E= com=3E =3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=B6=FE=2C =CA=AE=D2=BB=D4=C2 18=C8=D5=2C = 2008 =CF=C2=CE=E78=3A37 =3E =D6=F7=CC=E2=3A =5Bsavi=5D Reply=3A FYI=3A Juniper support for SEND =3E =CA=D5=BC=FE=C8=CB=3A Pekka Savola =3Cpekkas=40netcore=2Efi=3E =3E =B3=AD=CB=CD=3A savi=40ietf=2Eorg =3E = =3E =3E Thanks=2C Pwkka=2E =3E =3E = =3E =3E It makes sense really=2Cespecially for me=2E =3E =3E I wonder that whether there is open source of SEND=2E =3E =3E = =3E =3E = =3E =3E = =3E =3E Dong Zhang =3E =3E = =3E =3E = =3E =3E ----- =D4=AD=CA=BC=D3=CA=BC=FE ----- =3E =3E =B7=A2=BC=FE=C8=CB=3A Pekka Savola =3Cpekkas=40netcore=2Efi=3E =3E =3E =C8=D5=C6=DA=3A 2008=C4=EA 11=D4=C2 19=C8=D5=2C =D0=C7=C6=DA=C8=FD= =2C =C9=CF=CE=E73=3A58 =3E =3E =D6=F7=CC=E2=3A =5Bsavi=5D FYI=3A Juniper support for SEND =3E =3E =CA=D5=BC=FE=C8=CB=3A savi=40ietf=2Eorg =3E =3E = =3E =3E = =3E =3E =3E FYI=2C FWIW=2C =3E =3E =3E = =3E =3E =3E I noticed that the recently released JunOS software (9=2E3) = =3E =3E supports SEND=2E =3E =3E =3E = =3E =3E =3E I guess there must be loud users demanding this feature for = =3E it = =3E =3E to be = =3E =3E =3E = =3E =3E =3E implemented=2E I guess we=27ll have some hope for SEND afte= r all! =3E =3E =3E = =3E =3E =3E However=2C it seems that certificate discovery etc=2E is not= = =3E =3E supported=2E = =3E =3E =3E A SEND-based SAVI solution would probably need this to = =3E =3E authorize = =3E =3E =3E routers to send off-link traffic=2E =3E =3E =3E = =3E =3E =3E http=3A //www=2Ejuniper=2Enet/techpubs/en=5FUS/junos9=2E3/in= formation- =3E =3E products/topic-collections/release-notes/9=2E3/m-mx-t-series-new-= =3E =3E features=2Ehtml=3E = =3E =3E =3E http=3A = =3E =3E //www=2Ejuniper=2Enet/techpubs/software/junos/junos93/swconfig- =3E routing/secure-neighbor-discovery-configuration-guidelines=2Ehtml =3E =3E =3E = =3E =3E =3E -- = =3E =3E =3E Pekka Savola =22You each name yourselves kin= g=2C = =3E =3E yet the =3E =3E =3E Netcore Oy kingdom bleeds=2E=22 =3E =3E =3E Systems=2E Networks=2E Security=2E -- George R=2ER=2E Martin= =3A A Clash = =3E of = =3E =3E Kings=3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F =3E =3E =3E savi mailing list =3E =3E =3E savi=40ietf=2Eorg =3E =3E =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/savi =3E =3E =3E = =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =3E =3E savi mailing list =3E =3E savi=40ietf=2Eorg =3E =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/savi =3E =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E savi mailing list =3E savi=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/savi =3E From pekkas@netcore.fi Wed Nov 19 04:25:52 2008 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 A0F123A6872 for ; Wed, 19 Nov 2008 04:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[AWL=-2.257, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_GB2312=1.345] 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 mTZ4Ngq6e9sO for ; Wed, 19 Nov 2008 04:25:52 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 97D253A67B2 for ; Wed, 19 Nov 2008 04:25:51 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id mAJCPNNl030607; Wed, 19 Nov 2008 14:25:23 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id mAJCPLgv030603; Wed, 19 Nov 2008 14:25:22 +0200 Date: Wed, 19 Nov 2008 14:25:21 +0200 (EET) From: Pekka Savola To: shenshuo 00102542 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.94.1/8649/Wed Nov 19 00:31:11 2008 on otso.netcore.fi X-Virus-Status: Clean Cc: savi@ietf.org Subject: Re: [savi] =?gb2312?b?u9i4tDogUmVwbHk6ICBGWUk6IEp1bmlwZXIgc3VwcG9y?= =?gb2312?b?dCBmb3IgU0VORA==?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 12:25:52 -0000 On Wed, 19 Nov 2008, shenshuo 00102542 wrote: > Docomo USA had one open source implementation of SeND a few years > ago. But the project is no longer maintained. I believe many people > still have the code, in case you can not find it, let me know. We > just launched a project of a new implementation of SeND. We hope to > have a report by the next IETF. Best, I wonder if anyone would be interested in stepping up to maintain the Docomo project for the common benefit? Based on the mailing-list exchanges I referred to, they would be willing. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From sshen@huawei.com Wed Nov 19 07:46:26 2008 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 050043A6B03 for ; Wed, 19 Nov 2008 07:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.104 X-Spam-Level: ** X-Spam-Status: No, score=2.104 tagged_above=-999 required=5 tests=[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 yyh2LYK8tbPo for ; Wed, 19 Nov 2008 07:46:25 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 270393A6AB7 for ; Wed, 19 Nov 2008 07:46:25 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KAL00CLT7T1YX@szxga04-in.huawei.com> for savi@ietf.org; Wed, 19 Nov 2008 23:46:13 +0800 (CST) Received: from huawei.com ([172.17.1.36]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KAL00HHP7T1C4@szxga04-in.huawei.com> for savi@ietf.org; Wed, 19 Nov 2008 23:46:13 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [130.129.78.146]) by szxmc04-in.huawei.com (mshttpd); Wed, 19 Nov 2008 09:46:10 -0600 Date: Wed, 19 Nov 2008 09:46:10 -0600 From: shenshuo 00102542 In-reply-to: To: Pekka Savola Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal References: Cc: savi@ietf.org Subject: Re: [savi] ??: Reply: FYI: Juniper support for SEND X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 15:46:26 -0000 I found there are volunteers who is maintaining the Docomo code. Sorry if my previous message misleaded. http://www.ietf.org/mail-archive/web/cga-ext/current/msg00180.html Sean ----- Original Message ----- From: Pekka Savola Date: Wednesday, November 19, 2008 6:49 am Subject: Re: ??:[savi] Reply: FYI: Juniper support for SEND To: shenshuo 00102542 Cc: ZhangDong , savi@ietf.org > On Wed, 19 Nov 2008, shenshuo 00102542 wrote: > > Docomo USA had one open source implementation of SeND a few > years > > ago. But the project is no longer maintained. I believe many > people > > still have the code, in case you can not find it, let me know. > We > > just launched a project of a new implementation of SeND. We hope > to > > have a report by the next IETF. Best, > > I wonder if anyone would be interested in stepping up to maintain > the > Docomo project for the common benefit? Based on the mailing-list > exchanges I referred to, they would be willing. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > From christian.vogt@ericsson.com Wed Dec 17 21:15:03 2008 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 6248528C10C for ; Wed, 17 Dec 2008 21:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 5wbaloGMksqy for ; Wed, 17 Dec 2008 21:15:02 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 4F7013A6B47 for ; Wed, 17 Dec 2008 21:15:02 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 51E1620AFE; Thu, 18 Dec 2008 06:14:53 +0100 (CET) X-AuditID: c1b4fb3c-adf5ebb00000304c-ab-4949dc4d46d2 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 355FA20529; Thu, 18 Dec 2008 06:14:53 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Dec 2008 06:14:50 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Dec 2008 06:14:50 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 315A92461; Thu, 18 Dec 2008 07:14:50 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E12F84DB51; Thu, 18 Dec 2008 07:14:48 +0200 (EET) Message-Id: From: Christian Vogt To: SAVI Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 18 Dec 2008 13:14:46 +0800 X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 18 Dec 2008 05:14:50.0440 (UTC) FILETIME=[8D732480:01C960CF] X-Brightmail-Tracker: AAAAAA== Subject: [savi] Working Group Adoption of Individual SAVI Documents X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2008 05:15:03 -0000 Dear all - At the previous SAVI meeting in Minneapolis, we did a vote regarding which individual documents to use as starting points for the SAVI working group deliverables. I would now like to confirm this decision from Minneapolis here on the mailing list. The result of the vote in Minneapolis was thus: - To adopt draft-mcpherson-savi-threat-scope as a starting point for the Threats Analysis (Problem Statement) document: 7 in favour, 0 against. - To adopt draft-vogt-savi-rationale as a starting point for the Rationale document: 7 in favour, 0 against. - To adopt draft-bagnulo-savi-fcfs as a starting point for both the IPv4 and IPv6 Solution documents: 11 in favour, 2 against. - To adopt draft-bagnulo-savi-send as a starting point for the SeND-based IPv6 Solution document: 8 in favour, 1 against. Arguments raised by those voting against the adoption of one of the individual documents above related to potential security vulnerabilities or potential issues with mobile hosts. Both arguments would need to be addressed as the working group deliverables are being advanced. Please express on this mailing list whether or not you agree with the above documents being adopted by the SAVI working group as starting points for the various working group deliverables. Please also state the reasons in case you are against one of the documents being adopted. - Christian From christian.vogt@ericsson.com Wed Dec 17 21:23:55 2008 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 7B74A3A68D7 for ; Wed, 17 Dec 2008 21:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.204 X-Spam-Level: X-Spam-Status: No, score=-6.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 kuOxjJre4YKo for ; Wed, 17 Dec 2008 21:23:54 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A5D193A67EA for ; Wed, 17 Dec 2008 21:23:54 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 263EF201EE; Thu, 18 Dec 2008 06:23:46 +0100 (CET) X-AuditID: c1b4fb3e-acf82bb00000537b-00-4949de6225ad Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1554421005; Thu, 18 Dec 2008 06:23:46 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Dec 2008 06:23:45 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Dec 2008 06:23:45 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A7FBA2372; Thu, 18 Dec 2008 07:23:43 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 083C54DB51; Thu, 18 Dec 2008 07:23:40 +0200 (EET) Message-Id: <783F076C-3409-4F4E-B96E-F4D1D17D8470@ericsson.com> From: Christian Vogt To: SAVI Mailing List In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 18 Dec 2008 13:23:38 +0800 References: X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 18 Dec 2008 05:23:45.0790 (UTC) FILETIME=[CC8B11E0:01C960D0] X-Brightmail-Tracker: AAAAAA== Subject: Re: [savi] Working Group Adoption of Individual SAVI Documents X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2008 05:23:55 -0000 Christian Vogt wrote: > Please express on this mailing list whether or not you agree with the > above documents being adopted by the SAVI working group as starting > points for the various working group deliverables. Please also state > the reasons in case you are against one of the documents being > adopted. Please do so before Sunday, January 4, 2009. - Christian From xiayangsong@huawei.com Thu Dec 18 07:54:41 2008 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 849EC3A69B3 for ; Thu, 18 Dec 2008 07:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.745, 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 3TZU5gBVnz0v for ; Thu, 18 Dec 2008 07:54:40 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id B3C0D3A6990 for ; Thu, 18 Dec 2008 07:54:40 -0800 (PST) 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 <0KC2000ZAXIWIA@usaga02-in.huawei.com> for savi@ietf.org; Thu, 18 Dec 2008 07:54:32 -0800 (PST) Received: from X24512z ([10.124.12.66]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KC2007UAXIV66@usaga02-in.huawei.com> for savi@ietf.org; Thu, 18 Dec 2008 07:54:31 -0800 (PST) Date: Thu, 18 Dec 2008 09:54:30 -0600 From: Frank Xia To: Christian Vogt , SAVI Mailing List Message-id: <005901c96128$ea3185f0$420c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [savi] Working Group Adoption of Individual SAVI Documents X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2008 15:54:41 -0000 Hi Christian I was not in the against list of FCFS, however, I did express my concerns of the solution. The main idea is trying to build a source address validation rule using the first data packet. IMHO, this solution is vulnerable. It seems to be hard to deal with the following scenarios: 1)A host is authorized to use a static address, while the host does not connect the network 2)A IPv6 host periodically changes it's interface ID from privacy consideration. 3)In dynamic address configuration, an IP address can be reused by other hosts. BR Frank ----- Original Message ----- From: "Christian Vogt" To: "SAVI Mailing List" Sent: Wednesday, December 17, 2008 11:14 PM Subject: [savi] Working Group Adoption of Individual SAVI Documents > Dear all - > > At the previous SAVI meeting in Minneapolis, we did a vote regarding > which individual documents to use as starting points for the SAVI > working group deliverables. I would now like to confirm this decision > from Minneapolis here on the mailing list. > > The result of the vote in Minneapolis was thus: > > - To adopt draft-mcpherson-savi-threat-scope as a starting point for the > Threats Analysis (Problem Statement) document: 7 in favour, 0 > against. > > - To adopt draft-vogt-savi-rationale as a starting point for the > Rationale document: 7 in favour, 0 against. > > - To adopt draft-bagnulo-savi-fcfs as a starting point for both the IPv4 > and IPv6 Solution documents: 11 in favour, 2 against. > > - To adopt draft-bagnulo-savi-send as a starting point for the > SeND-based IPv6 Solution document: 8 in favour, 1 against. > > Arguments raised by those voting against the adoption of one of the > individual documents above related to potential security vulnerabilities > or potential issues with mobile hosts. Both arguments would need to be > addressed as the working group deliverables are being advanced. > > Please express on this mailing list whether or not you agree with the > above documents being adopted by the SAVI working group as starting > points for the various working group deliverables. Please also state > the reasons in case you are against one of the documents being adopted. > > - Christian > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From marcelo@it.uc3m.es Thu Dec 18 11:11:28 2008 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 254473A6BA4 for ; Thu, 18 Dec 2008 11:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.83 X-Spam-Level: X-Spam-Status: No, score=-3.83 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 r3BrCpVlceTK for ; Thu, 18 Dec 2008 11:11:26 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 352533A6B49 for ; Thu, 18 Dec 2008 11:11:25 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (159.pool85-53-153.dynamic.orange.es [85.53.153.159])by smtp03.uc3m.es (Postfix) with ESMTP id B211472B568; Thu, 18 Dec 2008 20:11:13 +0100 (CET) Message-ID: <494AA050.2060300@it.uc3m.es> Date: Thu, 18 Dec 2008 20:11:12 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Frank Xia References: <005901c96128$ea3185f0$420c7c0a@china.huawei.com> In-Reply-To: <005901c96128$ea3185f0$420c7c0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-35.0711 TC:1F TRN:56 TV:5.5.1026(16348.001) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: SAVI Mailing List , Christian Vogt Subject: Re: [savi] Working Group Adoption of Individual SAVI Documents X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2008 19:11:28 -0000 Hi Frank, some comments below... Frank Xia escribió: > Hi Christian > > I was not in the against list of FCFS, however, > I did express my concerns of the solution. > > The main idea is trying to build a > source address validation rule using the first data packet. IMHO, > this solution is vulnerable. > > It seems to be hard to deal with the following scenarios: > 1)A host is authorized to use a static address, while > the host does not connect the network right, we need to think how to deal with this case one obvious option is that since the address is manually configured in the host, it can also be manually included in the SAVI cache, so it knows that has been manually assigned I understand that some people actually manually configure MAC- IP address associations to perform this type of checks > > 2)A IPv6 host periodically changes it's interface ID > from privacy consideration. not sure why this is a problem, could you expand? > 3)In dynamic address configuration, an IP address > can be reused by other hosts. > this is no problem, the current draft actually deals with this Regards, marcelo > BR > Frank > > > ----- Original Message ----- From: "Christian Vogt" > > To: "SAVI Mailing List" > Sent: Wednesday, December 17, 2008 11:14 PM > Subject: [savi] Working Group Adoption of Individual SAVI Documents > > >> Dear all - >> >> At the previous SAVI meeting in Minneapolis, we did a vote regarding >> which individual documents to use as starting points for the SAVI >> working group deliverables. I would now like to confirm this decision >> from Minneapolis here on the mailing list. >> >> The result of the vote in Minneapolis was thus: >> >> - To adopt draft-mcpherson-savi-threat-scope as a starting point for the >> Threats Analysis (Problem Statement) document: 7 in favour, 0 >> against. >> >> - To adopt draft-vogt-savi-rationale as a starting point for the >> Rationale document: 7 in favour, 0 against. >> >> - To adopt draft-bagnulo-savi-fcfs as a starting point for both the IPv4 >> and IPv6 Solution documents: 11 in favour, 2 against. >> >> - To adopt draft-bagnulo-savi-send as a starting point for the >> SeND-based IPv6 Solution document: 8 in favour, 1 against. >> >> Arguments raised by those voting against the adoption of one of the >> individual documents above related to potential security vulnerabilities >> or potential issues with mobile hosts. Both arguments would need to be >> addressed as the working group deliverables are being advanced. >> >> Please express on this mailing list whether or not you agree with the >> above documents being adopted by the SAVI working group as starting >> points for the various working group deliverables. Please also state >> the reasons in case you are against one of the documents being adopted. >> >> - Christian >> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From christian.vogt@ericsson.com Sat Dec 20 10:10:11 2008 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 A29393A67DA for ; Sat, 20 Dec 2008 10:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.671 X-Spam-Level: X-Spam-Status: No, score=-5.671 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HELO_EQ_SE=0.35, 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 HMuY+4iNcr7y for ; Sat, 20 Dec 2008 10:10:10 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 992563A67D0 for ; Sat, 20 Dec 2008 10:10:10 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2C9682094A; Sat, 20 Dec 2008 19:10:01 +0100 (CET) X-AuditID: c1b4fb3c-ac75bbb00000304c-24-494d34f909bd Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0D74020647; Sat, 20 Dec 2008 19:10:01 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 20 Dec 2008 19:10:00 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 20 Dec 2008 19:10:00 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4CF112461; Sat, 20 Dec 2008 20:10:00 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2CC154DB51; Sat, 20 Dec 2008 20:10:00 +0200 (EET) Message-Id: <7141029F-A8F2-4892-977A-BFF510A405B7@ericsson.com> From: Christian Vogt To: Marcelo Bagnulo Braun , Frank Xia In-Reply-To: <494AA050.2060300@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 20 Dec 2008 13:28:28 +0200 References: <005901c96128$ea3185f0$420c7c0a@china.huawei.com> <494AA050.2060300@it.uc3m.es> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 20 Dec 2008 18:10:00.0330 (UTC) FILETIME=[2C54A6A0:01C962CE] X-Brightmail-Tracker: AAAAAA== Cc: SAVI Mailing List Subject: Re: [savi] Working Group Adoption of Individual SAVI Documents 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, 20 Dec 2008 18:10:11 -0000 Marcelo and Frank - >> It seems to be hard to deal with the following scenarios: 1)A host is >> authorized to use a static address, while the host does not >> connect the >> network > > right, we need to think how to deal with this case one obvious > option is > that since the address is manually configured in the host, it can also > be manually included in the SAVI cache, so it knows that has been > manually assigned Right. An alternative, more automated solution might be to have the switch perform proxy DAD when a new address is used on a given port. This would enable the switch to determine whether the new address is pre-configured and hence already in use, because the pre-configured host would respond to the switch's Neighbor Solicitation during the proxy DAD procedure. FCFS already uses proxy DAD -- in the Neighbor Unreachability Detection variant -- to prevent attackers from hijacking an address by faking link-layer movements. An obvious optimization to avoid unnecessary proxy DAD is for the switch to listen for non-proxy DAD, and to skip proxy DAD if non-proxy DAD was performed for the same address/port combination. - Christian From lint@h3c.com Mon Dec 22 01:50:10 2008 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 489B428C0FE for ; Mon, 22 Dec 2008 01:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.727 X-Spam-Level: * X-Spam-Status: No, score=1.727 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, RELAY_IS_221=2.222] 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 14qhDByyBlxN for ; Mon, 22 Dec 2008 01:50:09 -0800 (PST) Received: from huawei-3com.com (unknown [221.12.31.13]) by core3.amsl.com (Postfix) with ESMTP id 5893528C0F0 for ; Mon, 22 Dec 2008 01:50:08 -0800 (PST) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KC9005WCVBACX@h3cml02-in.huawei-3com.com> for savi@ietf.org; Mon, 22 Dec 2008 17:49:58 +0800 (CST) Received: from mailsecurity.h3c.com ([172.25.12.124]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KC9005KFVBABT@h3cml02-in.huawei-3com.com> for savi@ietf.org; Mon, 22 Dec 2008 17:49:58 +0800 (CST) Received: from unknown (HELO l00450a) ([10.153.17.34]) by mailsecurity.h3c.com with ESMTP; Mon, 22 Dec 2008 17:57:26 +0800 Date: Mon, 22 Dec 2008 17:49:57 +0800 From: Lin Tao To: Frank Xia , Marcelo Bagnulo Braun , Christian Vogt Message-id: <002601c9641a$a6446fc0$2211990a@h3c.huawei3com.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <005901c96128$ea3185f0$420c7c0a@china.huawei.com> <494AA050.2060300@it.uc3m.es> <7141029F-A8F2-4892-977A-BFF510A405B7@ericsson.com> Cc: =?utf-8?B?5aeaIOW5vw==?= , SAVI Mailing List Subject: Re: [savi] Working Group Adoption of Individual SAVI Documents 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, 22 Dec 2008 09:50:10 -0000 Hello, Christian, Marcelo and Frank: I agree with Frank's view. Because the forwarding packet is observed in FCFS draft, so the forwarding process is disrupted, and the device is vulnerable, e.g. savi cache table exhausted, the cpu of switch busy, etc. In my opinion, observing the Control Protocol, e.g. DHCP or ND etc, is easy to implement in switch for these protocol have special characteristic that can be filtered in switch port while the forwarding packet is blocked. ----- Original Message ----- From: "Christian Vogt" To: "Marcelo Bagnulo Braun" ; "Frank Xia" Cc: "SAVI Mailing List" Sent: Saturday, December 20, 2008 7:28 PM Subject: Re: [savi] Working Group Adoption of Individual SAVI Documents > Marcelo and Frank - > >>> It seems to be hard to deal with the following scenarios: 1)A host is >>> authorized to use a static address, while the host does not >>> connect the >>> network >> >> right, we need to think how to deal with this case one obvious >> option is >> that since the address is manually configured in the host, it can also >> be manually included in the SAVI cache, so it knows that has been >> manually assigned > > Right. An alternative, more automated solution might be to have the > switch perform proxy DAD when a new address is used on a given port. > This would enable the switch to determine whether the new address is > pre-configured and hence already in use, because the pre-configured host > would respond to the switch's Neighbor Solicitation during the proxy DAD > procedure. > > FCFS already uses proxy DAD -- in the Neighbor Unreachability Detection > variant -- to prevent attackers from hijacking an address by faking > link-layer movements. > > An obvious optimization to avoid unnecessary proxy DAD is for the switch > to listen for non-proxy DAD, and to skip proxy DAD if non-proxy DAD was > performed for the same address/port combination. > > - Christian > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From marcelo@it.uc3m.es Mon Dec 22 02:27:12 2008 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 BF3EB3A685C for ; Mon, 22 Dec 2008 02:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.762 X-Spam-Level: X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 BlfQwsrcKQWC for ; Mon, 22 Dec 2008 02:27:11 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 488043A67B2 for ; Mon, 22 Dec 2008 02:27:10 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (r190-0-142-44.dialup.adsl.anteldata.net.uy [190.0.142.44])by smtp02.uc3m.es (Postfix) with ESMTP id 53CEB65462F;Mon, 22 Dec 2008 11:26:55 +0100 (CET) Message-ID: <494F6B6E.8010002@it.uc3m.es> Date: Mon, 22 Dec 2008 11:26:54 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Lin Tao References: <005901c96128 $ea3185f0$420c7c0a@china.huawei.com><494AA050.2060300@it.uc3m.es><7141029F -A8F2-4892-977A-BFF510A405B7@ericsson.com> <002601c9641a$a6446fc0$2211990a@h3c.huawei3com.com> In-Reply-To: <002601c9641a$a6446fc0$2211990a@h3c.huawei3com.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-27.1959 TC:1F TRN:58 TV:5.5.1026(16354.006) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: =?UTF-8?B?5aeaIOW5vw==?= , SAVI Mailing List , Christian Vogt , Frank Xia Subject: Re: [savi] Working Group Adoption of Individual SAVI Documents 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, 22 Dec 2008 10:27:12 -0000 Hi Lin, Lin Tao escribió: > Hello, Christian, Marcelo and Frank: > > I agree with Frank's view. Because the forwarding packet is > observed in FCFS draft, so the forwarding process is disrupted, what do you mean by the process is disrupted? could you describe in detail what is the problem you are pointing out? > > and the device is vulnerable, the device is vulnerable to what type of attacks? again could you rpovide some detailed description of the issue that you are raising? > e.g. savi cache table exhausted, > DoS to the SAVI arch is an issue that we need to assess more indetail i agree see the previous disucssions in the ml about DoS attacks and SAVI > the cpu of switch busy, etc. > > In my opinion, observing the Control Protocol, e.g. DHCP > or ND etc, is easy to implement in switch for these protocol > have special characteristic that can be filtered in switch port while > the forwarding packet is blocked. > i don't understand what you mean here about the special characteristic dhcp has little or no security so, i am nbot sure how you are planning to prevent the attacks you mentioned before. with plain ND, is even worse imho, unless you use send, but send still retains some of the DoS attack vectors as been previously disucssed in the ml So, how do you think these protocols solve the issues you raised above? Regards, marcelo > > > ----- Original Message ----- > From: "Christian Vogt" > To: "Marcelo Bagnulo Braun" ; "Frank Xia" > Cc: "SAVI Mailing List" > Sent: Saturday, December 20, 2008 7:28 PM > Subject: Re: [savi] Working Group Adoption of Individual SAVI Documents > > > >> Marcelo and Frank - >> >> >>>> It seems to be hard to deal with the following scenarios: 1)A host is >>>> authorized to use a static address, while the host does not >>>> connect the >>>> network >>>> >>> right, we need to think how to deal with this case one obvious >>> option is >>> that since the address is manually configured in the host, it can also >>> be manually included in the SAVI cache, so it knows that has been >>> manually assigned >>> >> Right. An alternative, more automated solution might be to have the >> switch perform proxy DAD when a new address is used on a given port. >> This would enable the switch to determine whether the new address is >> pre-configured and hence already in use, because the pre-configured host >> would respond to the switch's Neighbor Solicitation during the proxy DAD >> procedure. >> >> FCFS already uses proxy DAD -- in the Neighbor Unreachability Detection >> variant -- to prevent attackers from hijacking an address by faking >> link-layer movements. >> >> An obvious optimization to avoid unnecessary proxy DAD is for the switch >> to listen for non-proxy DAD, and to skip proxy DAD if non-proxy DAD was >> performed for the same address/port combination. >> >> - Christian >> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> >> > > From christian.vogt@ericsson.com Tue Dec 23 02:36:05 2008 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 2486D28C156 for ; Tue, 23 Dec 2008 02:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.184 X-Spam-Level: X-Spam-Status: No, score=-6.184 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 redv3mm8oUk9 for ; Tue, 23 Dec 2008 02:36:04 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D6FE528C141 for ; Tue, 23 Dec 2008 02:36:02 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EB656217D7; Tue, 23 Dec 2008 11:35:52 +0100 (CET) X-AuditID: c1b4fb3e-af871bb00000429e-85-4950bf08425a Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C8B99213E9; Tue, 23 Dec 2008 11:35:52 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Dec 2008 11:35:52 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Dec 2008 11:35:51 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id C9CF6245E; Tue, 23 Dec 2008 12:35:51 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8501D4DB51; Tue, 23 Dec 2008 12:35:51 +0200 (EET) From: Christian Vogt To: Lin Tao In-Reply-To: <002601c9641a$a6446fc0$2211990a@h3c.huawei3com.com> X-Priority: 3 References: <005901c96128$ea3185f0$420c7c0a@china.huawei.com> <494AA050.2060300@it.uc3m.es> <7141029F-A8F2-4892-977A-BFF510A405B7@ericsson.com> <002601c9641a$a6446fc0$2211990a@h3c.huawei3com.com> Message-Id: <60D2E2DD-9815-4374-9A48-EC646396198E@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 23 Dec 2008 12:35:51 +0200 X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 23 Dec 2008 10:35:51.0848 (UTC) FILETIME=[3A358280:01C964EA] X-Brightmail-Tracker: AAAAAA== Cc: =?UTF-8?B?5aeaIOW5vw==?= , SAVI Mailing List , Frank Xia Subject: Re: [savi] Working Group Adoption of Individual SAVI Documents X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 10:36:05 -0000 Lin - I agree with you that DoS is an unsolved issue that we have yet to tackle. However, I don't think we can solve the issue, for all address configuration methods, simply by changing which packets we snoop. SLAAC in particular is an address configuration method where an attacker can overload a SAVI device just as easily with control packets (i.e., Neighbor Solicitation packets) as with datagram packets. The only scenario in which snooping control packets instead of datagram packets could mitigate the DoS issue is where addresses are exclusively assigned via DHCP. A SAVI device can then exclusively rely on messages being sent by a server (not directly by the attacker), such that a DoS attack against a SAVI device reduces to the existing threat of a DoS attack against a DHCP server. FWIW: Some SAVI participants were considering a DHCP-only option for SAVI during IETF 73. - Christian On Dec 22, 2008, Lin Tao wrote: > Hello, Christian, Marcelo and Frank: > > I agree with Frank's view. Because the forwarding packet is > observed in FCFS draft, so the forwarding process is disrupted, > and the device is vulnerable, e.g. savi cache table exhausted, > the cpu of switch busy, etc. > > In my opinion, observing the Control Protocol, e.g. DHCP > or ND etc, is easy to implement in switch for these protocol > have special characteristic that can be filtered in switch port while > the forwarding packet is blocked. From ietfdbh@comcast.net Tue Dec 23 13:52:23 2008 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 4684028C180 for ; Tue, 23 Dec 2008 13:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 Nqoqvseu6Wvx for ; Tue, 23 Dec 2008 13:52:22 -0800 (PST) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 3696228C17F for ; Tue, 23 Dec 2008 13:52:22 -0800 (PST) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA09.westchester.pa.mail.comcast.net with comcast id ukYS1a03U0QuhwU59lsDh8; Tue, 23 Dec 2008 21:52:13 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA02.westchester.pa.mail.comcast.net with comcast id ulsC1a00Q0UQ6dC3NlsCGG; Tue, 23 Dec 2008 21:52:13 +0000 From: "David Harrington" To: "'Christian Vogt'" , "'SAVI Mailing List'" References: Date: Tue, 23 Dec 2008 16:52:12 -0500 Message-ID: <00b001c96548$b6806bd0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Aclgz5MllC6V6+gWQ1arnGYslRkxKAEeEnlA Subject: Re: [savi] Working Group Adoption of Individual SAVI Documents X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 21:52:23 -0000 Hi, It appears some of these drafts have expired. Can the drafts be re-published so people can look at them before making a decision? I suggest you extend the review period accordingly. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On > Behalf Of Christian Vogt > Sent: Thursday, December 18, 2008 12:15 AM > To: SAVI Mailing List > Subject: [savi] Working Group Adoption of Individual SAVI Documents > > Dear all - > > At the previous SAVI meeting in Minneapolis, we did a vote regarding > which individual documents to use as starting points for the SAVI > working group deliverables. I would now like to confirm this decision > from Minneapolis here on the mailing list. > > The result of the vote in Minneapolis was thus: > > - To adopt draft-mcpherson-savi-threat-scope as a starting > point for the > Threats Analysis (Problem Statement) document: 7 in favour, 0 > against. > > - To adopt draft-vogt-savi-rationale as a starting point for the > Rationale document: 7 in favour, 0 against. > > - To adopt draft-bagnulo-savi-fcfs as a starting point for > both the IPv4 > and IPv6 Solution documents: 11 in favour, 2 against. > > - To adopt draft-bagnulo-savi-send as a starting point for the > SeND-based IPv6 Solution document: 8 in favour, 1 against. > > Arguments raised by those voting against the adoption of one of the > individual documents above related to potential security > vulnerabilities > or potential issues with mobile hosts. Both arguments would > need to be > addressed as the working group deliverables are being advanced. > > Please express on this mailing list whether or not you agree with the > above documents being adopted by the SAVI working group as starting > points for the various working group deliverables. Please also state > the reasons in case you are against one of the documents > being adopted. > > - Christian > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From marcelo@it.uc3m.es Tue Dec 23 17:01:39 2008 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 2D7A13A6B21 for ; Tue, 23 Dec 2008 17:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.18 X-Spam-Level: X-Spam-Status: No, score=-5.18 tagged_above=-999 required=5 tests=[AWL=1.418, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 vxBIb2ELAmMa for ; Tue, 23 Dec 2008 17:01:38 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 2FF0E3A677D for ; Tue, 23 Dec 2008 17:01:37 -0800 (PST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131])by smtp03.uc3m.es (Postfix) with ESMTP id 9CD5D72B61Cfor ; Wed, 24 Dec 2008 02:01:23 +0100 (CET) Received: from r190-135-181-179.dialup.adsl.anteldata.net.uy(r190-135-181-179.dialup.adsl. anteldata.net.uy [190.135.181.179]) bywebcartero01.uc3m.es (Horde MIME library) with HTTP; Wed, 24 Dec 200802:01:22 +0100 Message-ID: <20081224020122.p8webzgwgck8o4ok@webcartero01.uc3m.es> Date: Wed, 24 Dec 2008 02:01:22 +0100 From: MARCELO BAGNULO BRAUN To: savi@ietf.org References: <00b001c96548$b6806bd0$0600a8c0@china.huawei.com> In-Reply-To: <00b001c96548$b6806bd0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-24.3815 TC:1F TRN:43 TV:5.5.1026(16358.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: Re: [savi] Working Group Adoption of Individual SAVI Documents X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2008 01:01:39 -0000 Correction, only one of these draft is expired, draft-mcpherson-savi-threat-scope, (BTW you can easily find in tools.ietf.org besides many other sites, such as waterspings and so on) Regards, marcelo David Harrington dijo: > Hi, > > It appears some of these drafts have expired. > Can the drafts be re-published so people can look at them before > making a decision? > I suggest you extend the review period accordingly. > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > >> -----Original Message----- >> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On >> Behalf Of Christian Vogt >> Sent: Thursday, December 18, 2008 12:15 AM >> To: SAVI Mailing List >> Subject: [savi] Working Group Adoption of Individual SAVI Documents >> >> Dear all - >> >> At the previous SAVI meeting in Minneapolis, we did a vote regarding >> which individual documents to use as starting points for the SAVI >> working group deliverables. I would now like to confirm this > decision >> from Minneapolis here on the mailing list. >> >> The result of the vote in Minneapolis was thus: >> >> - To adopt draft-mcpherson-savi-threat-scope as a starting >> point for the >> Threats Analysis (Problem Statement) document: 7 in favour, 0 >> against. >> >> - To adopt draft-vogt-savi-rationale as a starting point for the >> Rationale document: 7 in favour, 0 against. >> >> - To adopt draft-bagnulo-savi-fcfs as a starting point for >> both the IPv4 >> and IPv6 Solution documents: 11 in favour, 2 against. >> >> - To adopt draft-bagnulo-savi-send as a starting point for the >> SeND-based IPv6 Solution document: 8 in favour, 1 against. >> >> Arguments raised by those voting against the adoption of one of the >> individual documents above related to potential security >> vulnerabilities >> or potential issues with mobile hosts. Both arguments would >> need to be >> addressed as the working group deliverables are being advanced. >> >> Please express on this mailing list whether or not you agree with > the >> above documents being adopted by the SAVI working group as starting >> points for the various working group deliverables. Please also > state >> the reasons in case you are against one of the documents >> being adopted. >> >> - Christian >> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid From lint@h3c.com Wed Dec 24 02:03:15 2008 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 14D023A682C for ; Wed, 24 Dec 2008 02:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.998 X-Spam-Level: *** X-Spam-Status: No, score=3.998 tagged_above=-999 required=5 tests=[AWL=-2.271, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, RELAY_IS_221=2.222] 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 VRcaSOa7IidD for ; Wed, 24 Dec 2008 02:03:14 -0800 (PST) Received: from huawei-3com.com (unknown [221.12.31.56]) by core3.amsl.com (Postfix) with ESMTP id CB8C928C146 for ; Wed, 24 Dec 2008 02:03:12 -0800 (PST) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KCD005BSL92NQ@h3cml01-in.huawei-3com.com> for savi@ietf.org; Wed, 24 Dec 2008 18:03:02 +0800 (CST) Received: from mailsecurity.h3c.com ([172.25.12.124]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KCD003NRL92PN@h3cml01-in.huawei-3com.com> for savi@ietf.org; Wed, 24 Dec 2008 18:03:02 +0800 (CST) Received: from unknown (HELO l00450a) ([10.153.17.131]) by mailsecurity.h3c.com with ESMTP; Wed, 24 Dec 2008 18:10:29 +0800 Date: Wed, 24 Dec 2008 18:03:01 +0800 From: Lin Tao To: Guang Yao , 'Christian Vogt' , 'Marcelo Bagnulo Braun' , 'Frank Xia' Message-id: <013001c965ae$ce9efa90$8311990a@h3c.huawei3com.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <005901c96128$ea3185f0$420c7c0a@china.huawei.com> <494AA050.2060300@it.uc3m.es> <7141029F-A8F2-4892-977A-BFF510A405B7@ericsson.com> <002601c9641a$a6446fc0$2211990a@h3c.huawei3com.com> <60D2E2DD-9815-4374-9A48-EC646396198E@ericsson.com> <008901c964f7$ca10ad00$5e320700$@tsinghua.edu.cn> Cc: 'SAVI Mailing List' Subject: Re: [savi] Working Group Adoption of Individual SAVI Documents X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2008 10:03:15 -0000 RGVhciBDaHJpc3RpYW4sIEd1YW5nIGFuZCBNYXJjZWxvLA0KDQogICAgSSBhZ3JlZSB3aXRoIEd1 YW5nIHRoYXQgdGhlIG5vcm1hbCBiZWhhdmlvcnMgYW5kIGdvb2QgZ3V5cw0KTVVTVCBiZSBwcm90 ZWN0ZWQsIHNvIHdlIHNob3VsZCBzbm9vcCBhdCBjb250cm9sIHBhY2tldHMgdGhhbiANCmRhdGFn cmFtIHBhY2tldHMuIFRoaXMgaXMgdGhlIHdvcnRoZXN0IHRoaW5nIGluIFNBVkkuIA0KICAgIFRo ZXJlIGlzIHR3byBwbGFuZSBpbiBTV0lUQ0g6IEFTSUMgYW5kIENQVSwgaXQgDQppcyBlYXN5IHRv IGltcGxlbWVudCBBQ0wgaW4gQVNJQyB0byBmaWx0ZXIgY29udHJvbCBwYWNrZXRzIHRvDQpDUFUs IGFuZCB0aGUgZGF0YWdyYW0gcGFja2V0cyBpcyBkaXNjYXJkZWQgYnkgZGVmYXVsdC4gT3RoZXJ3 aXNlLA0KYWxsIGRhdGFncmFtIHBhY2tldHMgdGhhdCBoYXZuJ3QgcmlnaHQgdG8gZm9yd2FyZCBh cmUgYWxsIA0KZGVsaXZlcmVkIHRvIENQVSwgdGhhbiBpdCB3aWxsIGJlIGZvcndhcmRlZCBieSBD UFUsIHRoaXMgaXMgDQphIGJhZGVyIGdyYW51bGFyaXR5IHRoYW4gc25vb3BpbmcgY29udHJvbCBw YWNrZXRzLg0KICAgDQpCZXN0IHJlZ2FyZHMNCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t LS0tIA0KRnJvbTogIkd1YW5nIFlhbyIgPHlhb2dAbmV0YXJjaGxhYi50c2luZ2h1YS5lZHUuY24+ DQpUbzogIidDaHJpc3RpYW4gVm9ndCciIDxjaHJpc3RpYW4udm9ndEBlcmljc3Nvbi5jb20+OyAi J0xpbiBUYW8nIiA8bGludEBoM2MuY29tPg0KQ2M6ICInRnJhbmsgWGlhJyIgPHhpYXlhbmdzb25n QGh1YXdlaS5jb20+OyAiJ01hcmNlbG8gQmFnbnVsbyBCcmF1biciIDxtYXJjZWxvQGl0LnVjM20u ZXM+OyAiJ1NBVkkgTWFpbGluZyBMaXN0JyIgPHNhdmlAaWV0Zi5vcmc+DQpTZW50OiBUdWVzZGF5 LCBEZWNlbWJlciAyMywgMjAwOCA4OjEyIFBNDQpTdWJqZWN0OiC08Li0OiBbc2F2aV0gV29ya2lu ZyBHcm91cCBBZG9wdGlvbiBvZiBJbmRpdmlkdWFsIFNBVkkgRG9jdW1lbnRzDQoNCg0KRGVhciBD aHJpc3RpYW4gYW5kIExpbiwNCg0KSXQncyBjbGVhciB0aGF0IHNub29waW5nIE5EIGNhbm5vdCBh Y2hpZXZlIGJldHRlciBwZXJmb3JtYW5jZSBhbmQgc2VjdXJpdHkgDQp0aGFuIHNub29waW5nIGRh dGEgdHJhZmZpYy4gQWN0dWFsbHkgc25vb3BpbmcgTkQgbWF5IGNvc3QgbW9yZSBmb3IgaXQgbXVz dA0KdHJhY2UgDQp0aGUgc3RhdGUgb2YgREFELg0KDQpCdXQgSU1PLCBpdCBpcyBub3QgYW4gaXNz dWUgb2YgcmVzb3VyY2Ugc2F2aW5nLCBidXQgYW4gaXNzdWUgdGhhdCB3aGF0IFNBVkkNCmlzIGlu dGVuZGluZw0KdG8gcHJvdGVjdC4gSWYgdGhlIFNBVkkgZGV2aWNlIHNub29wcyBORCB0byBiaW5k IGFkZHJlc3MgYW5kIGFuY2hvciwgaXQNCnByb3RlY3RzDQpnb29kIGd1eXMgd2hvIGFyZSB3b3Jr aW5nIGFjY29yZGluZyB0byB0aGUgc3RhbmRhcmQuIEJ1dCBpZiBpdCBzbm9vcHMgZGF0YQ0KdHJh ZmZpYyBhbmQNCmJpbmRzIGFkZHJlc3MgYW5kIGFuY2hvciB1c2luZyB0aGUgcHJpbmNpcGxlIG9m IEZDRlMsIGJhZCBiZWhhdmlvcnMsIHN1Y2ggYXMNCmF0dGFja3MgYWdhaW5zdA0KREFELCBhcmUg cHJvdGVjdGVkLiANCg0KTXIuIEZyZWQgQmFrZXIgb25jZSBnYXZlIHVzIGEgY29udmluY2luZyBl eGFtcGxlOiB3aGVuIGFuIGF0dGFja2VyIHJlY2VpdmVzDQphDQpEQUQgTlMsIGl0IGltbWVkaWF0 ZWx5IHNlbmRzIGEgcGFja2V0IHdpdGggc291cmNlIGFkZHJlc3Mgc2V0IHRvIHRoZSBUYXJnZXQN CkFkZHJlc3MgaW4gdGhlIE5TDQp0byBtYWtlIHRoZSBTQVZJIGRldmljZSBzZXQgdXAgYmluZGlu ZyB3aXRob3V0IHJlcGx5aW5nIGEgTkEuIFRoZW4gdGhlIERBRA0Kbm9kZSwgYWx0aG91Z2ggaGFz IGZpbmlzaGVkDQphIHN1Y2Nlc3NmdWwgREFELCBjYW5ub3QgdXNlIHRoZSB0ZW50YXRpdmUgYWRk cmVzcyBmb3IgdGhlIFNBVkkgZGV2aWNlIHdpbGwNCnRha2UgaXRzIHRyYWZmaWMgYXMgc3Bvb2Zp bmcgdHJhZmZpYy4NCg0KQWx0aG91Z2ggaXQgaXMgcmF0aGVyIGEgc2VjdXJpdHkgcHJvYmxlbSBv ZiBORCB0aGVuIHRoZSBmYXVsdCBvZiBTQVZJLCB0aGUNClNBVkkgZGV2aWNlIGlzDQpwcm90ZWN0 aW5nIGJhZCBkb2luZ3MgaW4gdGhlIGV4YW1wbGUuDQoNCkkgdGhpbmsgU0FWSSBzaG91bGQgYXQg bGVhc3QgcHJvdGVjdCBub3JtYWwgYmVoYXZpb3JzIGFuZCBnb29kIGd1eXMsIGJ1dCBub3QNCnBy b3RlY3QgYmFkIGJlaGF2aW9ycy4NCg0KSSBhbHNvIHRoaW5rIFNBVkkgc2hvdWxkIHByb3RlY3Qg dGhlIFRhcmdldCBBZGRyZXNzIGluIE5BIG1lc3NhZ2UsIGZvciBpdCBpcw0KYW5vdGhlciBraW5k IG9mIHNvdXJjZSBhZGRyZXNzLiANCg0KR3VhbmcNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjL OiBDaHJpc3RpYW4gVm9ndCBbbWFpbHRvOmNocmlzdGlhbi52b2d0QGVyaWNzc29uLmNvbV0gDQq3 osvNyrG85DogMjAwOMTqMTLUwjIzyNUgMTg6MzYNCsrVvP7IyzogTGluIFRhbw0Ks63LzTogRnJh bmsgWGlhOyBNYXJjZWxvIEJhZ251bG8gQnJhdW47IFNBVkkgTWFpbGluZyBMaXN0OyDSpiC54w0K 1vfM4jogUmU6IFtzYXZpXSBXb3JraW5nIEdyb3VwIEFkb3B0aW9uIG9mIEluZGl2aWR1YWwgU0FW SSBEb2N1bWVudHMNCg0KTGluIC0NCg0KSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IERvUyBpcyBhbiB1 bnNvbHZlZCBpc3N1ZSB0aGF0IHdlIGhhdmUgeWV0IHRvDQp0YWNrbGUuIEhvd2V2ZXIsIEkgZG9u J3QgdGhpbmsgd2UgY2FuIHNvbHZlIHRoZSBpc3N1ZSwgZm9yIGFsbCBhZGRyZXNzDQpjb25maWd1 cmF0aW9uIG1ldGhvZHMsIHNpbXBseSBieSBjaGFuZ2luZyB3aGljaCBwYWNrZXRzIHdlIHNub29w LiAgU0xBQUMNCmluIHBhcnRpY3VsYXIgaXMgYW4gYWRkcmVzcyBjb25maWd1cmF0aW9uIG1ldGhv ZCB3aGVyZSBhbiBhdHRhY2tlciBjYW4NCm92ZXJsb2FkIGEgU0FWSSBkZXZpY2UganVzdCBhcyBl YXNpbHkgd2l0aCBjb250cm9sIHBhY2tldHMgKGkuZS4sDQpOZWlnaGJvciBTb2xpY2l0YXRpb24g cGFja2V0cykgYXMgd2l0aCBkYXRhZ3JhbSBwYWNrZXRzLg0KDQpUaGUgb25seSBzY2VuYXJpbyBp biB3aGljaCBzbm9vcGluZyBjb250cm9sIHBhY2tldHMgaW5zdGVhZCBvZiBkYXRhZ3JhbQ0KcGFj a2V0cyBjb3VsZCBtaXRpZ2F0ZSB0aGUgRG9TIGlzc3VlIGlzIHdoZXJlIGFkZHJlc3NlcyBhcmUg ZXhjbHVzaXZlbHkNCmFzc2lnbmVkIHZpYSBESENQLiAgQSBTQVZJIGRldmljZSBjYW4gdGhlbiBl eGNsdXNpdmVseSByZWx5IG9uIG1lc3NhZ2VzDQpiZWluZyBzZW50IGJ5IGEgc2VydmVyIChub3Qg ZGlyZWN0bHkgYnkgdGhlIGF0dGFja2VyKSwgc3VjaCB0aGF0IGEgRG9TDQphdHRhY2sgYWdhaW5z dCBhIFNBVkkgZGV2aWNlIHJlZHVjZXMgdG8gdGhlIGV4aXN0aW5nIHRocmVhdCBvZiBhIERvUw0K YXR0YWNrIGFnYWluc3QgYSBESENQIHNlcnZlci4NCg0KRldJVzogIFNvbWUgU0FWSSBwYXJ0aWNp cGFudHMgd2VyZSBjb25zaWRlcmluZyBhIERIQ1Atb25seSBvcHRpb24gZm9yDQpTQVZJIGR1cmlu ZyBJRVRGIDczLg0KDQotIENocmlzdGlhbg0KDQoNCg0KT24gRGVjIDIyLCAyMDA4LCBMaW4gVGFv IHdyb3RlOg0KDQo+IEhlbGxvLCBDaHJpc3RpYW4sIE1hcmNlbG8gYW5kIEZyYW5rOg0KPg0KPiBJ IGFncmVlIHdpdGggRnJhbmsncyB2aWV3LiBCZWNhdXNlIHRoZSBmb3J3YXJkaW5nIHBhY2tldCBp cw0KPiBvYnNlcnZlZCBpbiBGQ0ZTIGRyYWZ0LCBzbyB0aGUgZm9yd2FyZGluZyBwcm9jZXNzIGlz IGRpc3J1cHRlZCwNCj4gYW5kIHRoZSBkZXZpY2UgaXMgdnVsbmVyYWJsZSwgZS5nLiBzYXZpIGNh Y2hlIHRhYmxlIGV4aGF1c3RlZCwNCj4gdGhlIGNwdSBvZiBzd2l0Y2ggYnVzeSwgZXRjLg0KPg0K PiBJbiBteSBvcGluaW9uLCBvYnNlcnZpbmcgdGhlIENvbnRyb2wgUHJvdG9jb2wsIGUuZy4gREhD UA0KPiBvciBORCBldGMsIGlzIGVhc3kgdG8gaW1wbGVtZW50IGluIHN3aXRjaCBmb3IgdGhlc2Ug cHJvdG9jb2wNCj4gaGF2ZSBzcGVjaWFsIGNoYXJhY3RlcmlzdGljIHRoYXQgY2FuIGJlIGZpbHRl cmVkIGluIHN3aXRjaCBwb3J0IHdoaWxlDQo+IHRoZSBmb3J3YXJkaW5nIHBhY2tldCBpcyBibG9j a2VkLg0KDQoNCg0K From ietfdbh@comcast.net Wed Dec 24 11:11:16 2008 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 4BB3C3A6973 for ; Wed, 24 Dec 2008 11:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 ClTuCegiRjlD for ; Wed, 24 Dec 2008 11:11:15 -0800 (PST) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 2A0D43A6A04 for ; Wed, 24 Dec 2008 11:11:15 -0800 (PST) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA01.westchester.pa.mail.comcast.net with comcast id v5EL1a00U0cZkys517B6id; Wed, 24 Dec 2008 19:11:06 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA10.westchester.pa.mail.comcast.net with comcast id v7B51a00Q0UQ6dC3W7B5vL; Wed, 24 Dec 2008 19:11:06 +0000 From: "David Harrington" To: "'MARCELO BAGNULO BRAUN'" , References: <00b001c96548$b6806bd0$0600a8c0@china.huawei.com> <20081224020122.p8webzgwgck8o4ok@webcartero01.uc3m.es> Date: Wed, 24 Dec 2008 14:11:05 -0500 Message-ID: <004301c965fb$5ef7bae0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20081224020122.p8webzgwgck8o4ok@webcartero01.uc3m.es> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcllYymMJ6xWLSjDTpSpZ55W0TtECQAl97kg Subject: Re: [savi] Working Group Adoption of Individual SAVI Documents X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2008 19:11:16 -0000 I also did not find draft-vogt-savi-rationale in the ID repository. dbh > -----Original Message----- > From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On > Behalf Of MARCELO BAGNULO BRAUN > Sent: Tuesday, December 23, 2008 8:01 PM > To: savi@ietf.org > Subject: Re: [savi] Working Group Adoption of Individual SAVI > Documents > > Correction, only one of these draft is expired, > draft-mcpherson-savi-threat-scope, (BTW you can easily find in > tools.ietf.org besides many other sites, such as waterspings > and so on) > > Regards, marcelo > > > David Harrington dijo: > > > Hi, > > > > It appears some of these drafts have expired. > > Can the drafts be re-published so people can look at them before > > making a decision? > > I suggest you extend the review period accordingly. > > > > David Harrington > > dbharrington@comcast.net > > ietfdbh@comcast.net > > dharrington@huawei.com > > > > > >> -----Original Message----- > >> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On > >> Behalf Of Christian Vogt > >> Sent: Thursday, December 18, 2008 12:15 AM > >> To: SAVI Mailing List > >> Subject: [savi] Working Group Adoption of Individual SAVI Documents > >> > >> Dear all - > >> > >> At the previous SAVI meeting in Minneapolis, we did a vote > regarding > >> which individual documents to use as starting points for the SAVI > >> working group deliverables. I would now like to confirm this > > decision > >> from Minneapolis here on the mailing list. > >> > >> The result of the vote in Minneapolis was thus: > >> > >> - To adopt draft-mcpherson-savi-threat-scope as a starting > >> point for the > >> Threats Analysis (Problem Statement) document: 7 in favour, 0 > >> against. > >> > >> - To adopt draft-vogt-savi-rationale as a starting point for the > >> Rationale document: 7 in favour, 0 against. > >> > >> - To adopt draft-bagnulo-savi-fcfs as a starting point for > >> both the IPv4 > >> and IPv6 Solution documents: 11 in favour, 2 against. > >> > >> - To adopt draft-bagnulo-savi-send as a starting point for the > >> SeND-based IPv6 Solution document: 8 in favour, 1 against. > >> > >> Arguments raised by those voting against the adoption of one of the > >> individual documents above related to potential security > >> vulnerabilities > >> or potential issues with mobile hosts. Both arguments would > >> need to be > >> addressed as the working group deliverables are being advanced. > >> > >> Please express on this mailing list whether or not you agree with > > the > >> above documents being adopted by the SAVI working group as starting > >> points for the various working group deliverables. Please also > > state > >> the reasons in case you are against one of the documents > >> being adopted. > >> > >> - Christian > >> > >> > >> _______________________________________________ > >> savi mailing list > >> savi@ietf.org > >> https://www.ietf.org/mailman/listinfo/savi > >> > > > > _______________________________________________ > > savi mailing list > > savi@ietf.org > > https://www.ietf.org/mailman/listinfo/savi > > > > > > -- > ---- > MARCELO BAGNULO BRAUN > WebCartero > Universidad Carlos III de Madrid > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From marcelo@it.uc3m.es Wed Dec 24 14:27:15 2008 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 9F6FA3A6909 for ; Wed, 24 Dec 2008 14:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.762 X-Spam-Level: X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 pRnTixWgxVln for ; Wed, 24 Dec 2008 14:27:14 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 00C5D3A68AC for ; Wed, 24 Dec 2008 14:27:12 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (r190-0-129-251.dialup.adsl.anteldata.net.uy [190.0.129.251])by smtp03.uc3m.es (Postfix) with ESMTP id 60AC672B5A8;Wed, 24 Dec 2008 23:26:56 +0100 (CET) Message-ID: <4952B72E.5080005@it.uc3m.es> Date: Wed, 24 Dec 2008 23:26:54 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: David Harrington References: <00b001c96548 $b6806bd0$0600a8c0@china.huawei.com> <20081224020122.p8webzgwgck8o4ok@webcartero01.uc3m.es> <004301c965fb$5ef7bae0$0600a8c0@china.huawei.com> In-Reply-To: <004301c965fb$5ef7bae0$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-22.8374 TC:1F TRN:54 TV:5.5.1026(16360.002) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: savi@ietf.org Subject: Re: [savi] Working Group Adoption of Individual SAVI Documents X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2008 22:27:15 -0000 indeed, you are right and this one is not available in any mirror (or i couldn't find it myself) sorry about that I think Christian sent it to the ml the link is http://users.piuha.net/chvogt/pub/2008/draft-vogt-savi-rationale-00.txt regards, marcelo David Harrington escribió: > I also did not find draft-vogt-savi-rationale in the ID repository. > > dbh > > >> -----Original Message----- >> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On >> Behalf Of MARCELO BAGNULO BRAUN >> Sent: Tuesday, December 23, 2008 8:01 PM >> To: savi@ietf.org >> Subject: Re: [savi] Working Group Adoption of Individual SAVI >> Documents >> >> Correction, only one of these draft is expired, >> draft-mcpherson-savi-threat-scope, (BTW you can easily find in >> tools.ietf.org besides many other sites, such as waterspings >> and so on) >> >> Regards, marcelo >> >> >> David Harrington dijo: >> >> >>> Hi, >>> >>> It appears some of these drafts have expired. >>> Can the drafts be re-published so people can look at them before >>> making a decision? >>> I suggest you extend the review period accordingly. >>> >>> David Harrington >>> dbharrington@comcast.net >>> ietfdbh@comcast.net >>> dharrington@huawei.com >>> >>> >>> >>>> -----Original Message----- >>>> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On >>>> Behalf Of Christian Vogt >>>> Sent: Thursday, December 18, 2008 12:15 AM >>>> To: SAVI Mailing List >>>> Subject: [savi] Working Group Adoption of Individual SAVI >>>> > Documents > >>>> Dear all - >>>> >>>> At the previous SAVI meeting in Minneapolis, we did a vote >>>> >> regarding >> >>>> which individual documents to use as starting points for the SAVI >>>> working group deliverables. I would now like to confirm this >>>> >>> decision >>> >>>> from Minneapolis here on the mailing list. >>>> >>>> The result of the vote in Minneapolis was thus: >>>> >>>> - To adopt draft-mcpherson-savi-threat-scope as a starting >>>> point for the >>>> Threats Analysis (Problem Statement) document: 7 in favour, 0 >>>> against. >>>> >>>> - To adopt draft-vogt-savi-rationale as a starting point for the >>>> Rationale document: 7 in favour, 0 against. >>>> >>>> - To adopt draft-bagnulo-savi-fcfs as a starting point for >>>> both the IPv4 >>>> and IPv6 Solution documents: 11 in favour, 2 against. >>>> >>>> - To adopt draft-bagnulo-savi-send as a starting point for the >>>> SeND-based IPv6 Solution document: 8 in favour, 1 against. >>>> >>>> Arguments raised by those voting against the adoption of one of >>>> > the > >>>> individual documents above related to potential security >>>> vulnerabilities >>>> or potential issues with mobile hosts. Both arguments would >>>> need to be >>>> addressed as the working group deliverables are being advanced. >>>> >>>> Please express on this mailing list whether or not you agree with >>>> >>> the >>> >>>> above documents being adopted by the SAVI working group as >>>> > starting > >>>> points for the various working group deliverables. Please also >>>> >>> state >>> >>>> the reasons in case you are against one of the documents >>>> being adopted. >>>> >>>> - Christian >>>> >>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>>> >>>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> >>> >> >> -- >> ---- >> MARCELO BAGNULO BRAUN >> WebCartero >> Universidad Carlos III de Madrid >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> >> > > > From zhangdong_rh@huaweisymantec.com Fri Dec 26 17:48:43 2008 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 7FD8B3A67B0 for ; Fri, 26 Dec 2008 17:48:43 -0800 (PST) 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 xc6+FPS0UUfe for ; Fri, 26 Dec 2008 17:48:42 -0800 (PST) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [121.15.168.142]) by core3.amsl.com (Postfix) with ESMTP id B40123A6781 for ; Fri, 26 Dec 2008 17:48:42 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KCI00J1LICTAE20@hstga01-in.huaweisymantec.com> for savi@ietf.org; Sat, 27 Dec 2008 09:48:31 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KCI00CICICR0020@hstml01-in.huaweisymantec.com> for savi@ietf.org; Sat, 27 Dec 2008 09:48:29 +0800 (CST) Received: from [10.27.140.93] by hstml01-in.huaweisymantec.com (mshttpd); Sat, 27 Dec 2008 09:48:27 +0800 From: ZhangDong To: marcelo bagnulo braun Message-id: Date: Sat, 27 Dec 2008 09:48:27 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal Cc: savi@ietf.org Subject: [savi] an edit error in fcfs X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2008 01:48:43 -0000 - o If an entry is found and the layer-2 information of the received - data packet does not match the information contained in the - existing matching entry, then the FCFS SAVI performs a Neighbor - Unreachability Detection procedure as described in [RFC4861] for - IPv4 and in Section 3.3 for IPv4. It uses the IP source address - and Layer-2 information available in the FCFS SAVI DB entry. It must be in [RFC4861] for IPv6. Dong Zhang Huawei Symantec Technologies Co., Ltd From zhangdong_rh@huaweisymantec.com Fri Dec 26 23:20:02 2008 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 2637A28C0E9 for ; Fri, 26 Dec 2008 23:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.962 X-Spam-Level: * X-Spam-Status: No, score=1.962 tagged_above=-999 required=5 tests=[AWL=-3.073, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] 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 dHQPga1MOCFR for ; Fri, 26 Dec 2008 23:20:01 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id DEE933A67AB for ; Fri, 26 Dec 2008 23:20:00 -0800 (PST) MIME-version: 1.0 Content-disposition: inline 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-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KCI00IQBXOZ5I40@hstga02-in.huaweisymantec.com> for savi@ietf.org; Sat, 27 Dec 2008 15:19:49 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KCI003KFXOXS000@hstml01-in.huaweisymantec.com> for savi@ietf.org; Sat, 27 Dec 2008 15:19:47 +0800 (CST) Received: from [10.27.140.93] by hstml01-in.huaweisymantec.com (mshttpd); Sat, 27 Dec 2008 15:19:45 +0800 From: ZhangDong To: marcelo bagnulo braun Message-id: Date: Sat, 27 Dec 2008 15:19:45 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <494AA050.2060300@it.uc3m.es> References: <005901c96128$ea3185f0$420c7c0a@china.huawei.com> <494AA050.2060300@it.uc3m.es> Content-transfer-encoding: quoted-printable Cc: SAVI Mailing List , Christian Vogt , Frank Xia Subject: [savi] =?gb2312?b?u9i4tDogUmU6ICBXb3JraW5nIEdyb3VwIEFkb3B0aW9u?= =?gb2312?b?IG9mIEluZGl2aWR1YWwgU0FWSSBEb2N1bWVudHM=?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2008 07:20:02 -0000 Hi=2C Perhaps there is another potential danger that should be considered=2E One node may have more than one IP addresses=2C but only one interface i= n IPv6=2E We assume that node X has IPa and IPb=2E Its layer-2 address is MACx=2E = According to FCFS=2C firstly node X uses IPa=2E A entry with IPa and MAC= x is created in SAVI device DB=2E The node X uses IPb=2E And another ent= ry with IPb and MACx also is created=2E The node X may use IPb all the t= ime=2E Now we should note that if an attacker sends packets with IPa and= MACx=2C the SAVI device will do nothing but forwarding the forged packe= ts=2E This case must be faced by FCFS=2E Dong Zhang ----- =D4=AD=CA=BC=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A marcelo bagnulo braun =3Cmarcelo=40it=2Euc3m=2Ees=3E= =C8=D5=C6=DA=3A 2008=C4=EA 12=D4=C2 19=C8=D5=2C =D0=C7=C6=DA=CE=E5=2C =C9= =CF=CE=E73=3A11 =D6=F7=CC=E2=3A Re=3A =5Bsavi=5D Working Group Adoption of Individual SA= VI Documents =CA=D5=BC=FE=C8=CB=3A Frank Xia =3Cxiayangsong=40huawei=2Ecom=3E =B3=AD=CB=CD=3A SAVI Mailing List =3Csavi=40ietf=2Eorg=3E=2C Christian V= ogt =3Cchristian=2Evogt=40ericsson=2Ecom=3E =3E Hi Frank=2C =3E = =3E some comments below=2E=2E=2E =3E = =3E Frank Xia escribi=A8=AE=3A =3E =3E Hi Christian =3E =3E =3E =3E I was not in the against list of FCFS=2C however=2C =3E =3E I did express my concerns of the solution=2E =3E =3E =3E =3E The main idea is trying to build a =3E =3E source address validation rule using the first data packet=2E = IMHO=2C = =3E = =3E =3E this solution is vulnerable=2E =3E =3E =3E =3E It seems to be hard to deal with the following scenarios=3A =3E =3E 1)A host is authorized to use a static address=2C while =3E =3E the host does not connect the network =3E right=2C we need to think how to deal with this case =3E one obvious option is that since the address is manually configured= = =3E in = =3E the host=2C it can also be manually included in the SAVI cache=2C s= o it = =3E knows that has been manually assigned =3E I understand that some people actually manually configure MAC- IP = =3E address associations to perform this type of checks =3E = =3E =3E =3E =3E 2)A IPv6 host periodically changes it=27s interface ID =3E =3E from privacy consideration=2E =3E not sure why this is a problem=2C could you expand=3F =3E = =3E =3E 3)In dynamic address configuration=2C an IP address =3E =3E can be reused by other hosts=2E =3E =3E =3E this is no problem=2C the current draft actually deals with this =3E = =3E Regards=2C marcelo =3E = =3E = =3E =3E BR =3E =3E Frank =3E =3E =3E =3E =3E =3E ----- Original Message ----- From=3A =22Christian Vogt=22 = =3E =3E =3Cchristian=2Evogt=40ericsson=2Ecom=3E =3E =3E To=3A =22SAVI Mailing List=22 =3Csavi=40ietf=2Eorg=3E =3E =3E Sent=3A Wednesday=2C December 17=2C 2008 11=3A14 PM =3E =3E Subject=3A =5Bsavi=5D Working Group Adoption of Individual SAVI= Documents =3E =3E =3E =3E =3E =3E=3E Dear all - =3E =3E=3E =3E =3E=3E At the previous SAVI meeting in Minneapolis=2C we did a vote= regarding =3E =3E=3E which individual documents to use as starting points for the= SAVI =3E =3E=3E working group deliverables=2E I would now like to confirm t= his decision =3E =3E=3E from Minneapolis here on the mailing list=2E =3E =3E=3E =3E =3E=3E The result of the vote in Minneapolis was thus=3A =3E =3E=3E =3E =3E=3E - To adopt draft-mcpherson-savi-threat-scope as a starting p= oint = =3E for the =3E =3E=3E Threats Analysis (Problem Statement) document=3A 7 in fav= our=2C 0 =3E =3E=3E against=2E =3E =3E=3E =3E =3E=3E - To adopt draft-vogt-savi-rationale as a starting point for= the =3E =3E=3E Rationale document=3A 7 in favour=2C 0 against=2E =3E =3E=3E =3E =3E=3E - To adopt draft-bagnulo-savi-fcfs as a starting point for b= oth = =3E the IPv4 =3E =3E=3E and IPv6 Solution documents=3A 11 in favour=2C 2 against=2E= =3E =3E=3E =3E =3E=3E - To adopt draft-bagnulo-savi-send as a starting point for t= he =3E =3E=3E SeND-based IPv6 Solution document=3A 8 in favour=2C 1 aga= inst=2E =3E =3E=3E =3E =3E=3E Arguments raised by those voting against the adoption of one= of the =3E =3E=3E individual documents above related to potential security vul= nerabilities =3E =3E=3E or potential issues with mobile hosts=2E Both arguments wou= ld need = =3E to be =3E =3E=3E addressed as the working group deliverables are being advanc= ed=2E =3E =3E=3E =3E =3E=3E Please express on this mailing list whether or not you agree= with = =3E the =3E =3E=3E above documents being adopted by the SAVI working group as s= tarting =3E =3E=3E points for the various working group deliverables=2E Please= also state =3E =3E=3E the reasons in case you are against one of the documents bei= ng adopted=2E =3E =3E=3E =3E =3E=3E - Christian =3E =3E=3E =3E =3E=3E =3E =3E=3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F =3E =3E=3E savi mailing list =3E =3E=3E savi=40ietf=2Eorg =3E =3E=3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/savi =3E =3E=3E =3E =3E =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F =3E =3E savi mailing list =3E =3E savi=40ietf=2Eorg =3E =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/savi =3E =3E =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =3E savi mailing list =3E savi=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/savi =3E From marcelo@it.uc3m.es Sat Dec 27 03:45:25 2008 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 20B8A3A690F for ; Sat, 27 Dec 2008 03:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.234 X-Spam-Level: X-Spam-Status: No, score=-4.234 tagged_above=-999 required=5 tests=[AWL=-0.473, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 qP4igZi81JCm for ; Sat, 27 Dec 2008 03:45:24 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 5392F3A66B4 for ; Sat, 27 Dec 2008 03:45:23 -0800 (PST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131])by smtp02.uc3m.es (Postfix) with ESMTP id CBF39654666;Sat, 27 Dec 2008 12:45:12 +0100 (CET) Received: from r190-132-69-34.dialup.mobile.ancel.net.uy(r190-132-69-34.dialup.mobile.ance l.net.uy [190.132.69.34]) bywebcartero01.uc3m.es (Horde MIME library) with HTTP; Sat, 27 Dec 200812:45:11 +0100 Message-ID: <20081227124511.7prrxe3s5c4cw8oo@webcartero01.uc3m.es> Date: Sat, 27 Dec 2008 12:45:11 +0100 From: MARCELO BAGNULO BRAUN To: ZhangDong References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-10.6653 TC:1F TRN:15 TV:5.5.1026(16364.006) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: savi@ietf.org Subject: Re: [savi] an edit error in fcfs X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2008 11:45:25 -0000 right, thanks ZhangDong dijo: > - o If an entry is found and the layer-2 information of the received > - data packet does not match the information contained in the > - existing matching entry, then the FCFS SAVI performs a Neighbor > - Unreachability Detection procedure as described in [RFC4861] for > - IPv4 and in Section 3.3 for IPv4. It uses the IP source address > - and Layer-2 information available in the FCFS SAVI DB entry. > > It must be in [RFC4861] for IPv6. > > > > Dong Zhang > Huawei Symantec Technologies Co., Ltd > > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid From marcelo@it.uc3m.es Sat Dec 27 03:49:15 2008 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 9EAAF3A6A76 for ; Sat, 27 Dec 2008 03:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.116 X-Spam-Level: X-Spam-Status: No, score=-4.116 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 NPluuDQCDk0T for ; Sat, 27 Dec 2008 03:49:14 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 4FA593A68C2 for ; Sat, 27 Dec 2008 03:49:14 -0800 (PST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131])by smtp03.uc3m.es (Postfix) with ESMTP id A3DB172B603;Sat, 27 Dec 2008 12:48:59 +0100 (CET) Received: from r190-132-69-34.dialup.mobile.ancel.net.uy(r190-132-69-34.dialup.mobile.ance l.net.uy [190.132.69.34]) bywebcartero01.uc3m.es (Horde MIME library) with HTTP; Sat, 27 Dec 200812:48:58 +0100 Message-ID: <20081227124858.1wm47cvvuckw48ck@webcartero01.uc3m.es> Date: Sat, 27 Dec 2008 12:48:58 +0100 From: MARCELO BAGNULO BRAUN To: ZhangDong References: <005901c96128 $ea3185f0$420c7c0a@china.huawei.com> <494AA050.2060300@it.uc3m.es> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-39.3177 TC:1F TRN:71 TV:5.5.1026(16364.006) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: SAVI Mailing List , Christian Vogt , Frank Xia Subject: Re: [savi] ??: Re: Working Group Adoption of Individual SAVIDocuments X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2008 11:49:15 -0000 Hi, ZhangDong dijo: > Hi, > > Perhaps there is another potential danger that should be considered. > One node may have more than one IP addresses, but only one interface in I= Pv6. > We assume that node X has IPa and IPb. Its layer-2 address is MACx. > According to FCFS, firstly node X uses IPa. A entry with IPa and MACx > is created in SAVI device DB. The node X uses IPb. And another entry > with IPb and MACx also is created. The node X may use IPb all the > time. Now we should note that if an attacker sends packets with IPa > and MACx, the SAVI device will do nothing but forwarding the forged > packets. i don't see the problem here. I mean, this is exactly the same case as if the node has a sinlgle IP address and the attacker sends a packet spoofing both the mac address and the IP address. IF we are using mac address as lower layer anchors, there is not much we can do about this. So, basically, i don't understand why having multipla IP addresses make things any worse than with a single IP address and second, i guess any solution is limited by the strength of the lower level anchor we use, but we knew this already, i guess regards, marcelo > > This case must be faced by FCFS. > > > Dong Zhang > > > > ----- ???? ----- > ???: marcelo bagnulo braun > ??: 2008? 12? 19?, ???, ??3:11 > ??: Re: [savi] Working Group Adoption of Individual SAVI Documents > ???: Frank Xia > ??: SAVI Mailing List , Christian Vogt > > > >> Hi Frank, >> >> some comments below... >> >> Frank Xia escribi=F3: >> > Hi Christian >> > >> > I was not in the against list of FCFS, however, >> > I did express my concerns of the solution. >> > >> > The main idea is trying to build a >> > source address validation rule using the first data packet. IMHO, >> >> > this solution is vulnerable. >> > >> > It seems to be hard to deal with the following scenarios: >> > 1)A host is authorized to use a static address, while >> > the host does not connect the network >> right, we need to think how to deal with this case >> one obvious option is that since the address is manually configured >> in >> the host, it can also be manually included in the SAVI cache, so it >> knows that has been manually assigned >> I understand that some people actually manually configure MAC- IP >> address associations to perform this type of checks >> >> > >> > 2)A IPv6 host periodically changes it's interface ID >> > from privacy consideration. >> not sure why this is a problem, could you expand? >> >> > 3)In dynamic address configuration, an IP address >> > can be reused by other hosts. >> > >> this is no problem, the current draft actually deals with this >> >> Regards, marcelo >> >> >> > BR >> > Frank >> > >> > >> > ----- Original Message ----- From: "Christian Vogt" >> > >> > To: "SAVI Mailing List" >> > Sent: Wednesday, December 17, 2008 11:14 PM >> > Subject: [savi] Working Group Adoption of Individual SAVI Documents >> > >> > >> >> Dear all - >> >> >> >> At the previous SAVI meeting in Minneapolis, we did a vote regarding >> >> which individual documents to use as starting points for the SAVI >> >> working group deliverables. I would now like to confirm this decisi= on >> >> from Minneapolis here on the mailing list. >> >> >> >> The result of the vote in Minneapolis was thus: >> >> >> >> - To adopt draft-mcpherson-savi-threat-scope as a starting point >> for the >> >> Threats Analysis (Problem Statement) document: 7 in favour, 0 >> >> against. >> >> >> >> - To adopt draft-vogt-savi-rationale as a starting point for the >> >> Rationale document: 7 in favour, 0 against. >> >> >> >> - To adopt draft-bagnulo-savi-fcfs as a starting point for both >> the IPv4 >> >> and IPv6 Solution documents: 11 in favour, 2 against. >> >> >> >> - To adopt draft-bagnulo-savi-send as a starting point for the >> >> SeND-based IPv6 Solution document: 8 in favour, 1 against. >> >> >> >> Arguments raised by those voting against the adoption of one of the >> >> individual documents above related to potential security vulnerabili= ties >> >> or potential issues with mobile hosts. Both arguments would need >> to be >> >> addressed as the working group deliverables are being advanced. >> >> >> >> Please express on this mailing list whether or not you agree with >> the >> >> above documents being adopted by the SAVI working group as starting >> >> points for the various working group deliverables. Please also stat= e >> >> the reasons in case you are against one of the documents being adopt= ed. >> >> >> >> - Christian >> >> >> >> >> >> _______________________________________________ >> >> savi mailing list >> >> savi@ietf.org >> >> https://www.ietf.org/mailman/listinfo/savi >> >> >> > >> > _______________________________________________ >> > savi mailing list >> > savi@ietf.org >> > https://www.ietf.org/mailman/listinfo/savi >> > >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid From marcelo@it.uc3m.es Sun Dec 28 12:11:48 2008 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 346383A69F5 for ; Sun, 28 Dec 2008 12:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.872 X-Spam-Level: *** X-Spam-Status: No, score=3.872 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 M25fEJGjxZxN for ; Sun, 28 Dec 2008 12:11:43 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id F2B913A68DF for ; Sun, 28 Dec 2008 12:11:42 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [200.40.4.98])by smtp03.uc3m.es (Postfix) with ESMTP id 921BF6ECECB;Sun, 28 Dec 2008 21:11:18 +0100 (CET) Message-ID: <4957CF87.9050601@it.uc3m.es> Date: Sun, 28 Dec 2008 20:12:07 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Guang Yao References: <005901c96128$ea3185f0$420c7c0a@china.huawei.com> <494AA050.2060300@it.uc3m.es> <7141029F-A8F2-4892-977A-BFF510A405B7@ericsson.com> <002601c9641a$a6446fc0$2211990a@h3c.huawei3com.com> <60D2E2DD-9815-4374-9A48-EC646396198E@ericsson.com> <008901c964f7$ca10ad00$5e320700$@tsinghua.edu.cn> In-Reply-To: <008901c964f7$ca10ad00$5e320700$@tsinghua.edu.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-35.4376 TC:1F TRN:52 TV:5.5.1026(16368.001) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: 'Lin Tao' , 'SAVI Mailing List' , 'Christian Vogt' , 'Frank Xia' Subject: Re: [savi] =?gb2312?b?tPC4tDogIFdvcmtpbmcgR3JvdXAgQWRvcHRpb24gb2Yg?= =?gb2312?b?SW5kaXZpZHVhbCBTQVZJIERvY3VtZW50cw==?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Dec 2008 20:11:48 -0000 Guang Yao escribi¨®: > Dear Christian and Lin, > > It's clear that snooping ND cannot achieve better performance and security > than snooping data traffic. Actually snooping ND may cost more for it must > trace > the state of DAD. > > But IMO, it is not an issue of resource saving, but an issue that what SAVI > is intending > to protect. If the SAVI device snoops ND to bind address and anchor, it > protects > good guys who are working according to the standard. But if it snoops data > traffic and > binds address and anchor using the principle of FCFS, bad behaviors, such as > attacks against > DAD, are protected. > > Mr. Fred Baker once gave us a convincing example: when an attacker receives > a > DAD NS, it immediately sends a packet with source address set to the Target > Address in the NS > to make the SAVI device set up binding without replying a NA. Then the DAD > node, although has finished > a successful DAD, cannot use the tentative address for the SAVI device will > take its traffic as spoofing traffic. > > but the attacker could send a NADV replying to the DAD NS and would achieve the same effect in a NS-based SAVI approach, wouldn't it? I mean, i fail to see how you improve security if you rely on ND than when you rely on data packets... (FWIW, this is completelly orthogonal to the FCFS appraoch, since FCFS may apply both to data packets or to ND packets) Regards, marcelo > Although it is rather a security problem of ND then the fault of SAVI, the > SAVI device is > protecting bad doings in the example. > > I think SAVI should at least protect normal behaviors and good guys, but not > protect bad behaviors. > > I also think SAVI should protect the Target Address in NA message, for it is > another kind of source address. > > Guang > -----ÓʼþÔ­¼þ----- > ·¢¼þÈË: Christian Vogt [mailto:christian.vogt@ericsson.com] > ·¢ËÍʱ¼ä: 2008Äê12ÔÂ23ÈÕ 18:36 > ÊÕ¼þÈË: Lin Tao > ³­ËÍ: Frank Xia; Marcelo Bagnulo Braun; SAVI Mailing List; Ò¦ ¹ã > Ö÷Ìâ: Re: [savi] Working Group Adoption of Individual SAVI Documents > > Lin - > > I agree with you that DoS is an unsolved issue that we have yet to > tackle. However, I don't think we can solve the issue, for all address > configuration methods, simply by changing which packets we snoop. SLAAC > in particular is an address configuration method where an attacker can > overload a SAVI device just as easily with control packets (i.e., > Neighbor Solicitation packets) as with datagram packets. > > The only scenario in which snooping control packets instead of datagram > packets could mitigate the DoS issue is where addresses are exclusively > assigned via DHCP. A SAVI device can then exclusively rely on messages > being sent by a server (not directly by the attacker), such that a DoS > attack against a SAVI device reduces to the existing threat of a DoS > attack against a DHCP server. > > FWIW: Some SAVI participants were considering a DHCP-only option for > SAVI during IETF 73. > > - Christian > > > > On Dec 22, 2008, Lin Tao wrote: > > >> Hello, Christian, Marcelo and Frank: >> >> I agree with Frank's view. Because the forwarding packet is >> observed in FCFS draft, so the forwarding process is disrupted, >> and the device is vulnerable, e.g. savi cache table exhausted, >> the cpu of switch busy, etc. >> >> In my opinion, observing the Control Protocol, e.g. DHCP >> or ND etc, is easy to implement in switch for these protocol >> have special characteristic that can be filtered in switch port while >> the forwarding packet is blocked. >> > > > > > > From marcelo@it.uc3m.es Sun Dec 28 12:11:54 2008 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 36CD73A6B6A for ; Sun, 28 Dec 2008 12:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.45 X-Spam-Level: * X-Spam-Status: No, score=1.45 tagged_above=-999 required=5 tests=[AWL=2.422, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_BAD_ID=2.837, 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 xvmhVtv+52vk for ; Sun, 28 Dec 2008 12:11:51 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 6AF153A6B62 for ; Sun, 28 Dec 2008 12:11:51 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [200.40.4.98])by smtp02.uc3m.es (Postfix) with ESMTP id 64D29654855;Sun, 28 Dec 2008 21:11:34 +0100 (CET) Message-ID: <4957D0DB.8050304@it.uc3m.es> Date: Sun, 28 Dec 2008 20:17:47 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Lin Tao References: <005901c96128 $ea3185f0$420c7c0a@china.huawei.com><494AA050.2060300@it.uc3m.es><7141029F - A8F2-4892-977A-BFF510A405B7@ericsson.com><002601c9641a$a6446fc0$2211990a@ h3 c.huawei3com.com><60D2E2DD-9815-4374-9A48-EC646396198E@ericsson.com><008 901c964f7$ca10ad00$5e320700$@tsinghua.edu.cn> <013001c965ae$ce9efa90$8311990a@h3c.huawei3com.com> In-Reply-To: <013001c965ae$ce9efa90$8311990a@h3c.huawei3com.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-39.6912 TC:1F TRN:59 TV:5.5.1026(16368.001) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Guang Yao , 'SAVI Mailing List' , 'Christian Vogt' , 'Frank Xia' Subject: Re: [savi] Working Group Adoption of Individual SAVI Documents X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Dec 2008 20:11:54 -0000 Lin Tao escribi¨®: > Dear Christian, Guang and Marcelo, > > I agree with Guang that the normal behaviors and good guys > MUST be protected, so we should snoop at control packets than > datagram packets. I fail to see why this is so could you expand? regards, marcelo > This is the worthest thing in SAVI. > There is two plane in SWITCH: ASIC and CPU, it > is easy to implement ACL in ASIC to filter control packets to > CPU, and the datagram packets is discarded by default. Otherwise, > all datagram packets that havn't right to forward are all > delivered to CPU, than it will be forwarded by CPU, this is > a bader granularity than snooping control packets. > > Best regards > > > ----- Original Message ----- > From: "Guang Yao" > To: "'Christian Vogt'" ; "'Lin Tao'" > Cc: "'Frank Xia'" ; "'Marcelo Bagnulo Braun'" ; "'SAVI Mailing List'" > Sent: Tuesday, December 23, 2008 8:12 PM > Subject: ´ð¸´: [savi] Working Group Adoption of Individual SAVI Documents > > > Dear Christian and Lin, > > It's clear that snooping ND cannot achieve better performance and security > than snooping data traffic. Actually snooping ND may cost more for it must > trace > the state of DAD. > > But IMO, it is not an issue of resource saving, but an issue that what SAVI > is intending > to protect. If the SAVI device snoops ND to bind address and anchor, it > protects > good guys who are working according to the standard. But if it snoops data > traffic and > binds address and anchor using the principle of FCFS, bad behaviors, such as > attacks against > DAD, are protected. > > Mr. Fred Baker once gave us a convincing example: when an attacker receives > a > DAD NS, it immediately sends a packet with source address set to the Target > Address in the NS > to make the SAVI device set up binding without replying a NA. Then the DAD > node, although has finished > a successful DAD, cannot use the tentative address for the SAVI device will > take its traffic as spoofing traffic. > > Although it is rather a security problem of ND then the fault of SAVI, the > SAVI device is > protecting bad doings in the example. > > I think SAVI should at least protect normal behaviors and good guys, but not > protect bad behaviors. > > I also think SAVI should protect the Target Address in NA message, for it is > another kind of source address. > > Guang > -----ÓʼþÔ­¼þ----- > ·¢¼þÈË: Christian Vogt [mailto:christian.vogt@ericsson.com] > ·¢ËÍʱ¼ä: 2008Äê12ÔÂ23ÈÕ 18:36 > ÊÕ¼þÈË: Lin Tao > ³­ËÍ: Frank Xia; Marcelo Bagnulo Braun; SAVI Mailing List; Ò¦ ¹ã > Ö÷Ìâ: Re: [savi] Working Group Adoption of Individual SAVI Documents > > Lin - > > I agree with you that DoS is an unsolved issue that we have yet to > tackle. However, I don't think we can solve the issue, for all address > configuration methods, simply by changing which packets we snoop. SLAAC > in particular is an address configuration method where an attacker can > overload a SAVI device just as easily with control packets (i.e., > Neighbor Solicitation packets) as with datagram packets. > > The only scenario in which snooping control packets instead of datagram > packets could mitigate the DoS issue is where addresses are exclusively > assigned via DHCP. A SAVI device can then exclusively rely on messages > being sent by a server (not directly by the attacker), such that a DoS > attack against a SAVI device reduces to the existing threat of a DoS > attack against a DHCP server. > > FWIW: Some SAVI participants were considering a DHCP-only option for > SAVI during IETF 73. > > - Christian > > > > On Dec 22, 2008, Lin Tao wrote: > > >> Hello, Christian, Marcelo and Frank: >> >> I agree with Frank's view. Because the forwarding packet is >> observed in FCFS draft, so the forwarding process is disrupted, >> and the device is vulnerable, e.g. savi cache table exhausted, >> the cpu of switch busy, etc. >> >> In my opinion, observing the Control Protocol, e.g. DHCP >> or ND etc, is easy to implement in switch for these protocol >> have special characteristic that can be filtered in switch port while >> the forwarding packet is blocked. >> > > > > From marcelo@it.uc3m.es Mon Dec 29 10:07:40 2008 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 0FD3E3A6C57 for ; Mon, 29 Dec 2008 10:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.661 X-Spam-Level: ** X-Spam-Status: No, score=2.661 tagged_above=-999 required=5 tests=[AWL=-1.211, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 yOkDYURg2eLt for ; Mon, 29 Dec 2008 10:07:38 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 434653A677C for ; Mon, 29 Dec 2008 10:07:37 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [200.40.4.181])by smtp02.uc3m.es (Postfix) with ESMTP id 4A9F3654890;Mon, 29 Dec 2008 19:07:15 +0100 (CET) Message-ID: <49590EF6.4080407@it.uc3m.es> Date: Mon, 29 Dec 2008 18:55:02 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Guang Yao References: <005901c96128$ea3185f0$420c7c0a@china.huawei.com> <494AA050.2060300@it.uc3m.es> <7141029F-A8F2-4892-977A-BFF510A405B7@ericsson.com> <002601c9641a$a6446fc0$2211990a@h3c.huawei3com.com> <60D2E2DD-9815-4374-9A48-EC646396198E@ericsson.com> <008901c964f7$ca10ad00$5e320700$@tsinghua.edu.cn> <4957CF87.9050601@it.uc3m.es> <001001c96973$3b508ce0$b1f1a6a0$@tsinghua.edu.cn> In-Reply-To: <001001c96973$3b508ce0$b1f1a6a0$@tsinghua.edu.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-34.5490 TC:1F TRN:79 TV:5.5.1026(16370.001) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: 'Lin Tao' , 'SAVI Mailing List' , 'Christian Vogt' , 'Frank Xia' Subject: Re: [savi] =?gb2312?b?tPC4tDogtPC4tDogIFdvcmtpbmcgR3JvdXAgQWRvcHRp?= =?gb2312?b?b24gb2YgSW5kaXZpZHVhbCBTQVZJIERvY3VtZW50cw==?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2008 18:07:40 -0000 Guang Yao escribi¨®: > -----ÓʼþÔ­¼þ----- > ·¢¼þÈË: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > ·¢ËÍʱ¼ä: 2008Äê12ÔÂ29ÈÕ 3:12 > ÊÕ¼þÈË: Guang Yao > ³­ËÍ: 'Christian Vogt'; 'Lin Tao'; 'Frank Xia'; 'SAVI Mailing List' > Ö÷Ìâ: Re: ´ð¸´: [savi] Working Group Adoption of Individual SAVI Documents > > Guang Yao escribi¨®: > >> Dear Christian and Lin, >> >> It's clear that snooping ND cannot achieve better performance and security >> > > >> than snooping data traffic. Actually snooping ND may cost more for it must >> trace >> the state of DAD. >> >> But IMO, it is not an issue of resource saving, but an issue that what >> > SAVI > >> is intending >> to protect. If the SAVI device snoops ND to bind address and anchor, it >> protects >> good guys who are working according to the standard. But if it snoops data >> traffic and >> binds address and anchor using the principle of FCFS, bad behaviors, such >> > as > >> attacks against >> DAD, are protected. >> >> Mr. Fred Baker once gave us a convincing example: when an attacker >> > receives > >> a >> DAD NS, it immediately sends a packet with source address set to the >> > Target > >> Address in the NS >> to make the SAVI device set up binding without replying a NA. Then the DAD >> node, although has finished >> a successful DAD, cannot use the tentative address for the SAVI device >> > will > >> take its traffic as spoofing traffic. >> >> >> > but the attacker could send a NADV replying to the DAD NS and would > achieve the same effect in a NS-based SAVI approach, wouldn't it? > I mean, i fail to see how you improve security if you rely on ND than > when you rely on data packets... (FWIW, this is completelly orthogonal > to the FCFS appraoch, since FCFS may apply both to data packets or to ND > packets) > > Regards, marcelo > > No, it wouldn't. Because the attacker has not finished a DAD to achieve the > ownership > of the Target Address in the NADV message, the SAVI device wouldn't bind > this address > with its anchor. And in this situation, the tentative node just fails to get > an address and it > knows that clearly. But in FCFS case, it doesn't know the address assigned > has been bound > with another node, and it will try to send "spoofing" packets. > > right, i agree that the failure modes are different. I think we are having two somehow orthogonal issues here: - On one hand we are discussing what is the type of address ownership proof that we want to have. I think that irrespectively whether you use control messages or data packets, you can use the FCFS principle as address ownership. I mean, in both cases, the first node that sends a packet with a given address claims the address ownership. The first packet can be a data packet or a NS or NADV packet, but it is FCFS principle all the way. I don't thing you are propising a different address ownership proof afaict - On the other hand, there is the disucssion if we do this based on data packets or using control packets, in particular NSol and NAdv). I don't have a problem in doing it in both. I don't think you can do it only with control packets. In particular, consider the case of optimistic DAD. In that case, the node starts using the address even wihtout having the DAD completed. Moreover, DAD is a one time operation that is succesfull when there is no reply. So if we have a transite failure duringt he DAD period, and packets are not delivered to the SAVI device during that time, SAVI would fail. I do agree that it would be interesting to evaluate if looking into ND messages could help to prevent some scenarion as the one you mention above. But i think that a solution that solely relies in ND messages would be not very robust (i.e. it would fail if the DAD packet is lost for instance) > And I mentioned SAVI must control the NA messages, for the Target Address in > the NA message is another kind of source address. If the SAVI device has set > up > a binding table, it can filter spoofed NA with ease. > > It may be argued that in any situation, a node can avoid replying to NS > message even the > Target Address has been assigned to it, and the tentative node will be > assigned duplicated and "spoofing" address. > But still it is very different because the probability for two node to > generate same address is little and the possible damage > Is trivial. > But if an attacker designedly attacks against the tentative address, the > consequence is very bad. Unfortunately, FCFS > using data traffic makes this situation possible. > > IMO, binding address using data traffic is wrong because data traffic is not > defined to have the > function of assigning address to node. It is the necessary condition but not > sufficient condition. > > > but the problem is that there is no sufficient condition for knowing that a node has configured an address. I mean, DAD messages can be lost and they are only sent once in a nion reliable fashion. In addition, nodes do optimistic DAD and start using the address without waiting for the DAD to be completed. So, if you want to design a robust mechanism you need to deal with all that, and using data packets seem the ultimate line (In order to deal with the attack you mention, the SAVI device can sniff DAD packets and identify the suggested attacks if it first sees a DAD packet and then a data packet with the same address and no DAD reply to the original request... of course this makes the logic more comlex) Regards, marcelo >> Although it is rather a security problem of ND then the fault of SAVI, the >> SAVI device is >> protecting bad doings in the example. >> >> I think SAVI should at least protect normal behaviors and good guys, but >> > not > >> protect bad behaviors. >> >> I also think SAVI should protect the Target Address in NA message, for it >> > is > >> another kind of source address. >> >> Guang >> -----ÓʼþÔ­¼þ----- >> ·¢¼þÈË: Christian Vogt [mailto:christian.vogt@ericsson.com] >> ·¢ËÍʱ¼ä: 2008Äê12ÔÂ23ÈÕ 18:36 >> ÊÕ¼þÈË: Lin Tao >> ³­ËÍ: Frank Xia; Marcelo Bagnulo Braun; SAVI Mailing List; Ò¦ ¹ã >> Ö÷Ìâ: Re: [savi] Working Group Adoption of Individual SAVI Documents >> >> Lin - >> >> I agree with you that DoS is an unsolved issue that we have yet to >> tackle. However, I don't think we can solve the issue, for all address >> configuration methods, simply by changing which packets we snoop. SLAAC >> in particular is an address configuration method where an attacker can >> overload a SAVI device just as easily with control packets (i.e., >> Neighbor Solicitation packets) as with datagram packets. >> >> The only scenario in which snooping control packets instead of datagram >> packets could mitigate the DoS issue is where addresses are exclusively >> assigned via DHCP. A SAVI device can then exclusively rely on messages >> being sent by a server (not directly by the attacker), such that a DoS >> attack against a SAVI device reduces to the existing threat of a DoS >> attack against a DHCP server. >> >> FWIW: Some SAVI participants were considering a DHCP-only option for >> SAVI during IETF 73. >> >> - Christian >> >> >> >> On Dec 22, 2008, Lin Tao wrote: >> >> >> >>> Hello, Christian, Marcelo and Frank: >>> >>> I agree with Frank's view. Because the forwarding packet is >>> observed in FCFS draft, so the forwarding process is disrupted, >>> and the device is vulnerable, e.g. savi cache table exhausted, >>> the cpu of switch busy, etc. >>> >>> In my opinion, observing the Control Protocol, e.g. DHCP >>> or ND etc, is easy to implement in switch for these protocol >>> have special characteristic that can be filtered in switch port while >>> the forwarding packet is blocked. >>> >>> >> >> >> >> >> > > > > > From marcelo@it.uc3m.es Tue Dec 30 07:26:05 2008 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 CCF6728C0E9 for ; Tue, 30 Dec 2008 07:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.065 X-Spam-Level: *** X-Spam-Status: No, score=3.065 tagged_above=-999 required=5 tests=[AWL=-0.807, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 pB-FBfgLNBHV for ; Tue, 30 Dec 2008 07:26:04 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id CF2EA3A6A61 for ; Tue, 30 Dec 2008 07:26:03 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [200.40.4.133])by smtp01.uc3m.es (Postfix) with ESMTP id 8D7CBB4772D;Tue, 30 Dec 2008 16:25:42 +0100 (CET) Message-ID: <495A300F.3090401@it.uc3m.es> Date: Tue, 30 Dec 2008 15:28:31 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Guang Yao References: <005901c96128$ea3185f0$420c7c0a@china.huawei.com> <494AA050.2060300@it.uc3m.es> <7141029F-A8F2-4892-977A-BFF510A405B7@ericsson.com> <002601c9641a$a6446fc0$2211990a@h3c.huawei3com.com> <60D2E2DD-9815-4374-9A48-EC646396198E@ericsson.com> <008901c964f7$ca10ad00$5e320700$@tsinghua.edu.cn> <4957CF87.9050601@it.uc3m.es> <001001c96973$3b508ce0$b1f1a6a0$@tsinghua.edu.cn> <49590EF6.4080407@it.uc3m.es> <001201c96a4f$8dc3cd70$a94b6850$@tsinghua.edu.cn> In-Reply-To: <001201c96a4f$8dc3cd70$a94b6850$@tsinghua.edu.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-22.4047 TC:1F TRN:92 TV:5.5.1026(16370.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: 'Lin Tao' , 'SAVI Mailing List' , 'Christian Vogt' , 'Frank Xia' Subject: Re: [savi] =?gb2312?b?tPC4tDogtPC4tDogtPC4tDogIFdvcmtpbmcgR3JvdXAg?= =?gb2312?b?QWRvcHRpb24gb2YgSW5kaXZpZHVhbCBTQVZJIERvY3VtZW50cw==?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2008 15:26:05 -0000 [Meta comment: Guang, please indent or mark somehow your text in order to distinguish from my previous comments, cause it is becoming increasingly hard to follow this thread) below... Guang Yao escribi¨®: > > I think we are having two somehow orthogonal issues here: > - On one hand we are discussing what is the type of address ownership > proof that we want to have. I think that irrespectively whether you use > control messages or data packets, you can use the FCFS principle as > address ownership. I mean, in both cases, the first node that sends a > packet with a given address claims the address ownership. The first > packet can be a data packet or a NS or NADV packet, but it is FCFS > principle all the way. I don't thing you are propising a different > address ownership proof afaict > > For the SAVI device, it is correct that address ownership can be assigned > according > to the principle of FCFS, no matter data traffic or control traffic is > chosen. It is not the fault > of the principle of FCFS. But it is correct from the view of the SAVI > device. > > Please consider the hosts in the same network. For currently we cannot > modify the > host, they have none sense of the existing of a SAVI device. They are > working assuming > all the nodes are working according to the standard and > the switch or router would never drop its traffic if it obeys the rules, > unless congestion. > > mmm, what about ingress filtering? If a node has multiple addresses with different prefixes, packets can get dropped cause ingress filtering (this is fairly common case in multihomed scenarios for instance) The point that i am trying to make is that if we intend to create a SAVI mechanism that is transparent to the edn nodes, we will need to make some assumptions and these assumptions are likely to not hold for every possible scenario, and when they don't hold, some things are likely to fail. Of course we must minimize the situations where that happens, i agree > However, we put a superpower manager into the network without notifying the > hosts. > And the manager designed two new rules: > 1a, if you use an address in the data traffic firstly, you get > the ownership; > 2a, if you use an address given to another, your packet will be dropped. > Unfortunately, these rules are not known by any host. The host runs > according to these two rules: > 1b, If a tentative address is not replied by another, I can use it; > 2b, My packet will be delivered if I use my address. > Well, DAD is not guaranteed to work in all the cases, so it may be possible that there is a collision even with DAD being successful. In that case, you enter in very strange failure modes. So, you can use that address indeed but there is no guarantees it will your own and your own only > The first rules of SAVI device and host are very different. > 1 the owner of a tentative traffic what do you mean by the owner of tentative traffic? > is not enforced to reply a DAD NA. So 1a > is not the sufficient condition of 1b. > 2 any host can reply the DAD NS. So 1a is not the necessary condition of 1b. > And there may be more examples to prove that 1a is not a necessary and > sufficient condition of 1b. > So 1a and 1b are separate conditions. > If we want to use 1a, we must assure that all hosts run according to 1a. Or > else, something goes bad. > But actually, all normal hosts run according to 1b. > > In short, FCFS is OK, but it will be bad if the FCFS principle is not known > clearly by host. If we don't want to modify > host, we must make the SAVI device transparent and import no new rule. > > I am not sure what is the problem here. We can use the FCFS principle both with data traffic and control packets as i suggested in the previous email The SAVI device can create state both based on the ND traffic and the data traffic, there is no problem with that. I guess it is up to the WG to decide if we think that the additional complexity required for the SAVI device to also understand ND messages is worth it. I am not sure we are disagreeing here... > - On the other hand, there is the disucssion if we do this based on data > packets or using control packets, in particular NSol and NAdv). I don't > have a problem in doing it in both. I don't think you can do it only > with control packets. In particular, consider the case of optimistic > DAD. In that case, the node starts using the address even wihtout having > the DAD completed. Moreover, DAD is a one time operation that is > succesfull when there is no reply. So if we have a transite failure > duringt he DAD period, and packets are not delivered to the SAVI device > during that time, SAVI would fail. I do agree that it would be > interesting to evaluate if looking into ND messages could help to > prevent some scenarion as the one you mention above. But i think that a > solution that solely relies in ND messages would be not very robust > (i.e. it would fail if the DAD packet is lost for instance) > > Optimistic DAD would not trouble for a DAD NS has been sent and the SAVI > device > knows exactly whether there is a collision. If there is a collision, the > source address > without finishing DAD will be dropped. There is no problem. And if no > collision, there > is no problem to forward these packets. > > > I agree that SAVI will fail if the DAD NA message is not delivered to the > tentative node. > So I think maybe the SAVI device should guarantee the procedure will not be > disrupted, > e.g., it can play as a ND proxy. but how do you guarantee that the ND message was delviered to the SAVI device in the first place? (And how do you guarantee that the ND message is delviered to all the nodes?) I mean, the problem with DAD robustness is that the topology can change after the DAD procedure was done. So, suppose you have two lans that are working and that at some point in time they are merged into one lan. In that case, the nodes on each lan have already executed the DAD procedure and they are not even aware of the merging, so they will not repeat the DAD procedure. (this can happne when there is a failure and a network gets partitioned and then repaired for example) So DAD is inherently non robust cause the procedure is successful when there is NO reply, but you cannot know if there is no reply cause there is no address collision or because the packet was lost. > But I think relying on data traffic has the > same problem, right? > > not really, cause there are many data packets. So, if one data packet gets lost, there will be more to come, so sooner or later one of them will make it (or we have bigger problems) The problem with DAD is that we send only one packet and if it is lost we are out of luck. BEsides, we could send several packets, but this would imply longer delay, whcih is also bad. Data pakcet otoh, there are plenty of them, so the problem is handled better >> And I mentioned SAVI must control the NA messages, for the Target Address >> > in > >> the NA message is another kind of source address. If the SAVI device has >> > set > >> up >> a binding table, it can filter spoofed NA with ease. >> >> It may be argued that in any situation, a node can avoid replying to NS >> message even the >> Target Address has been assigned to it, and the tentative node will be >> assigned duplicated and "spoofing" address. >> But still it is very different because the probability for two node to >> generate same address is little and the possible damage >> Is trivial. >> But if an attacker designedly attacks against the tentative address, the >> consequence is very bad. Unfortunately, FCFS >> using data traffic makes this situation possible. >> >> IMO, binding address using data traffic is wrong because data traffic is >> > not > >> defined to have the >> function of assigning address to node. It is the necessary condition but >> > not > >> sufficient condition. >> >> >> >> > but the problem is that there is no sufficient condition for knowing > that a node has configured an address. I mean, DAD messages can be lost > and they are only sent once in a nion reliable fashion. In addition, > nodes do optimistic DAD and start using the address without waiting for > the DAD to be completed. > > So, if you want to design a robust mechanism you need to deal with all > that, and using data packets seem the ultimate line > > Yes, I want to design a robust mechanism. But I don¡¯t think we have to use > data traffic. > I think the mechanism can be like this: > 1 It must ensure the security and completeness of DAD. > how do you think you can do that? As i said, imho DAD is inherently non robust > 1.1 Address can be bound only after a DAD NS and there is no > collision in local binding table. > as i said several times, i thin it may be ok to use ND messages to populate the SAVI DB, but i don't think we should rely solely on ND. I think we need to use data packets as well, in case DAD packets are missing for soem reason BTW, i also think we should use dhcp messages if we can I think we need to understnad what do we gain by adding this complexity (clearly relying solely on dat packets is simpler, but relying on signaling packets as well may prevent som attacks, but we need to understadn that better imho) > 1.2 If there is a collision in local binding, and a DAD NA is > replied from the address owner, it must > ensure the NA will be delivered to the tentative node. > sure, this is basic DAD behaviour, nothing new here, right? > 1.3 If the address owner doesn't reply, it may either: 1, delete > former binding and set up new binding; > or 2 Send a NA to the tentative node instead of the address > owner. > sure, this is done already in the FCFS draft, > 1.4 Any NA with spoofed Target Address must be dropped. > 2 Data traffic is either dropped or forwarded according to binding, without > triggering new binding entry. > > here, i disagree as i said, i think we should also use data traffic as well > I think the security and completeness of DAD is necessary even using data > traffic to bind address. > how do you plan to achieve that? regards, marcelo > If this condition is not guaranteed, there will be varies of attacks and > collisions. > > (In order to deal with the attack you mention, the SAVI device can sniff > DAD packets and identify the suggested attacks if it first sees a DAD > packet and then a data packet with the same address and no DAD reply to > the original request... of course this makes the logic more comlex) > > Regards, marcelo > > > >>> Although it is rather a security problem of ND then the fault of SAVI, >>> > the > >>> SAVI device is >>> protecting bad doings in the example. >>> >>> I think SAVI should at least protect normal behaviors and good guys, but >>> >>> >> not >> >> >>> protect bad behaviors. >>> >>> I also think SAVI should protect the Target Address in NA message, for it >>> >>> >> is >> >> >>> another kind of source address. >>> >>> Guang >>> -----ÓʼþÔ­¼þ----- >>> ·¢¼þÈË: Christian Vogt [mailto:christian.vogt@ericsson.com] >>> ·¢ËÍʱ¼ä: 2008Äê12ÔÂ23ÈÕ 18:36 >>> ÊÕ¼þÈË: Lin Tao >>> ³­ËÍ: Frank Xia; Marcelo Bagnulo Braun; SAVI Mailing List; Ò¦ ¹ã >>> Ö÷Ìâ: Re: [savi] Working Group Adoption of Individual SAVI Documents >>> >>> Lin - >>> >>> I agree with you that DoS is an unsolved issue that we have yet to >>> tackle. However, I don't think we can solve the issue, for all address >>> configuration methods, simply by changing which packets we snoop. SLAAC >>> in particular is an address configuration method where an attacker can >>> overload a SAVI device just as easily with control packets (i.e., >>> Neighbor Solicitation packets) as with datagram packets. >>> >>> The only scenario in which snooping control packets instead of datagram >>> packets could mitigate the DoS issue is where addresses are exclusively >>> assigned via DHCP. A SAVI device can then exclusively rely on messages >>> being sent by a server (not directly by the attacker), such that a DoS >>> attack against a SAVI device reduces to the existing threat of a DoS >>> attack against a DHCP server. >>> >>> FWIW: Some SAVI participants were considering a DHCP-only option for >>> SAVI during IETF 73. >>> >>> - Christian >>> >>> >>> >>> On Dec 22, 2008, Lin Tao wrote: >>> >>> >>> >>> >>>> Hello, Christian, Marcelo and Frank: >>>> >>>> I agree with Frank's view. Because the forwarding packet is >>>> observed in FCFS draft, so the forwarding process is disrupted, >>>> and the device is vulnerable, e.g. savi cache table exhausted, >>>> the cpu of switch busy, etc. >>>> >>>> In my opinion, observing the Control Protocol, e.g. DHCP >>>> or ND etc, is easy to implement in switch for these protocol >>>> have special characteristic that can be filtered in switch port while >>>> the forwarding packet is blocked. >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> > > > > > From lint@h3c.com Wed Dec 31 01:55:57 2008 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 89F283A6946 for ; Wed, 31 Dec 2008 01:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 5.133 X-Spam-Level: ***** X-Spam-Status: Yes, score=5.133 tagged_above=-999 required=5 tests=[AWL=-1.135, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, RELAY_IS_221=2.222] X-Spam-Report: * 2.2 RELAY_IS_221 RELAY_IS_221 * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 0.3 CN_BODY_35 BODY: Body contains "\323\312\274\376" * -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] * 1.8 MIME_BASE64_TEXT RAW: Message text disguised using base64 encoding * 2.5 MIME_CHARSET_FARAWAY MIME character set indicates foreign language * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 0.6 HELO_MISMATCH_COM HELO_MISMATCH_COM * -1.1 AWL AWL: From: address is in the auto white-list 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 HF+lZge7JC1n for ; Wed, 31 Dec 2008 01:55:56 -0800 (PST) Received: from huawei-3com.com (unknown [221.12.31.56]) by core3.amsl.com (Postfix) with ESMTP id 4082D3A6941 for ; Wed, 31 Dec 2008 01:55:55 -0800 (PST) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KCQ00DR6JKVDN@h3cml01-in.huawei-3com.com> for savi@ietf.org; Wed, 31 Dec 2008 17:55:43 +0800 (CST) Received: from mailsecurity.h3c.com ([172.25.12.124]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KCQ004BPJKVXH@h3cml01-in.huawei-3com.com> for savi@ietf.org; Wed, 31 Dec 2008 17:55:43 +0800 (CST) Received: from unknown (HELO l00450a) ([10.153.17.74]) by mailsecurity.h3c.com with ESMTP; Wed, 31 Dec 2008 18:03:03 +0800 Date: Wed, 31 Dec 2008 17:55:41 +0800 From: Lin Tao To: marcelo bagnulo braun Message-id: <009b01c96b2d$f1713b80$4a11990a@h3c.huawei3com.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <"005901c96128 $ea3185f0$420c7c0a"@china.huawei.com> <494AA050.2060300@it.uc3m.es> <"7141029F - A8F2-4892-977A-BFF510A405B7"@ericsson.com> <60D2E2DD-9815-4374-9A48-EC646396198E@ericsson.com> <"008 901c964f7$ca10ad00$5e320700$"@tsinghua.edu.cn> <013001c965ae$ce9efa90$8311990a@h3c.huawei3com.com> <4957D0DB.8050304@it.uc3m.es> Cc: Guang Yao , 'SAVI Mailing List' , 'Christian Vogt' , 'Frank Xia' Subject: [savi] ***SPAM*** 5.133 (5) Re: Working Group Adoption of Individual SAVI Documents X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2008 09:55:57 -0000 U29ycnkgc28gbGF0ZS4gSSB0aGluayBHdWFuZyBoYXZlIGV4cGxhaW5lZCB0aGUgbWVhbmluZy4N CkkgYWdyZWUgaGlzIGlkZWEsIHRoZSBjb250cm9sIHByb3RvY29sIG11c3QgYmUgc25vb3BpbmcN Cm9yIHByb3h5IHRvIHByb3RlY3QgdGhlIG5ldHdvcmsgc2VjdXJpdHkuIEFuZCB3ZSBjYW4gDQps YXlvdXQgZGlmZmVyZW50IHNlY3VyZSBsZXZlbCBpbiB0aGlzIHdheS4gVGhlcmUgaXMgdGhlDQpz YW1lIGFwcHJvYWNoIGluIElQdjQuDQoNCg0KSGFwcHkgbmV3IHllYXIhDQoNCg0KLS0tLS0gT3Jp Z2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJtYXJjZWxvIGJhZ251bG8gYnJhdW4iIDxtYXJj ZWxvQGl0LnVjM20uZXM+DQpUbzogIkxpbiBUYW8iIDxsaW50QGgzYy5jb20+DQpDYzogIkd1YW5n IFlhbyIgPHlhb2dAbmV0YXJjaGxhYi50c2luZ2h1YS5lZHUuY24+OyAiJ0NocmlzdGlhbiBWb2d0 JyIgPGNocmlzdGlhbi52b2d0QGVyaWNzc29uLmNvbT47ICInRnJhbmsgWGlhJyIgPHhpYXlhbmdz b25nQGh1YXdlaS5jb20+OyAiJ1NBVkkgTWFpbGluZyBMaXN0JyIgPHNhdmlAaWV0Zi5vcmc+DQpT ZW50OiBNb25kYXksIERlY2VtYmVyIDI5LCAyMDA4IDM6MTcgQU0NClN1YmplY3Q6IFJlOiBbc2F2 aV0gV29ya2luZyBHcm91cCBBZG9wdGlvbiBvZiBJbmRpdmlkdWFsIFNBVkkgRG9jdW1lbnRzDQoN Cg0KPiBMaW4gVGFvIGVzY3JpYmmorjoNCj4+IERlYXIgQ2hyaXN0aWFuLCBHdWFuZyBhbmQgTWFy Y2VsbywNCj4+DQo+PiAgICAgSSBhZ3JlZSB3aXRoIEd1YW5nIHRoYXQgdGhlIG5vcm1hbCBiZWhh dmlvcnMgYW5kIGdvb2QgZ3V5cw0KPj4gTVVTVCBiZSBwcm90ZWN0ZWQsIHNvIHdlIHNob3VsZCBz bm9vcCBhdCBjb250cm9sIHBhY2tldHMgdGhhbiANCj4+IGRhdGFncmFtIHBhY2tldHMuIA0KPiBJ IGZhaWwgdG8gc2VlIHdoeSB0aGlzIGlzIHNvDQo+IGNvdWxkIHlvdSBleHBhbmQ/DQo+IA0KPiBy ZWdhcmRzLCBtYXJjZWxvDQo+IA0KPiANCj4gDQo+PiBUaGlzIGlzIHRoZSB3b3J0aGVzdCB0aGlu ZyBpbiBTQVZJLiANCj4+ICAgICBUaGVyZSBpcyB0d28gcGxhbmUgaW4gU1dJVENIOiBBU0lDIGFu ZCBDUFUsIGl0IA0KPj4gaXMgZWFzeSB0byBpbXBsZW1lbnQgQUNMIGluIEFTSUMgdG8gZmlsdGVy IGNvbnRyb2wgcGFja2V0cyB0bw0KPj4gQ1BVLCBhbmQgdGhlIGRhdGFncmFtIHBhY2tldHMgaXMg ZGlzY2FyZGVkIGJ5IGRlZmF1bHQuIE90aGVyd2lzZSwNCj4+IGFsbCBkYXRhZ3JhbSBwYWNrZXRz IHRoYXQgaGF2bid0IHJpZ2h0IHRvIGZvcndhcmQgYXJlIGFsbCANCj4+IGRlbGl2ZXJlZCB0byBD UFUsIHRoYW4gaXQgd2lsbCBiZSBmb3J3YXJkZWQgYnkgQ1BVLCB0aGlzIGlzIA0KPj4gYSBiYWRl ciBncmFudWxhcml0eSB0aGFuIHNub29waW5nIGNvbnRyb2wgcGFja2V0cy4NCj4+ICAgIA0KPj4g QmVzdCByZWdhcmRzDQo+Pg0KPj4NCj4+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQo+ PiBGcm9tOiAiR3VhbmcgWWFvIiA8eWFvZ0BuZXRhcmNobGFiLnRzaW5naHVhLmVkdS5jbj4NCj4+ IFRvOiAiJ0NocmlzdGlhbiBWb2d0JyIgPGNocmlzdGlhbi52b2d0QGVyaWNzc29uLmNvbT47ICIn TGluIFRhbyciIDxsaW50QGgzYy5jb20+DQo+PiBDYzogIidGcmFuayBYaWEnIiA8eGlheWFuZ3Nv bmdAaHVhd2VpLmNvbT47ICInTWFyY2VsbyBCYWdudWxvIEJyYXVuJyIgPG1hcmNlbG9AaXQudWMz bS5lcz47ICInU0FWSSBNYWlsaW5nIExpc3QnIiA8c2F2aUBpZXRmLm9yZz4NCj4+IFNlbnQ6IFR1 ZXNkYXksIERlY2VtYmVyIDIzLCAyMDA4IDg6MTIgUE0NCj4+IFN1YmplY3Q6ILTwuLQ6IFtzYXZp XSBXb3JraW5nIEdyb3VwIEFkb3B0aW9uIG9mIEluZGl2aWR1YWwgU0FWSSBEb2N1bWVudHMNCj4+ DQo+Pg0KPj4gRGVhciBDaHJpc3RpYW4gYW5kIExpbiwNCj4+DQo+PiBJdCdzIGNsZWFyIHRoYXQg c25vb3BpbmcgTkQgY2Fubm90IGFjaGlldmUgYmV0dGVyIHBlcmZvcm1hbmNlIGFuZCBzZWN1cml0 eSANCj4+IHRoYW4gc25vb3BpbmcgZGF0YSB0cmFmZmljLiBBY3R1YWxseSBzbm9vcGluZyBORCBt YXkgY29zdCBtb3JlIGZvciBpdCBtdXN0DQo+PiB0cmFjZSANCj4+IHRoZSBzdGF0ZSBvZiBEQUQu DQo+Pg0KPj4gQnV0IElNTywgaXQgaXMgbm90IGFuIGlzc3VlIG9mIHJlc291cmNlIHNhdmluZywg YnV0IGFuIGlzc3VlIHRoYXQgd2hhdCBTQVZJDQo+PiBpcyBpbnRlbmRpbmcNCj4+IHRvIHByb3Rl Y3QuIElmIHRoZSBTQVZJIGRldmljZSBzbm9vcHMgTkQgdG8gYmluZCBhZGRyZXNzIGFuZCBhbmNo b3IsIGl0DQo+PiBwcm90ZWN0cw0KPj4gZ29vZCBndXlzIHdobyBhcmUgd29ya2luZyBhY2NvcmRp bmcgdG8gdGhlIHN0YW5kYXJkLiBCdXQgaWYgaXQgc25vb3BzIGRhdGENCj4+IHRyYWZmaWMgYW5k DQo+PiBiaW5kcyBhZGRyZXNzIGFuZCBhbmNob3IgdXNpbmcgdGhlIHByaW5jaXBsZSBvZiBGQ0ZT LCBiYWQgYmVoYXZpb3JzLCBzdWNoIGFzDQo+PiBhdHRhY2tzIGFnYWluc3QNCj4+IERBRCwgYXJl IHByb3RlY3RlZC4gDQo+Pg0KPj4gTXIuIEZyZWQgQmFrZXIgb25jZSBnYXZlIHVzIGEgY29udmlu Y2luZyBleGFtcGxlOiB3aGVuIGFuIGF0dGFja2VyIHJlY2VpdmVzDQo+PiBhDQo+PiBEQUQgTlMs IGl0IGltbWVkaWF0ZWx5IHNlbmRzIGEgcGFja2V0IHdpdGggc291cmNlIGFkZHJlc3Mgc2V0IHRv IHRoZSBUYXJnZXQNCj4+IEFkZHJlc3MgaW4gdGhlIE5TDQo+PiB0byBtYWtlIHRoZSBTQVZJIGRl dmljZSBzZXQgdXAgYmluZGluZyB3aXRob3V0IHJlcGx5aW5nIGEgTkEuIFRoZW4gdGhlIERBRA0K Pj4gbm9kZSwgYWx0aG91Z2ggaGFzIGZpbmlzaGVkDQo+PiBhIHN1Y2Nlc3NmdWwgREFELCBjYW5u b3QgdXNlIHRoZSB0ZW50YXRpdmUgYWRkcmVzcyBmb3IgdGhlIFNBVkkgZGV2aWNlIHdpbGwNCj4+ IHRha2UgaXRzIHRyYWZmaWMgYXMgc3Bvb2ZpbmcgdHJhZmZpYy4NCj4+DQo+PiBBbHRob3VnaCBp dCBpcyByYXRoZXIgYSBzZWN1cml0eSBwcm9ibGVtIG9mIE5EIHRoZW4gdGhlIGZhdWx0IG9mIFNB VkksIHRoZQ0KPj4gU0FWSSBkZXZpY2UgaXMNCj4+IHByb3RlY3RpbmcgYmFkIGRvaW5ncyBpbiB0 aGUgZXhhbXBsZS4NCj4+DQo+PiBJIHRoaW5rIFNBVkkgc2hvdWxkIGF0IGxlYXN0IHByb3RlY3Qg bm9ybWFsIGJlaGF2aW9ycyBhbmQgZ29vZCBndXlzLCBidXQgbm90DQo+PiBwcm90ZWN0IGJhZCBi ZWhhdmlvcnMuDQo+Pg0KPj4gSSBhbHNvIHRoaW5rIFNBVkkgc2hvdWxkIHByb3RlY3QgdGhlIFRh cmdldCBBZGRyZXNzIGluIE5BIG1lc3NhZ2UsIGZvciBpdCBpcw0KPj4gYW5vdGhlciBraW5kIG9m IHNvdXJjZSBhZGRyZXNzLiANCj4+DQo+PiBHdWFuZw0KPj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ PiC3orz+yMs6IENocmlzdGlhbiBWb2d0IFttYWlsdG86Y2hyaXN0aWFuLnZvZ3RAZXJpY3Nzb24u Y29tXSANCj4+ILeiy83KsbzkOiAyMDA4xOoxMtTCMjPI1SAxODozNg0KPj4gytW8/sjLOiBMaW4g VGFvDQo+PiCzrcvNOiBGcmFuayBYaWE7IE1hcmNlbG8gQmFnbnVsbyBCcmF1bjsgU0FWSSBNYWls aW5nIExpc3Q7INKmILnjDQo+PiDW98ziOiBSZTogW3NhdmldIFdvcmtpbmcgR3JvdXAgQWRvcHRp b24gb2YgSW5kaXZpZHVhbCBTQVZJIERvY3VtZW50cw0KPj4NCj4+IExpbiAtDQo+Pg0KPj4gSSBh Z3JlZSB3aXRoIHlvdSB0aGF0IERvUyBpcyBhbiB1bnNvbHZlZCBpc3N1ZSB0aGF0IHdlIGhhdmUg eWV0IHRvDQo+PiB0YWNrbGUuIEhvd2V2ZXIsIEkgZG9uJ3QgdGhpbmsgd2UgY2FuIHNvbHZlIHRo ZSBpc3N1ZSwgZm9yIGFsbCBhZGRyZXNzDQo+PiBjb25maWd1cmF0aW9uIG1ldGhvZHMsIHNpbXBs eSBieSBjaGFuZ2luZyB3aGljaCBwYWNrZXRzIHdlIHNub29wLiAgU0xBQUMNCj4+IGluIHBhcnRp Y3VsYXIgaXMgYW4gYWRkcmVzcyBjb25maWd1cmF0aW9uIG1ldGhvZCB3aGVyZSBhbiBhdHRhY2tl ciBjYW4NCj4+IG92ZXJsb2FkIGEgU0FWSSBkZXZpY2UganVzdCBhcyBlYXNpbHkgd2l0aCBjb250 cm9sIHBhY2tldHMgKGkuZS4sDQo+PiBOZWlnaGJvciBTb2xpY2l0YXRpb24gcGFja2V0cykgYXMg d2l0aCBkYXRhZ3JhbSBwYWNrZXRzLg0KPj4NCj4+IFRoZSBvbmx5IHNjZW5hcmlvIGluIHdoaWNo IHNub29waW5nIGNvbnRyb2wgcGFja2V0cyBpbnN0ZWFkIG9mIGRhdGFncmFtDQo+PiBwYWNrZXRz IGNvdWxkIG1pdGlnYXRlIHRoZSBEb1MgaXNzdWUgaXMgd2hlcmUgYWRkcmVzc2VzIGFyZSBleGNs dXNpdmVseQ0KPj4gYXNzaWduZWQgdmlhIERIQ1AuICBBIFNBVkkgZGV2aWNlIGNhbiB0aGVuIGV4 Y2x1c2l2ZWx5IHJlbHkgb24gbWVzc2FnZXMNCj4+IGJlaW5nIHNlbnQgYnkgYSBzZXJ2ZXIgKG5v dCBkaXJlY3RseSBieSB0aGUgYXR0YWNrZXIpLCBzdWNoIHRoYXQgYSBEb1MNCj4+IGF0dGFjayBh Z2FpbnN0IGEgU0FWSSBkZXZpY2UgcmVkdWNlcyB0byB0aGUgZXhpc3RpbmcgdGhyZWF0IG9mIGEg RG9TDQo+PiBhdHRhY2sgYWdhaW5zdCBhIERIQ1Agc2VydmVyLg0KPj4NCj4+IEZXSVc6ICBTb21l IFNBVkkgcGFydGljaXBhbnRzIHdlcmUgY29uc2lkZXJpbmcgYSBESENQLW9ubHkgb3B0aW9uIGZv cg0KPj4gU0FWSSBkdXJpbmcgSUVURiA3My4NCj4+DQo+PiAtIENocmlzdGlhbg0KPj4NCj4+DQo+ Pg0KPj4gT24gRGVjIDIyLCAyMDA4LCBMaW4gVGFvIHdyb3RlOg0KPj4NCj4+ICAgDQo+Pj4gSGVs bG8sIENocmlzdGlhbiwgTWFyY2VsbyBhbmQgRnJhbms6DQo+Pj4NCj4+PiBJIGFncmVlIHdpdGgg RnJhbmsncyB2aWV3LiBCZWNhdXNlIHRoZSBmb3J3YXJkaW5nIHBhY2tldCBpcw0KPj4+IG9ic2Vy dmVkIGluIEZDRlMgZHJhZnQsIHNvIHRoZSBmb3J3YXJkaW5nIHByb2Nlc3MgaXMgZGlzcnVwdGVk LA0KPj4+IGFuZCB0aGUgZGV2aWNlIGlzIHZ1bG5lcmFibGUsIGUuZy4gc2F2aSBjYWNoZSB0YWJs ZSBleGhhdXN0ZWQsDQo+Pj4gdGhlIGNwdSBvZiBzd2l0Y2ggYnVzeSwgZXRjLg0KPj4+DQo+Pj4g SW4gbXkgb3Bpbmlvbiwgb2JzZXJ2aW5nIHRoZSBDb250cm9sIFByb3RvY29sLCBlLmcuIERIQ1AN Cj4+PiBvciBORCBldGMsIGlzIGVhc3kgdG8gaW1wbGVtZW50IGluIHN3aXRjaCBmb3IgdGhlc2Ug cHJvdG9jb2wNCj4+PiBoYXZlIHNwZWNpYWwgY2hhcmFjdGVyaXN0aWMgdGhhdCBjYW4gYmUgZmls dGVyZWQgaW4gc3dpdGNoIHBvcnQgd2hpbGUNCj4+PiB0aGUgZm9yd2FyZGluZyBwYWNrZXQgaXMg YmxvY2tlZC4NCj4+PiAgICAgDQo+Pg0KPj4NCj4+DQo+PiAgIA0KPiANCj4= From marcelo@it.uc3m.es Wed Dec 31 05:01:00 2008 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 184173A67B2 for ; Wed, 31 Dec 2008 05:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.045 X-Spam-Level: X-Spam-Status: No, score=-4.045 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 CKK0iC-A1CBe for ; Wed, 31 Dec 2008 05:00:59 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id B42F83A67AD for ; Wed, 31 Dec 2008 05:00:57 -0800 (PST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131])by smtp01.uc3m.es (Postfix) with ESMTP id A5496B47512;Wed, 31 Dec 2008 14:00:42 +0100 (CET) Received: from r190-132-87-57.dialup.mobile.ancel.net.uy(r190-132-87-57.dialup.mobile.ance l.net.uy [190.132.87.57]) bywebcartero01.uc3m.es (Horde MIME library) with HTTP; Wed, 31 Dec 200814:00:40 +0100 Message-ID: <20081231140040.zf4f79t39oossk8o@webcartero01.uc3m.es> Date: Wed, 31 Dec 2008 14:00:40 +0100 From: MARCELO BAGNULO BRAUN To: Lin Tao References: <"005901c9612 8$ea3185f0$420c7c0a"@china.huawei.com><494AA050.2060300@it.uc3m.es><"71410 29F -A8F2-4892-977A-BFF510A405B7"@ericsson.com><60D2E2DD-9815-4374-9A48-EC64639 6198E@ericsson.com><"008901c964f7$ca10ad00$5e320700$"@tsinghua.edu.cn><0130 01c965ae$ce9efa90$8311990a@h3c.huawei3com.com><4957D0DB.8050304@it.uc3m.es> <009b01c96b2d$f1713b80$4a11990a@h3c.huawei3com.com> In-Reply-To: <009b01c96b2d$f1713b80$4a11990a@h3c.huawei3com.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-37.2532 TC:1F TRN:71 TV:5.5.1026(16372.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Guang Yao , 'SAVIMailing List' , 'Christian Vogt' , 'Frank Xia' Subject: Re: [savi] Working Group Adoption of Individual SAVI Documents X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2008 13:01:00 -0000 Lin, Lin Tao dijo: > Sorry so late. I think Guang have explained the meaning. > I agree his idea, the control protocol must be snooping How do you suggest to deal with the case the NADV message is lost and the SAVI device does not receives it? > or proxy to protect the network security. as i mentioned already, this is included already in the fcfs draft > And we can > layout different secure level in this way. What do you mena by this? > There is the > same approach in IPv4. how are you planning to do this? IS DAD mandatory in IPv4? Regards, marcelo > > > Happy new year! > > > ----- Original Message ----- > From: "marcelo bagnulo braun" > To: "Lin Tao" > Cc: "Guang Yao" ; "'Christian Vogt'" > ; "'Frank Xia'" > ; "'SAVI Mailing List'" > Sent: Monday, December 29, 2008 3:17 AM > Subject: Re: [savi] Working Group Adoption of Individual SAVI Documents > > >> Lin Tao escribi=F3: >>> Dear Christian, Guang and Marcelo, >>> >>> I agree with Guang that the normal behaviors and good guys >>> MUST be protected, so we should snoop at control packets than >>> datagram packets. >> I fail to see why this is so >> could you expand? >> >> regards, marcelo >> >> >> >>> This is the worthest thing in SAVI. >>> There is two plane in SWITCH: ASIC and CPU, it >>> is easy to implement ACL in ASIC to filter control packets to >>> CPU, and the datagram packets is discarded by default. Otherwise, >>> all datagram packets that havn't right to forward are all >>> delivered to CPU, than it will be forwarded by CPU, this is >>> a bader granularity than snooping control packets. >>> >>> Best regards >>> >>> >>> ----- Original Message ----- >>> From: "Guang Yao" >>> To: "'Christian Vogt'" ; "'Lin Tao'" >>> >>> Cc: "'Frank Xia'" ; "'Marcelo Bagnulo >>> Braun'" ; "'SAVI Mailing List'" >>> Sent: Tuesday, December 23, 2008 8:12 PM >>> Subject: ??: [savi] Working Group Adoption of Individual SAVI Documents >>> >>> >>> Dear Christian and Lin, >>> >>> It's clear that snooping ND cannot achieve better performance and secur= ity >>> than snooping data traffic. Actually snooping ND may cost more for it m= ust >>> trace >>> the state of DAD. >>> >>> But IMO, it is not an issue of resource saving, but an issue that what = SAVI >>> is intending >>> to protect. If the SAVI device snoops ND to bind address and anchor, it >>> protects >>> good guys who are working according to the standard. But if it snoops d= ata >>> traffic and >>> binds address and anchor using the principle of FCFS, bad >>> behaviors, such as >>> attacks against >>> DAD, are protected. >>> >>> Mr. Fred Baker once gave us a convincing example: when an attacker rece= ives >>> a >>> DAD NS, it immediately sends a packet with source address set to the Ta= rget >>> Address in the NS >>> to make the SAVI device set up binding without replying a NA. Then the = DAD >>> node, although has finished >>> a successful DAD, cannot use the tentative address for the SAVI device = will >>> take its traffic as spoofing traffic. >>> >>> Although it is rather a security problem of ND then the fault of SAVI, = the >>> SAVI device is >>> protecting bad doings in the example. >>> >>> I think SAVI should at least protect normal behaviors and good >>> guys, but not >>> protect bad behaviors. >>> >>> I also think SAVI should protect the Target Address in NA message, >>> for it is >>> another kind of source address. >>> >>> Guang >>> -----????----- >>> ???: Christian Vogt [mailto:christian.vogt@ericsson.com] >>> ????: 2008?12?23? 18:36 >>> ???: Lin Tao >>> ??: Frank Xia; Marcelo Bagnulo Braun; SAVI Mailing List; ? ? >>> ??: Re: [savi] Working Group Adoption of Individual SAVI Documents >>> >>> Lin - >>> >>> I agree with you that DoS is an unsolved issue that we have yet to >>> tackle. However, I don't think we can solve the issue, for all address >>> configuration methods, simply by changing which packets we snoop. SLAA= C >>> in particular is an address configuration method where an attacker can >>> overload a SAVI device just as easily with control packets (i.e., >>> Neighbor Solicitation packets) as with datagram packets. >>> >>> The only scenario in which snooping control packets instead of datagram >>> packets could mitigate the DoS issue is where addresses are exclusively >>> assigned via DHCP. A SAVI device can then exclusively rely on messages >>> being sent by a server (not directly by the attacker), such that a DoS >>> attack against a SAVI device reduces to the existing threat of a DoS >>> attack against a DHCP server. >>> >>> FWIW: Some SAVI participants were considering a DHCP-only option for >>> SAVI during IETF 73. >>> >>> - Christian >>> >>> >>> >>> On Dec 22, 2008, Lin Tao wrote: >>> >>> >>>> Hello, Christian, Marcelo and Frank: >>>> >>>> I agree with Frank's view. Because the forwarding packet is >>>> observed in FCFS draft, so the forwarding process is disrupted, >>>> and the device is vulnerable, e.g. savi cache table exhausted, >>>> the cpu of switch busy, etc. >>>> >>>> In my opinion, observing the Control Protocol, e.g. DHCP >>>> or ND etc, is easy to implement in switch for these protocol >>>> have special characteristic that can be filtered in switch port while >>>> the forwarding packet is blocked. >>>> >>> >>> >>> >>> >> >> -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid From marcelo@it.uc3m.es Wed Dec 31 08:58:21 2008 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 A0F093A69EE for ; Wed, 31 Dec 2008 08:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 d3P7rGi-oQDG for ; Wed, 31 Dec 2008 08:58:20 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id C447C3A6990 for ; Wed, 31 Dec 2008 08:58:20 -0800 (PST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131])by smtp01.uc3m.es (Postfix) with ESMTP id 08F8AB47479;Wed, 31 Dec 2008 17:58:00 +0100 (CET) Received: from r190-132-68-97.dialup.mobile.ancel.net.uy(r190-132-68-97.dialup.mobile.ance l.net.uy [190.132.68.97]) bywebcartero01.uc3m.es (Horde MIME library) with HTTP; Wed, 31 Dec 200817:57:57 +0100 Message-ID: <20081231175757.54ekcygu4gsgcsgs@webcartero01.uc3m.es> Date: Wed, 31 Dec 2008 17:57:57 +0100 From: MARCELO BAGNULO BRAUN To: MARCELO BAGNULO BRAUN References: <"005901c9612 8$ea3185f0$420c7c0a"@china.huawei.com><494AA050.2060300@it.uc3m.es><"714102 9F-A8F2-4892-977A-BFF510A405B7"@ericsson.com><60D2E2DD-9815-4374-9A48-EC646 396198E@ericsson.com><"008901c964f7$ca10ad00$5e320700$"@tsinghua.edu.cn><01 3001c965ae$ce9efa90$8311990a@h3c.huawei3com.com><4957D0DB.8050304@it.uc3m.e s><009b01c96b2d$f1713b80$4a11990a@h3c.huawei3com.com><20081231140040.zf4f79t39oossk8o@webcartero01.uc3m.es> In-Reply-To: <20081231140040.zf4f79t39oossk8o@webcartero01.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-11.9305 TC:1F TRN:17 TV:5.5.1026(16374.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Lin Tao , Guang Yao , 'SAVIMailing List' , 'Christian Vogt' , 'Frank Xia' Subject: Re: [savi] Working Group Adoption of Individual SAVI Documents X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2008 16:58:21 -0000 MARCELO BAGNULO BRAUN dijo: >> There is the >> same approach in IPv4. > Follow up in this one Address conflict detection for IPv4 is defined in RFC5227, published in July 2008. I don't know how widely implemented is this, but i guess that as oposed to DAD which was defined from the start in ND, conflict detection for v4 has been defined much later on afaict and i would guess that it cannot be assumed to be universally implemented (or even widely implemented) Of course this is just my feeling, does anyone has actual data or experience about this? Regards, marcelo From lint@h3c.com Sun Jan 4 05:15:47 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 513063A6944 for ; Sun, 4 Jan 2009 05:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.418 X-Spam-Level: **** X-Spam-Status: No, score=4.418 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_72=0.6, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1, RELAY_IS_221=2.222] 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 X6peDwXMD1-P for ; Sun, 4 Jan 2009 05:15:46 -0800 (PST) Received: from huawei-3com.com (unknown [221.12.31.13]) by core3.amsl.com (Postfix) with ESMTP id DE5EC3A68D4 for ; Sun, 4 Jan 2009 05:15:44 -0800 (PST) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KCY00GYM7HVFI@h3cml02-in.huawei-3com.com> for savi@ietf.org; Sun, 04 Jan 2009 21:15:31 +0800 (CST) Received: from mailsecurity.h3c.com ([172.25.12.124]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KCY00GXV7HVLK@h3cml02-in.huawei-3com.com> for savi@ietf.org; Sun, 04 Jan 2009 21:15:31 +0800 (CST) Received: from unknown (HELO l00450a) ([10.153.17.0]) by mailsecurity.h3c.com with ESMTP; Sun, 04 Jan 2009 21:22:49 +0800 Date: Sun, 04 Jan 2009 21:15:29 +0800 From: Lin Tao To: MARCELO BAGNULO BRAUN Message-id: <003001c96e6e$846a32a0$0011990a@h3c.huawei3com.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <"005901c9612 8$ea3185f0$420c7c0a"@china.huawei.com> <494AA050.2060300@it.uc3m.es> <"71410 29F -A8F2-4892-977A-BFF510A405B7"@ericsson.com> <"60D2E2DD-9815-4374-9A48-EC64639 6198E"@ericsson.com> <008901c964f7$ca10ad00$5e320700$@tsinghua.edu.cn> <"0130 01c965ae$ce9efa90$8311990a"@h3c.huawei3com.com> <4957D0DB.8050304@it.uc3m.es> <009b01c96b2d$f1713b80$4a11990a@h3c.huawei3com.com> <20081231140040.zf4f79t39oossk8o@webcartero01.uc3m.es> Cc: Guang Yao , 'SAVIMailing List' , 'Christian Vogt' , 'Frank Xia' Subject: Re: [savi] Working Group Adoption of Individual SAVI Documents X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2009 13:15:47 -0000 MS4gQWJvdXQgTkFEViBtZXNzYWdlIGxvc3QuDQpUaGUgU0FWSSBkZXZpY2UgaXMgdGhlIGZpcnN0 IGFjY2VzcyBkZXZpY2UsIHNvIGlmIHRoaXMgbWVzc2FnZSBpcyBsb3N0LCANCndlIGNhbiAgY29u c2lkZXIgdGhlIGhvc3QgaXMgb2ZmbGluZS4NCg0KMi5TZWN1cmUgbGV2ZWwuDQpBbGwgdGhlIFNB VkkgZmVhdHVyZShORCBwcm94eSwgIGV0Yykgc2hvdWxkIGJlIG9wdGlvbmFsLCB3ZSBjYW4gDQpk ZWZpbmUgdGhlIGZlYXR1cmUgaW4gZGlmZmVyIGxldmVsLiBUaGUgd2Vha2VzdCBsZXZlbCBpcyBu byBTQVZJLCB0aGFuDQpkZWFsIHdpdGggZm9yd2FyZGluZyBwYXJja2V0LCB0aGFuIGNvbnRyb2xp bmcgcGFyY2tldCAodGhlcmUgYXJlDQptb3JlIGxldmVsIGluIGNvbnRyb2xpbmcgcGFyY2tldCwg TkQvQVJQLCBESENQLCBldGMpLg0KDQozLlNhbWUgYXBwcm9hY2ggaW4gSVB2NC4NClllcywgREFE IG1hbmRhdG9yeSBpbiBJUHY0IGlzIG9uZS4gV2UgaGF2ZSBtb3JlIGFwcHJvYWNoLCANCmZvciBl eGFtcGxlLCBBUlAgcHJveHksIEFSUCBzbm9vcGluZywgQVJQIGRldGVjdGlvbiBmb3Igc2FtZQ0K c291cmNlIE1BQywgZXRjLg0KDQo0LiBBYm91dCBSRkM1MjI3DQpUaGlzIFJGQyBtYXkgbm90IGJl IHVuaXZlcnNhbGx5IGltcGxlbWVudGVkLiBCdXQgU0FWSSBncm91cA0KZGljdXNzIHRoZSBkZXZp Y2UsIGFuZCB0aGUgZGV2aWNlIGNhbiBpbXBsZW1lbnQgaXQgZmlyc3QuIE90aGVyd2lzZSwNCndl IGNhbiBpbXByb3ZlIGl0IGZvciBkZXZpY2UgaW4gU0FWSSBzdGFuZGFyZCwgdGhlIHNhbWUgYXMg TkQuDQoNCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk1BUkNFTE8g QkFHTlVMTyBCUkFVTiIgPG1hcmNlbG9AaXQudWMzbS5lcz4NClRvOiAiTGluIFRhbyIgPGxpbnRA aDNjLmNvbT4NCkNjOiAiR3VhbmcgWWFvIiA8eWFvZ0BuZXRhcmNobGFiLnRzaW5naHVhLmVkdS5j bj47ICInU0FWSU1haWxpbmcgTGlzdCciIDxzYXZpQGlldGYub3JnPjsgIidDaHJpc3RpYW4gVm9n dCciIDxjaHJpc3RpYW4udm9ndEBlcmljc3Nvbi5jb20+OyAiJ0ZyYW5rIFhpYSciIDx4aWF5YW5n c29uZ0BodWF3ZWkuY29tPg0KU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAzMSwgMjAwOCA5OjAw IFBNDQpTdWJqZWN0OiBSZTogW3NhdmldIFdvcmtpbmcgR3JvdXAgQWRvcHRpb24gb2YgSW5kaXZp ZHVhbCBTQVZJIERvY3VtZW50cw0KDQoNCkxpbiwNCg0KDQpMaW4gVGFvIDxsaW50QGgzYy5jb20+ IGRpam86DQoNCj4gU29ycnkgc28gbGF0ZS4gSSB0aGluayBHdWFuZyBoYXZlIGV4cGxhaW5lZCB0 aGUgbWVhbmluZy4NCj4gSSBhZ3JlZSBoaXMgaWRlYSwgdGhlIGNvbnRyb2wgcHJvdG9jb2wgbXVz dCBiZSBzbm9vcGluZw0KDQpIb3cgZG8geW91IHN1Z2dlc3QgdG8gZGVhbCB3aXRoIHRoZSBjYXNl IHRoZSBOQURWIG1lc3NhZ2UgaXMgbG9zdCBhbmQgDQp0aGUgU0FWSSBkZXZpY2UgZG9lcyBub3Qg cmVjZWl2ZXMgaXQ/DQoNCj4gb3IgcHJveHkgdG8gcHJvdGVjdCB0aGUgbmV0d29yayBzZWN1cml0 eS4NCg0KYXMgaSBtZW50aW9uZWQgYWxyZWFkeSwgdGhpcyBpcyBpbmNsdWRlZCBhbHJlYWR5IGlu IHRoZSBmY2ZzIGRyYWZ0DQoNCj4gQW5kIHdlIGNhbg0KPiBsYXlvdXQgZGlmZmVyZW50IHNlY3Vy ZSBsZXZlbCBpbiB0aGlzIHdheS4NCg0KV2hhdCBkbyB5b3UgbWVuYSBieSB0aGlzPw0KDQo+IFRo ZXJlIGlzIHRoZQ0KPiBzYW1lIGFwcHJvYWNoIGluIElQdjQuDQoNCmhvdyBhcmUgeW91IHBsYW5u aW5nIHRvIGRvIHRoaXM/IElTIERBRCBtYW5kYXRvcnkgaW4gSVB2ND8NCg0KUmVnYXJkcywgbWFy Y2Vsbw0KDQoNCj4NCj4NCj4gSGFwcHkgbmV3IHllYXIhDQo+DQo+DQo+IC0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0NCj4gRnJvbTogIm1hcmNlbG8gYmFnbnVsbyBicmF1biIgPG1hcmNlbG9A aXQudWMzbS5lcz4NCj4gVG86ICJMaW4gVGFvIiA8bGludEBoM2MuY29tPg0KPiBDYzogIkd1YW5n IFlhbyIgPHlhb2dAbmV0YXJjaGxhYi50c2luZ2h1YS5lZHUuY24+OyAiJ0NocmlzdGlhbiBWb2d0 JyIgDQo+IDxjaHJpc3RpYW4udm9ndEBlcmljc3Nvbi5jb20+OyAiJ0ZyYW5rIFhpYSciIA0KPiA8 eGlheWFuZ3NvbmdAaHVhd2VpLmNvbT47ICInU0FWSSBNYWlsaW5nIExpc3QnIiA8c2F2aUBpZXRm Lm9yZz4NCj4gU2VudDogTW9uZGF5LCBEZWNlbWJlciAyOSwgMjAwOCAzOjE3IEFNDQo+IFN1Ympl Y3Q6IFJlOiBbc2F2aV0gV29ya2luZyBHcm91cCBBZG9wdGlvbiBvZiBJbmRpdmlkdWFsIFNBVkkg RG9jdW1lbnRzDQo+DQo+DQo+PiBMaW4gVGFvIGVzY3JpYmnzOg0KPj4+IERlYXIgQ2hyaXN0aWFu LCBHdWFuZyBhbmQgTWFyY2VsbywNCj4+Pg0KPj4+ICAgICBJIGFncmVlIHdpdGggR3VhbmcgdGhh dCB0aGUgbm9ybWFsIGJlaGF2aW9ycyBhbmQgZ29vZCBndXlzDQo+Pj4gTVVTVCBiZSBwcm90ZWN0 ZWQsIHNvIHdlIHNob3VsZCBzbm9vcCBhdCBjb250cm9sIHBhY2tldHMgdGhhbg0KPj4+IGRhdGFn cmFtIHBhY2tldHMuDQo+PiBJIGZhaWwgdG8gc2VlIHdoeSB0aGlzIGlzIHNvDQo+PiBjb3VsZCB5 b3UgZXhwYW5kPw0KPj4NCj4+IHJlZ2FyZHMsIG1hcmNlbG8NCj4+DQo+Pg0KPj4NCj4+PiBUaGlz IGlzIHRoZSB3b3J0aGVzdCB0aGluZyBpbiBTQVZJLg0KPj4+ICAgICBUaGVyZSBpcyB0d28gcGxh bmUgaW4gU1dJVENIOiBBU0lDIGFuZCBDUFUsIGl0DQo+Pj4gaXMgZWFzeSB0byBpbXBsZW1lbnQg QUNMIGluIEFTSUMgdG8gZmlsdGVyIGNvbnRyb2wgcGFja2V0cyB0bw0KPj4+IENQVSwgYW5kIHRo ZSBkYXRhZ3JhbSBwYWNrZXRzIGlzIGRpc2NhcmRlZCBieSBkZWZhdWx0LiBPdGhlcndpc2UsDQo+ Pj4gYWxsIGRhdGFncmFtIHBhY2tldHMgdGhhdCBoYXZuJ3QgcmlnaHQgdG8gZm9yd2FyZCBhcmUg YWxsDQo+Pj4gZGVsaXZlcmVkIHRvIENQVSwgdGhhbiBpdCB3aWxsIGJlIGZvcndhcmRlZCBieSBD UFUsIHRoaXMgaXMNCj4+PiBhIGJhZGVyIGdyYW51bGFyaXR5IHRoYW4gc25vb3BpbmcgY29udHJv bCBwYWNrZXRzLg0KPj4+DQo+Pj4gQmVzdCByZWdhcmRzDQo+Pj4NCj4+Pg0KPj4+IC0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4+PiBGcm9tOiAiR3VhbmcgWWFvIiA8eWFvZ0BuZXRhcmNo bGFiLnRzaW5naHVhLmVkdS5jbj4NCj4+PiBUbzogIidDaHJpc3RpYW4gVm9ndCciIDxjaHJpc3Rp YW4udm9ndEBlcmljc3Nvbi5jb20+OyAiJ0xpbiBUYW8nIiANCj4+PiA8bGludEBoM2MuY29tPg0K Pj4+IENjOiAiJ0ZyYW5rIFhpYSciIDx4aWF5YW5nc29uZ0BodWF3ZWkuY29tPjsgIidNYXJjZWxv IEJhZ251bG8gDQo+Pj4gQnJhdW4nIiA8bWFyY2Vsb0BpdC51YzNtLmVzPjsgIidTQVZJIE1haWxp bmcgTGlzdCciIDxzYXZpQGlldGYub3JnPg0KPj4+IFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDIz LCAyMDA4IDg6MTIgUE0NCj4+PiBTdWJqZWN0OiA/PzogW3NhdmldIFdvcmtpbmcgR3JvdXAgQWRv cHRpb24gb2YgSW5kaXZpZHVhbCBTQVZJIERvY3VtZW50cw0KPj4+DQo+Pj4NCj4+PiBEZWFyIENo cmlzdGlhbiBhbmQgTGluLA0KPj4+DQo+Pj4gSXQncyBjbGVhciB0aGF0IHNub29waW5nIE5EIGNh bm5vdCBhY2hpZXZlIGJldHRlciBwZXJmb3JtYW5jZSBhbmQgc2VjdXJpdHkNCj4+PiB0aGFuIHNu b29waW5nIGRhdGEgdHJhZmZpYy4gQWN0dWFsbHkgc25vb3BpbmcgTkQgbWF5IGNvc3QgbW9yZSBm b3IgaXQgbXVzdA0KPj4+IHRyYWNlDQo+Pj4gdGhlIHN0YXRlIG9mIERBRC4NCj4+Pg0KPj4+IEJ1 dCBJTU8sIGl0IGlzIG5vdCBhbiBpc3N1ZSBvZiByZXNvdXJjZSBzYXZpbmcsIGJ1dCBhbiBpc3N1 ZSB0aGF0IHdoYXQgU0FWSQ0KPj4+IGlzIGludGVuZGluZw0KPj4+IHRvIHByb3RlY3QuIElmIHRo ZSBTQVZJIGRldmljZSBzbm9vcHMgTkQgdG8gYmluZCBhZGRyZXNzIGFuZCBhbmNob3IsIGl0DQo+ Pj4gcHJvdGVjdHMNCj4+PiBnb29kIGd1eXMgd2hvIGFyZSB3b3JraW5nIGFjY29yZGluZyB0byB0 aGUgc3RhbmRhcmQuIEJ1dCBpZiBpdCBzbm9vcHMgZGF0YQ0KPj4+IHRyYWZmaWMgYW5kDQo+Pj4g YmluZHMgYWRkcmVzcyBhbmQgYW5jaG9yIHVzaW5nIHRoZSBwcmluY2lwbGUgb2YgRkNGUywgYmFk IA0KPj4+IGJlaGF2aW9ycywgc3VjaCBhcw0KPj4+IGF0dGFja3MgYWdhaW5zdA0KPj4+IERBRCwg YXJlIHByb3RlY3RlZC4NCj4+Pg0KPj4+IE1yLiBGcmVkIEJha2VyIG9uY2UgZ2F2ZSB1cyBhIGNv bnZpbmNpbmcgZXhhbXBsZTogd2hlbiBhbiBhdHRhY2tlciByZWNlaXZlcw0KPj4+IGENCj4+PiBE QUQgTlMsIGl0IGltbWVkaWF0ZWx5IHNlbmRzIGEgcGFja2V0IHdpdGggc291cmNlIGFkZHJlc3Mg c2V0IHRvIHRoZSBUYXJnZXQNCj4+PiBBZGRyZXNzIGluIHRoZSBOUw0KPj4+IHRvIG1ha2UgdGhl IFNBVkkgZGV2aWNlIHNldCB1cCBiaW5kaW5nIHdpdGhvdXQgcmVwbHlpbmcgYSBOQS4gVGhlbiB0 aGUgREFEDQo+Pj4gbm9kZSwgYWx0aG91Z2ggaGFzIGZpbmlzaGVkDQo+Pj4gYSBzdWNjZXNzZnVs IERBRCwgY2Fubm90IHVzZSB0aGUgdGVudGF0aXZlIGFkZHJlc3MgZm9yIHRoZSBTQVZJIGRldmlj ZSB3aWxsDQo+Pj4gdGFrZSBpdHMgdHJhZmZpYyBhcyBzcG9vZmluZyB0cmFmZmljLg0KPj4+DQo+ Pj4gQWx0aG91Z2ggaXQgaXMgcmF0aGVyIGEgc2VjdXJpdHkgcHJvYmxlbSBvZiBORCB0aGVuIHRo ZSBmYXVsdCBvZiBTQVZJLCB0aGUNCj4+PiBTQVZJIGRldmljZSBpcw0KPj4+IHByb3RlY3Rpbmcg YmFkIGRvaW5ncyBpbiB0aGUgZXhhbXBsZS4NCj4+Pg0KPj4+IEkgdGhpbmsgU0FWSSBzaG91bGQg YXQgbGVhc3QgcHJvdGVjdCBub3JtYWwgYmVoYXZpb3JzIGFuZCBnb29kIA0KPj4+IGd1eXMsIGJ1 dCBub3QNCj4+PiBwcm90ZWN0IGJhZCBiZWhhdmlvcnMuDQo+Pj4NCj4+PiBJIGFsc28gdGhpbmsg U0FWSSBzaG91bGQgcHJvdGVjdCB0aGUgVGFyZ2V0IEFkZHJlc3MgaW4gTkEgbWVzc2FnZSwgDQo+ Pj4gZm9yIGl0IGlzDQo+Pj4gYW5vdGhlciBraW5kIG9mIHNvdXJjZSBhZGRyZXNzLg0KPj4+DQo+ Pj4gR3VhbmcNCj4+PiAtLS0tLT8/Pz8tLS0tLQ0KPj4+ID8/PzogQ2hyaXN0aWFuIFZvZ3QgW21h aWx0bzpjaHJpc3RpYW4udm9ndEBlcmljc3Nvbi5jb21dDQo+Pj4gPz8/PzogMjAwOD8xMj8yMz8g MTg6MzYNCj4+PiA/Pz86IExpbiBUYW8NCj4+PiA/PzogRnJhbmsgWGlhOyBNYXJjZWxvIEJhZ251 bG8gQnJhdW47IFNBVkkgTWFpbGluZyBMaXN0OyA/ID8NCj4+PiA/PzogUmU6IFtzYXZpXSBXb3Jr aW5nIEdyb3VwIEFkb3B0aW9uIG9mIEluZGl2aWR1YWwgU0FWSSBEb2N1bWVudHMNCj4+Pg0KPj4+ IExpbiAtDQo+Pj4NCj4+PiBJIGFncmVlIHdpdGggeW91IHRoYXQgRG9TIGlzIGFuIHVuc29sdmVk IGlzc3VlIHRoYXQgd2UgaGF2ZSB5ZXQgdG8NCj4+PiB0YWNrbGUuIEhvd2V2ZXIsIEkgZG9uJ3Qg dGhpbmsgd2UgY2FuIHNvbHZlIHRoZSBpc3N1ZSwgZm9yIGFsbCBhZGRyZXNzDQo+Pj4gY29uZmln dXJhdGlvbiBtZXRob2RzLCBzaW1wbHkgYnkgY2hhbmdpbmcgd2hpY2ggcGFja2V0cyB3ZSBzbm9v cC4gIFNMQUFDDQo+Pj4gaW4gcGFydGljdWxhciBpcyBhbiBhZGRyZXNzIGNvbmZpZ3VyYXRpb24g bWV0aG9kIHdoZXJlIGFuIGF0dGFja2VyIGNhbg0KPj4+IG92ZXJsb2FkIGEgU0FWSSBkZXZpY2Ug anVzdCBhcyBlYXNpbHkgd2l0aCBjb250cm9sIHBhY2tldHMgKGkuZS4sDQo+Pj4gTmVpZ2hib3Ig U29saWNpdGF0aW9uIHBhY2tldHMpIGFzIHdpdGggZGF0YWdyYW0gcGFja2V0cy4NCj4+Pg0KPj4+ IFRoZSBvbmx5IHNjZW5hcmlvIGluIHdoaWNoIHNub29waW5nIGNvbnRyb2wgcGFja2V0cyBpbnN0 ZWFkIG9mIGRhdGFncmFtDQo+Pj4gcGFja2V0cyBjb3VsZCBtaXRpZ2F0ZSB0aGUgRG9TIGlzc3Vl IGlzIHdoZXJlIGFkZHJlc3NlcyBhcmUgZXhjbHVzaXZlbHkNCj4+PiBhc3NpZ25lZCB2aWEgREhD UC4gIEEgU0FWSSBkZXZpY2UgY2FuIHRoZW4gZXhjbHVzaXZlbHkgcmVseSBvbiBtZXNzYWdlcw0K Pj4+IGJlaW5nIHNlbnQgYnkgYSBzZXJ2ZXIgKG5vdCBkaXJlY3RseSBieSB0aGUgYXR0YWNrZXIp LCBzdWNoIHRoYXQgYSBEb1MNCj4+PiBhdHRhY2sgYWdhaW5zdCBhIFNBVkkgZGV2aWNlIHJlZHVj ZXMgdG8gdGhlIGV4aXN0aW5nIHRocmVhdCBvZiBhIERvUw0KPj4+IGF0dGFjayBhZ2FpbnN0IGEg REhDUCBzZXJ2ZXIuDQo+Pj4NCj4+PiBGV0lXOiAgU29tZSBTQVZJIHBhcnRpY2lwYW50cyB3ZXJl IGNvbnNpZGVyaW5nIGEgREhDUC1vbmx5IG9wdGlvbiBmb3INCj4+PiBTQVZJIGR1cmluZyBJRVRG IDczLg0KPj4+DQo+Pj4gLSBDaHJpc3RpYW4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiBPbiBEZWMgMjIs IDIwMDgsIExpbiBUYW8gd3JvdGU6DQo+Pj4NCj4+Pg0KPj4+PiBIZWxsbywgQ2hyaXN0aWFuLCBN YXJjZWxvIGFuZCBGcmFuazoNCj4+Pj4NCj4+Pj4gSSBhZ3JlZSB3aXRoIEZyYW5rJ3Mgdmlldy4g QmVjYXVzZSB0aGUgZm9yd2FyZGluZyBwYWNrZXQgaXMNCj4+Pj4gb2JzZXJ2ZWQgaW4gRkNGUyBk cmFmdCwgc28gdGhlIGZvcndhcmRpbmcgcHJvY2VzcyBpcyBkaXNydXB0ZWQsDQo+Pj4+IGFuZCB0 aGUgZGV2aWNlIGlzIHZ1bG5lcmFibGUsIGUuZy4gc2F2aSBjYWNoZSB0YWJsZSBleGhhdXN0ZWQs DQo+Pj4+IHRoZSBjcHUgb2Ygc3dpdGNoIGJ1c3ksIGV0Yy4NCj4+Pj4NCj4+Pj4gSW4gbXkgb3Bp bmlvbiwgb2JzZXJ2aW5nIHRoZSBDb250cm9sIFByb3RvY29sLCBlLmcuIERIQ1ANCj4+Pj4gb3Ig TkQgZXRjLCBpcyBlYXN5IHRvIGltcGxlbWVudCBpbiBzd2l0Y2ggZm9yIHRoZXNlIHByb3RvY29s DQo+Pj4+IGhhdmUgc3BlY2lhbCBjaGFyYWN0ZXJpc3RpYyB0aGF0IGNhbiBiZSBmaWx0ZXJlZCBp biBzd2l0Y2ggcG9ydCB3aGlsZQ0KPj4+PiB0aGUgZm9yd2FyZGluZyBwYWNrZXQgaXMgYmxvY2tl ZC4NCj4+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4NCj4+DQoNCg0KDQotLSANCi0tLS0NCk1B UkNFTE8gQkFHTlVMTyBCUkFVTg0KV2ViQ2FydGVybw0KVW5pdmVyc2lkYWQgQ2FybG9zIElJSSBk ZSBNYWRyaWQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnNhdmkgbWFpbGluZyBsaXN0DQpzYXZpQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NhdmkNCg== From yaoa02@mails.tsinghua.edu.cn Sun Jan 4 05:39:52 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B98D93A6A78 for ; Sun, 4 Jan 2009 05:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 8.235 X-Spam-Level: ******** X-Spam-Status: Yes, score=8.235 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] X-Spam-Report: * 1.3 SARE_SUB_ENC_GB2312 Subject specifies display in non-English lang * 3.2 CHARSET_FARAWAY_HEADER A foreign language charset used in headers * 0.3 CN_BODY_35 BODY: Body contains "\323\312\274\376" * 0.6 J_CHICKENPOX_45 BODY: 4alpha-pock-5alpha * 0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60% * [score: 0.4991] * 2.5 MIME_CHARSET_FARAWAY MIME character set indicates foreign language * 0.3 MIME_8BIT_HEADER Message header contains 8-bit character 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 AHTh7Xm3GiVt for ; Sun, 4 Jan 2009 05:39:50 -0800 (PST) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id 09FA43A6951 for ; Sun, 4 Jan 2009 05:39:50 -0800 (PST) Received: from tu132215.ip.tsinghua.edu.cn ([166.111.132.215] helo=netarchld5f663) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1LJTC0-0003XH-FA; Sun, 04 Jan 2009 21:39:00 +0800 From: "Guang Yao" To: "'marcelo bagnulo braun'" References: <005901c96128$ea3185f0$420c7c0a@china.huawei.com> <494AA050.2060300@it.uc3m.es> <7141029F-A8F2-4892-977A-BFF510A405B7@ericsson.com> <002601c9641a$a6446fc0$2211990a@h3c.huawei3com.com> <60D2E2DD-9815-4374-9A48-EC646396198E@ericsson.com> <008901c964f7$ca10ad00$5e320700$@tsinghua.edu.cn> <4957CF87.9050601@it.uc3m.es> <001001c96973$3b508ce0$b1f1a6a0$@tsinghua.edu.cn> <49590EF6.4080407@it.uc3m.es> <001201c96a4f$8dc3cd70$a94b6850$@tsinghua.edu.cn> <495A300F.3090401@it.uc3m.es> In-Reply-To: <495A300F.3090401@it.uc3m.es> Date: Sun, 4 Jan 2009 21:38:43 +0800 Message-ID: <001e01c96e71$c31d7fe0$49587fa0$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclqkujImvbSH+oGRbGjCSxY78p3XwDqaRIw Content-Language: zh-cn Cc: 'Lin Tao' , 'SAVI Mailing List' , 'Christian Vogt' , 'Frank Xia' Subject: [savi] =?gb2312?b?KioqU1BBTSoqKiA4LjIzNSAoNSkgtPC4tDogtPC4tDog?= =?gb2312?b?tPC4tDogtPC4tDogIFdvcmtpbmcgR3JvdXAgQWRvcHRpb24gb2Yg?= =?gb2312?b?SW5kaXZpZHVhbCBTQVZJIERvY3VtZW50cw==?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2009 13:39:52 -0000 [Sorry for replying late. There is something wrong with my mail server = and I have to reply using this mail address.] -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2008=C4=EA12=D4=C230=C8=D5 22:29 =CA=D5=BC=FE=C8=CB: Guang Yao =B3=AD=CB=CD: 'Christian Vogt'; 'Lin Tao'; 'Frank Xia'; 'SAVI Mailing = List'; 'Jun Bi' =D6=F7=CC=E2: Re: =B4=F0=B8=B4: =B4=F0=B8=B4: =B4=F0=B8=B4: [savi] = Working Group Adoption of Individual SAVI Documents [Meta comment: Guang, please indent or mark somehow your text in order to distinguish from my previous comments, cause it is becoming increasingly hard to follow this thread) below... Guang Yao escribi=A8=AE: > > I think we are having two somehow orthogonal issues here: > - On one hand we are discussing what is the type of address ownership > proof that we want to have. I think that irrespectively whether you = use > control messages or data packets, you can use the FCFS principle as > address ownership. I mean, in both cases, the first node that sends a > packet with a given address claims the address ownership. The first > packet can be a data packet or a NS or NADV packet, but it is FCFS > principle all the way. I don't thing you are propising a different > address ownership proof afaict > > For the SAVI device, it is correct that address ownership can be = assigned > according > to the principle of FCFS, no matter data traffic or control traffic is > chosen. It is not the fault=20 > of the principle of FCFS. But it is correct from the view of the SAVI > device. > > Please consider the hosts in the same network. For currently we cannot > modify the > host, they have none sense of the existing of a SAVI device. They are > working assuming > all the nodes are working according to the standard and > the switch or router would never drop its traffic if it obeys the = rules, > unless congestion. > > =20 mmm, what about ingress filtering? If a node has multiple addresses with different prefixes, packets can get dropped cause ingress filtering (this is fairly common case in multihomed scenarios for instance) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~Guang, 1.4: ~As I know, ingress filtering has loose and feasible mode to handle multihoming [RFC 3704]. ~Anyway, false positive is a very bad feature for a mechanism.=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= The point that i am trying to make is that if we intend to create a SAVI mechanism that is transparent to the edn nodes, we will need to make some assumptions and these assumptions are likely to not hold for every possible scenario, and when they don't hold, some things are likely to = fail. Of course we must minimize the situations where that happens, i agree ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~Guang, 1.4: ~I'm not sure it's a problem of assumption. ~Maybe you can make your assumptions clear. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= > However, we put a superpower manager into the network without = notifying the > hosts.=20 > And the manager designed two new rules:=20 > 1a, if you use an address in the data traffic firstly, you get > the ownership; > 2a, if you use an address given to another, your packet will be = dropped.=20 > Unfortunately, these rules are not known by any host. The host runs > according to these two rules:=20 > 1b, If a tentative address is not replied by another, I can use it;=20 > 2b, My packet will be delivered if I use my address. > =20 Well, DAD is not guaranteed to work in all the cases, so it may be possible that there is a collision even with DAD being successful. In that case, you enter in very strange failure modes. So, you can use that address indeed but there is no guarantees it will your own and your own only ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~Guang, 1.4: ~Yes, I agree it's not perfect. However, we can compare the failure possibility of DAD snooping=20 ~and FCFS(false positive only): ~1. FCFS fails if (1.1) normal DAD is being attacked; ~ (1.2) DAD NA is missing; ~ (1.3)Collision you mentioned ~2. DAD snooping fails when (2.1) DAD NA is missing ~ (2.2) Collision you mentioned ~ ~I think it is quite clear (1.2),(1.3) ,(2.1),(2.2) happen with very = little possibility, but (1.1) ~can happen with great possibility. ~And (1.2),(1.3) ,(2.1),(2.2) is the failure of DAD mechanism, not the = fault of SAVI. (1.1) is ~the fault of SAVI. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= > The first rules of SAVI device and host are very different. > 1 the owner of a tentative traffic what do you mean by the owner of tentative traffic? > is not enforced to reply a DAD NA. So 1a > is not the sufficient condition of 1b. > 2 any host can reply the DAD NS. So 1a is not the necessary condition = of 1b. > And there may be more examples to prove that 1a is not a necessary and > sufficient condition of 1b. > So 1a and 1b are separate conditions.=20 > If we want to use 1a, we must assure that all hosts run according to = 1a. Or > else, something goes bad. > But actually, all normal hosts run according to 1b. > > In short, FCFS is OK, but it will be bad if the FCFS principle is not known > clearly by host. If we don't want to modify > host, we must make the SAVI device transparent and import no new rule. > > =20 I am not sure what is the problem here. We can use the FCFS principle both with data traffic and control packets as i suggested in the previous email The SAVI device can create state both based on the ND traffic and the data traffic, there is no problem with that. I guess it is up to the WG to decide if we think that the additional complexity required for the SAVI device to also understand ND messages is worth it. I am not sure we are disagreeing here... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~Guang, 1.4: ~I think "both" would not solve the problem.=20 ~ND only is the reasonable solution. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= > - On the other hand, there is the disucssion if we do this based on = data > packets or using control packets, in particular NSol and NAdv). I = don't > have a problem in doing it in both. I don't think you can do it only > with control packets. In particular, consider the case of optimistic > DAD. In that case, the node starts using the address even wihtout = having > the DAD completed. Moreover, DAD is a one time operation that is > succesfull when there is no reply. So if we have a transite failure > duringt he DAD period, and packets are not delivered to the SAVI = device > during that time, SAVI would fail. I do agree that it would be > interesting to evaluate if looking into ND messages could help to > prevent some scenarion as the one you mention above. But i think that = a > solution that solely relies in ND messages would be not very robust > (i.e. it would fail if the DAD packet is lost for instance) > > Optimistic DAD would not trouble for a DAD NS has been sent and the = SAVI > device > knows exactly whether there is a collision. If there is a collision, = the > source address > without finishing DAD will be dropped. There is no problem. And if no > collision, there=20 > is no problem to forward these packets. > > =20 > I agree that SAVI will fail if the DAD NA message is not delivered to = the > tentative node. > So I think maybe the SAVI device should guarantee the procedure will = not be > disrupted, > e.g., it can play as a ND proxy. but how do you guarantee that the ND message was delviered to the SAVI device in the first place? (And how do you guarantee that the ND message is delviered to all the nodes?) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~Guang, 1.4: ~SAVI device is always the device directly connected with the host(first = hop switch or router). ~So it is not hard to guarantee the first point. ~And I don't think we have to guarantee ND message is delivered to all nodes. It is enforced ~by standard and it only fails with little possibility. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= I mean, the problem with DAD robustness is that the topology can change after the DAD procedure was done. So, suppose you have two lans that are working and that at some point in time they are merged into one lan. In that case, the nodes on each lan have already executed the DAD procedure and they are not even aware of the merging, so they will not repeat the DAD procedure. (this can happne when there is a failure and a network gets partitioned and then repaired for example) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~Guang, 1.4: ~A great example. But ~(1) If the nodes are not aware of merging, they must not leave their = switch (or else it is the same ~as a node is attached to the LAN for the first time.) and the switch = must be used in the new LAN. If ~the binding is performed on the switch, there is no trouble. If the = binding is performed on the router, ~also no trouble. The binding information is always not removed and it = can be used again, without requirement ~of another DAD. ~(2) It is really an infrequent situation. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= So DAD is inherently non robust cause the procedure is successful when there is NO reply, but you cannot know if there is no reply cause there is no address collision or because the packet was lost. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~Guang, 1.4: ~(1) The SAVI device knows what the situation is clearly, because it has recorded all addresses. ~(2) And my point is: We choose DAD snooping for host relies on DAD exclusively, rather than ~DAD is robust. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= > But I think relying on data traffic has the > same problem, right? > > =20 not really, cause there are many data packets. So, if one data packet gets lost, there will be more to come, so sooner or later one of them will make it (or we have bigger problems) The problem with DAD is that we send only one packet and if it is lost we are out of luck. BEsides, we could send several packets, but this would imply longer delay, whcih is also bad. Data pakcet otoh, there are plenty of them, so the problem is handled = better ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~Guang, 1.4: ~Well, I wonder will DAD message be dropped at the first link? I = remember link layer protocol ~has acknowledgement and retransmission policy. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= >> And I mentioned SAVI must control the NA messages, for the Target = Address >> =20 > in > =20 >> the NA message is another kind of source address. If the SAVI device = has >> =20 > set > =20 >> up >> a binding table, it can filter spoofed NA with ease.=20 >> >> It may be argued that in any situation, a node can avoid replying to = NS >> message even the >> Target Address has been assigned to it, and the tentative node will = be >> assigned duplicated and "spoofing" address. >> But still it is very different because the probability for two node = to >> generate same address is little and the possible damage=20 >> Is trivial.=20 >> But if an attacker designedly attacks against the tentative address, = the >> consequence is very bad. Unfortunately, FCFS >> using data traffic makes this situation possible. >> >> IMO, binding address using data traffic is wrong because data traffic = is >> =20 > not > =20 >> defined to have the >> function of assigning address to node. It is the necessary condition = but >> =20 > not > =20 >> sufficient condition. >> >> >> =20 >> =20 > but the problem is that there is no sufficient condition for knowing > that a node has configured an address. I mean, DAD messages can be = lost > and they are only sent once in a nion reliable fashion. In addition, > nodes do optimistic DAD and start using the address without waiting = for > the DAD to be completed. > > So, if you want to design a robust mechanism you need to deal with all > that, and using data packets seem the ultimate line > > Yes, I want to design a robust mechanism. But I don=A1=AFt think we = have to use > data traffic. > I think the mechanism can be like this: > 1 It must ensure the security and completeness of DAD. > =20 how do you think you can do that? As i said, imho DAD is inherently non robust > 1.1 Address can be bound only after a DAD NS and there is no > collision in local binding table. > =20 as i said several times, i thin it may be ok to use ND messages to populate the SAVI DB, but i don't think we should rely solely on ND. I think we need to use data packets as well, in case DAD packets are missing for soem reason BTW, i also think we should use dhcp messages if we can I think we need to understnad what do we gain by adding this complexity (clearly relying solely on dat packets is simpler, but relying on signaling packets as well may prevent som attacks, but we need to understadn that better imho) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~Guang, 1.4: ~OK, I will make clear WHAT we lose if we use data packet solely. ~(1) Normal behavior hosts will face additional vulnerability for their legally got addresses=20 ~can be regarded as spoofing by SAVI device. Attack against Target = Address in DAD NS message ~is connived and protected by SAVI device. ~(2)Evil behavior hosts benefit from easily flooding addresses. They = easily take control of=20 ~an amount of addresses in an address-critical network and make other = hosts hard to find a ~useable address. Moreover, such attack is also protected by SAVI = device. However, DAD snooping ~can at least reduce the speed of address occupation. ~(3)For any data traffic may trigger binding, the cost of processing a single packet is heavy. ~Any packet with new address will trigger a binding and attacker can = design a rather easy attack ~against SAVI device. ~ FCFS flow: Data packet----(source in binding table)----->forward ----(source not in binding table)----->check whether to bind or not--------(address used by another)-->drop =09 -------(first use)->bind and forward Signal packet (I'm not clear) DAD Snooping flow: Data packet---(source in binding table)----->forward ---(source not in binding table)----->drop Signal Packet--------(address used by another)-->drop -------(first use)->bind and forward For any packet, DAD snooping has only a check process. But FCFS may have = two checks. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~Guang, 1.4: ~And if use signal packets and data packets together, (2) and (3) will = still stand. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= > 1.2 If there is a collision in local binding, and a DAD NA is > replied from the address owner, it must > ensure the NA will be delivered to the tentative node. > =20 sure, this is basic DAD behaviour, nothing new here, right? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~Guang, 1.4: ~Yes. If every NA is delivered to the tentative node, the SAVI device doesn't have to do anything here. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= > 1.3 If the address owner doesn't reply, it may either: 1, delete > former binding and set up new binding;=20 > or 2 Send a NA to the tentative node instead of the address > owner. > =20 sure, this is done already in the FCFS draft, > 1.4 Any NA with spoofed Target Address must be dropped. > 2 Data traffic is either dropped or forwarded according to binding, without > triggering new binding entry. > > =20 here, i disagree as i said, i think we should also use data traffic as well > I think the security and completeness of DAD is necessary even using = data > traffic to bind address.=20 > =20 how do you plan to achieve that? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~Guang, 1.4: ~The security problem of DAD is easy to handle since the SAVI device has recorded all the addresses ~a node owns. So it is easy to filter spoofing DAD NA. ~The completeness is harder. But the SAVI device can run as a ND proxy = as mention above. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~Guang, 1.4: ~Regards, Guang ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= regards, marcelo > If this condition is not guaranteed, there will be varies of attacks = and > collisions. > > (In order to deal with the attack you mention, the SAVI device can = sniff > DAD packets and identify the suggested attacks if it first sees a DAD > packet and then a data packet with the same address and no DAD reply = to > the original request... of course this makes the logic more comlex) > > Regards, marcelo > > > =20 >>> Although it is rather a security problem of ND then the fault of = SAVI, >>> =20 > the > =20 >>> SAVI device is >>> protecting bad doings in the example. >>> >>> I think SAVI should at least protect normal behaviors and good guys, = but >>> =20 >>> =20 >> not >> =20 >> =20 >>> protect bad behaviors. >>> >>> I also think SAVI should protect the Target Address in NA message, = for it >>> =20 >>> =20 >> is >> =20 >> =20 >>> another kind of source address.=20 >>> >>> Guang >>> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >>> =B7=A2=BC=FE=C8=CB: Christian Vogt = [mailto:christian.vogt@ericsson.com]=20 >>> =B7=A2=CB=CD=CA=B1=BC=E4: 2008=C4=EA12=D4=C223=C8=D5 18:36 >>> =CA=D5=BC=FE=C8=CB: Lin Tao >>> =B3=AD=CB=CD: Frank Xia; Marcelo Bagnulo Braun; SAVI Mailing List; = =D2=A6 =B9=E3 >>> =D6=F7=CC=E2: Re: [savi] Working Group Adoption of Individual SAVI = Documents >>> >>> Lin - >>> >>> I agree with you that DoS is an unsolved issue that we have yet to >>> tackle. However, I don't think we can solve the issue, for all = address >>> configuration methods, simply by changing which packets we snoop. = SLAAC >>> in particular is an address configuration method where an attacker = can >>> overload a SAVI device just as easily with control packets (i.e., >>> Neighbor Solicitation packets) as with datagram packets. >>> >>> The only scenario in which snooping control packets instead of = datagram >>> packets could mitigate the DoS issue is where addresses are = exclusively >>> assigned via DHCP. A SAVI device can then exclusively rely on = messages >>> being sent by a server (not directly by the attacker), such that a = DoS >>> attack against a SAVI device reduces to the existing threat of a DoS >>> attack against a DHCP server. >>> >>> FWIW: Some SAVI participants were considering a DHCP-only option = for >>> SAVI during IETF 73. >>> >>> - Christian >>> >>> >>> >>> On Dec 22, 2008, Lin Tao wrote: >>> >>> =20 >>> =20 >>> =20 >>>> Hello, Christian, Marcelo and Frank: >>>> >>>> I agree with Frank's view. Because the forwarding packet is >>>> observed in FCFS draft, so the forwarding process is disrupted, >>>> and the device is vulnerable, e.g. savi cache table exhausted, >>>> the cpu of switch busy, etc. >>>> >>>> In my opinion, observing the Control Protocol, e.g. DHCP >>>> or ND etc, is easy to implement in switch for these protocol >>>> have special characteristic that can be filtered in switch port = while >>>> the forwarding packet is blocked. >>>> =20 >>>> =20 >>>> =20 >>> >>> =20 >>> =20 >>> =20 >> >> >> =20 >> =20 > > > > > =20 From marcelo@it.uc3m.es Sun Jan 4 05:45:34 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 737F13A6951 for ; Sun, 4 Jan 2009 05:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.723 X-Spam-Level: X-Spam-Status: No, score=-3.723 tagged_above=-999 required=5 tests=[AWL=-0.562, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 118E3LMCDaZG for ; Sun, 4 Jan 2009 05:45:33 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id CBC7B3A6A78 for ; Sun, 4 Jan 2009 05:45:31 -0800 (PST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131])by smtp03.uc3m.es (Postfix) with ESMTP id 9F57172AC97;Sun, 4 Jan 2009 14:45:14 +0100 (CET) Received: from r190-132-74-108.dialup.mobile.ancel.net.uy(r190-132-74-108.dialup.mobile.an cel.net.uy [190.132.74.108]) bywebcartero01.uc3m.es (Horde MIME library) with HTTP; Sun, 04 Jan 200914:45:12 +0100 Message-ID: <20090104144512.ozkuhyudc4cg80sk@webcartero01.uc3m.es> Date: Sun, 04 Jan 2009 14:45:12 +0100 From: MARCELO BAGNULO BRAUN To: Lin Tao References: <"005901c9612 8$ea3185f0$420c7c0a"@china.huawei.com><494AA050.2060300@it.uc3m.es><"714102 9F-A8F2-4892-977A-BFF510A405B7"@ericsson.com><"60D2E2DD-9815-4374-9A48-EC64 6396198E"@ericsson.com><008901c964f7$ca10ad00$5e320700$@tsinghua.edu.cn><"0 13001c965ae$ce9efa90$8311990a"@h3c.huawei3com.com><4957D0DB.8050304@it.uc3m .es><009b01c96b2d$f1713b80$4a11990a@h3c.huawei3com.com><20081231140040.zf4f 79t39oossk8o@webcartero01.uc3m.es><003001c96e6e$846a32a0$0011990a@h3c.huawei3com.com> In-Reply-To: <003001c96e6e$846a32a0$0011990a@h3c.huawei3com.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-37.9553 TC:1F TRN:94 TV:5.5.1026(16380.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Guang Yao , 'SAVIMailing List' , 'Christian Vogt' , 'FrankXia' Subject: Re: [savi] Working Group Adoption of Individual SAVI Documents X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2009 13:45:34 -0000 Lin Tao dijo: > 1. About NADV message lost. > The SAVI device is the first access device, so if this message is lost, > we can consider the host is offline. First, i am not sure we want to impose such restriction. this is one possible configuration, but depending what do you want to enforce, it may be ok to have the SAVI function in a higher part of the topology (for instance, if you have a switch topology Second, if the host is connected to a hub, for instance, and the hub is then connected to a switch where the SAVI function is performed, then from the host perspective, the DAD procedure would have been successfull but the sav device will not be aware of the NADV packet. IF the failure is restored after that, then the SAVI will filter the data packets Bottom line is, what do you do when the savi device receives a data packet contianing a source address that is not present in the savi db? I can see 3 options here: 1- one is to filter it. I don't think this is acceptable 2- the other one is to create a new savi db entry with the information of the data packet 3- the third option is to perfrom some check, like the NUD procedure with the information contained in the packet. I don 't feel this is necesary, since i fail to see what additional information would this new check would provide Do you think there are more options that this? which option do you think is reasonable and why? > > 2.Secure level. > All the SAVI feature(ND proxy, etc) should be optional, we can > define the feature in differ level. The weakest level is no SAVI, than > deal with forwarding parcket, than controling parcket (there are > more level in controling parcket, ND/ARP, DHCP, etc). > I fail to see why do you think that a control packet packet provides a higher security level than the data packets BEsides as i mention already, i don't see using control packets and data packets as mutually exclusive, but as complementing each other. The question here is about a tradeoff between simplicity and capabilities. > 3.Same approach in IPv4. > Yes, DAD mandatory in IPv4 is one. I don't understand what you mean here... > We have more approach, > for example, ARP proxy, ARP snooping, ARP detection for same > source MAC, etc. > > 4. About RFC5227 > This RFC may not be universally implemented. But SAVI group > dicuss the device, and the device can implement it first. Otherwise, > we can improve it for device in SAVI standard, the same as ND. > I don't understand what you mean here We can certainly require new capabilities in the SAVI device, but to rely in IPv4 DAD, the hosts need to implement it In order to define a mechanism that is suscetible of wide deployment we need to rely on features that are actually widely deployed in the hosts and i am not sure rfc5227 is one of them Regards, marcelo > > > ----- Original Message ----- > From: "MARCELO BAGNULO BRAUN" > To: "Lin Tao" > Cc: "Guang Yao" ; "'SAVIMailing > List'" ; "'Christian Vogt'" > ; "'Frank Xia'" > Sent: Wednesday, December 31, 2008 9:00 PM > Subject: Re: [savi] Working Group Adoption of Individual SAVI Documents > > > Lin, > > > Lin Tao dijo: > >> Sorry so late. I think Guang have explained the meaning. >> I agree his idea, the control protocol must be snooping > > How do you suggest to deal with the case the NADV message is lost and > the SAVI device does not receives it? > >> or proxy to protect the network security. > > as i mentioned already, this is included already in the fcfs draft > >> And we can >> layout different secure level in this way. > > What do you mena by this? > >> There is the >> same approach in IPv4. > > how are you planning to do this? IS DAD mandatory in IPv4? > > Regards, marcelo > > >> >> >> Happy new year! >> >> >> ----- Original Message ----- >> From: "marcelo bagnulo braun" >> To: "Lin Tao" >> Cc: "Guang Yao" ; "'Christian Vogt'" >> ; "'Frank Xia'" >> ; "'SAVI Mailing List'" >> Sent: Monday, December 29, 2008 3:17 AM >> Subject: Re: [savi] Working Group Adoption of Individual SAVI Documents >> >> >>> Lin Tao escribi=F3: >>>> Dear Christian, Guang and Marcelo, >>>> >>>> I agree with Guang that the normal behaviors and good guys >>>> MUST be protected, so we should snoop at control packets than >>>> datagram packets. >>> I fail to see why this is so >>> could you expand? >>> >>> regards, marcelo >>> >>> >>> >>>> This is the worthest thing in SAVI. >>>> There is two plane in SWITCH: ASIC and CPU, it >>>> is easy to implement ACL in ASIC to filter control packets to >>>> CPU, and the datagram packets is discarded by default. Otherwise, >>>> all datagram packets that havn't right to forward are all >>>> delivered to CPU, than it will be forwarded by CPU, this is >>>> a bader granularity than snooping control packets. >>>> >>>> Best regards >>>> >>>> >>>> ----- Original Message ----- >>>> From: "Guang Yao" >>>> To: "'Christian Vogt'" ; "'Lin Tao'" >>>> >>>> Cc: "'Frank Xia'" ; "'Marcelo Bagnulo >>>> Braun'" ; "'SAVI Mailing List'" >>>> Sent: Tuesday, December 23, 2008 8:12 PM >>>> Subject: ??: [savi] Working Group Adoption of Individual SAVI Document= s >>>> >>>> >>>> Dear Christian and Lin, >>>> >>>> It's clear that snooping ND cannot achieve better performance and secu= rity >>>> than snooping data traffic. Actually snooping ND may cost more for it = must >>>> trace >>>> the state of DAD. >>>> >>>> But IMO, it is not an issue of resource saving, but an issue that >>>> what SAVI >>>> is intending >>>> to protect. If the SAVI device snoops ND to bind address and anchor, i= t >>>> protects >>>> good guys who are working according to the standard. But if it snoops = data >>>> traffic and >>>> binds address and anchor using the principle of FCFS, bad >>>> behaviors, such as >>>> attacks against >>>> DAD, are protected. >>>> >>>> Mr. Fred Baker once gave us a convincing example: when an attacker >>>> receives >>>> a >>>> DAD NS, it immediately sends a packet with source address set to >>>> the Target >>>> Address in the NS >>>> to make the SAVI device set up binding without replying a NA. Then the= DAD >>>> node, although has finished >>>> a successful DAD, cannot use the tentative address for the SAVI >>>> device will >>>> take its traffic as spoofing traffic. >>>> >>>> Although it is rather a security problem of ND then the fault of SAVI,= the >>>> SAVI device is >>>> protecting bad doings in the example. >>>> >>>> I think SAVI should at least protect normal behaviors and good >>>> guys, but not >>>> protect bad behaviors. >>>> >>>> I also think SAVI should protect the Target Address in NA message, >>>> for it is >>>> another kind of source address. >>>> >>>> Guang >>>> -----????----- >>>> ???: Christian Vogt [mailto:christian.vogt@ericsson.com] >>>> ????: 2008?12?23? 18:36 >>>> ???: Lin Tao >>>> ??: Frank Xia; Marcelo Bagnulo Braun; SAVI Mailing List; ? ? >>>> ??: Re: [savi] Working Group Adoption of Individual SAVI Documents >>>> >>>> Lin - >>>> >>>> I agree with you that DoS is an unsolved issue that we have yet to >>>> tackle. However, I don't think we can solve the issue, for all address >>>> configuration methods, simply by changing which packets we snoop. SLA= AC >>>> in particular is an address configuration method where an attacker can >>>> overload a SAVI device just as easily with control packets (i.e., >>>> Neighbor Solicitation packets) as with datagram packets. >>>> >>>> The only scenario in which snooping control packets instead of datagra= m >>>> packets could mitigate the DoS issue is where addresses are exclusivel= y >>>> assigned via DHCP. A SAVI device can then exclusively rely on message= s >>>> being sent by a server (not directly by the attacker), such that a DoS >>>> attack against a SAVI device reduces to the existing threat of a DoS >>>> attack against a DHCP server. >>>> >>>> FWIW: Some SAVI participants were considering a DHCP-only option for >>>> SAVI during IETF 73. >>>> >>>> - Christian >>>> >>>> >>>> >>>> On Dec 22, 2008, Lin Tao wrote: >>>> >>>> >>>>> Hello, Christian, Marcelo and Frank: >>>>> >>>>> I agree with Frank's view. Because the forwarding packet is >>>>> observed in FCFS draft, so the forwarding process is disrupted, >>>>> and the device is vulnerable, e.g. savi cache table exhausted, >>>>> the cpu of switch busy, etc. >>>>> >>>>> In my opinion, observing the Control Protocol, e.g. DHCP >>>>> or ND etc, is easy to implement in switch for these protocol >>>>> have special characteristic that can be filtered in switch port while >>>>> the forwarding packet is blocked. >>>>> >>>> >>>> >>>> >>>> >>> >>> > > > > -- > ---- > MARCELO BAGNULO BRAUN > WebCartero > Universidad Carlos III de Madrid > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid From christian.vogt@ericsson.com Wed Jan 7 16:48:32 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FC8E3A6905 for ; Wed, 7 Jan 2009 16:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 kioAjrwm3apj for ; Wed, 7 Jan 2009 16:48:31 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 424A83A682D for ; Wed, 7 Jan 2009 16:48:31 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E9B1621373; Thu, 8 Jan 2009 01:48:16 +0100 (CET) X-AuditID: c1b4fb3c-adf5ebb00000304c-bf-49654d503070 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B906C2124C; Thu, 8 Jan 2009 01:48:16 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jan 2009 01:48:16 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jan 2009 01:48:15 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1552C245F; Thu, 8 Jan 2009 02:48:16 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 62F3B4DA9B; Thu, 8 Jan 2009 02:48:14 +0200 (EET) Message-Id: <19ADF7C7-6E46-47F6-B7AC-2DF82C1F1636@ericsson.com> From: Christian Vogt To: SAVI Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 7 Jan 2009 16:48:13 -0800 X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 08 Jan 2009 00:48:15.0884 (UTC) FILETIME=[CAA054C0:01C9712A] X-Brightmail-Tracker: AAAAAA== Cc: Guang Yao Subject: [savi] Binding establishment based on data or control packets? 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, 08 Jan 2009 00:48:32 -0000 Dear all - Marcelo and Guang had an interesting discussion on whether FCFS SAVI should establish bindings based on data packets or based on control packets. I would like to follow up on this. To summarize: Whereas draft-bagnulo-savi-fcfs proposes the exclusive use of data packets to establish bindings, Guang believes that bindings should be established exclusively based on control packets. According to Guang, the advantage of exclusively using control packets to establish bindings would be a better means to synchronize hosts and SAVI devices regarding a host's right to use an address. The standard way for hosts to determine their right to use an address is via the Duplicate Address Detection or DHCP procedure, whereas according to draft-bagnulo-savi-fcfs, SAVI devices determine such right based on previously received data packets. The use of different procedures for hosts and SAVI devices raises the question of whether hosts and SAVI devices may lose sync regarding the right to use an address. One case where this is an issue, as brought up by Guang, is the deliberate establishment of bogus bindings by an attacker in order to keep a victim host from aquiring a functioning address. The Neighbor Solicitation message that the victim host must send during the Duplicate Address Detection procedure discloses the address that the victim host is trying to acquire without establishing a binding for the address. This enables the attacker to establish a bogus binding, and hence to make the address dysfunctional for the victim host, by sending a data packet that appears to originate from the address. To prevent this attack, Guang concludes that bindings should exclusively be established based on control packets, i.e., based on monitoring the messages exchanged during the Duplicate Address Detection or DHCP procedure. Like Marcelo, I agree with this partly, but not entirely: Although using control packets for binding establishment is necessary to prevent the attack described above, it is not required that control packets are used /exclusively/. Using both, control and data packets, for binding establishment would be possible as well. More specifically, the reason for the aforementioned attack is the existence of a shortcut for binding establishment, which is non-legitimate, but which is not prevented either. To prevent the attack, the shortcut must be eliminated. And this means that binding establishment should be based on the first packet independent of whether this is a data packet or a control packet. The residual question therefore is whether or not data packets should be used for binding establishment in addition to control packets. There are pros and cons for either approach: - The advantage of using data packets is that statically configured addresses become straightforward to support. Hosts with statically configured addresses cannot be expected to engage in any exchange of control packets, so a simple method to establish a binding in this case is based on the first data packet. - The advantage of /not/ using data packets is that it becomes less likely for hosts and SAVI devices to lose sync regarding a host's right to use an address. A host and its connected SAVI device then always determine such right based on the same control packets, so in the absence of control packet loss on the link segment between the host and the SAVI device, it is impossible for the host and the SAVI device to have different understanding regarding the host's right to use an address. However, neither of these is a strong argument for or against the use of data packets for binding establishment. Statically configured addresses could also be supported if bindings were established based on only control packets: A SAVI device could, e.g., initiate a Duplicate Address Detection procedure on behalf of a host when the host sends the first data packet from a statically configured address. Loss of synchronization between hosts and SAVI devices could, e.g., also be resolved with the Neighbor Unreachability Detection procedure, such as proposed in draft-bagnulo-savi-fcfs. I think that, in order to move forward and decide whether or not to use data packets for binding establishment, we should also consider the affects on SAVI solution components other than the initial binding establishment. One such component is inter-switch mobility: Would the re-establishment of the binding in the new switch become easier based on data packets or control packets? How about the removal of the binding in the old switch? Another component is SeND support (in the SeND-based SAVI variant): If binding establishment is exclusively based on control packets, the use of SeND automatically protects binding establishment. This is not the case if data packets are used to establish bindings because SeND does not protect the source address in data packets. SeND can then only protect the Neighbor Unreachability Detection procedure, which is used for garbage collection in draft-bagnulo-savi-fcfs. What does the working group think about this? Please comment. One final, important note: Of course, the FCFS principle, the core idea of draft-bagnulo-savi-fcfs, is orthogonal to whether or not data packets are used for binding establishment. And based on the feedback we got at the SAVI meeting in Minneapolis and so far on this mailing list, the FCFS principle is by many considered the way to go. - Christian From marcelo@it.uc3m.es Wed Jan 7 19:29:02 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 8C56A3A6993 for ; Wed, 7 Jan 2009 19:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.918 X-Spam-Level: X-Spam-Status: No, score=-3.918 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 Gx1yBXz98GRd for ; Wed, 7 Jan 2009 19:29:01 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 36E893A6984 for ; Wed, 7 Jan 2009 19:29:00 -0800 (PST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131])by smtp02.uc3m.es (Postfix) with ESMTP id 3C4B1654669;Thu, 8 Jan 2009 04:28:44 +0100 (CET) Received: from r190-135-152-31.dialup.adsl.anteldata.net.uy(r190-135-152-31.dialup.adsl.an teldata.net.uy [190.135.152.31]) bywebcartero01.uc3m.es (Horde MIME library) with HTTP; Thu, 08 Jan 200904:28:44 +0100 Message-ID: <20090108042844.jy12ki34coogggko@webcartero01.uc3m.es> Date: Thu, 08 Jan 2009 04:28:44 +0100 From: MARCELO BAGNULO BRAUN To: Christian Vogt References: <19ADF7C7-6E46-47F6-B7AC-2DF82C1F1636@ericsson.com> In-Reply-To: <19ADF7C7-6E46-47F6-B7AC-2DF82C1F1636@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-17.7097 TC:1F TRN:72 TV:5.5.1026(16388.004) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Guang Yao , SAVI Mailing List Subject: Re: [savi] Binding establishment based on data or control packets? 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, 08 Jan 2009 03:29:02 -0000 Hi Christian, thanks for the summary some comments below... Christian Vogt dijo: > More specifically, the reason for the aforementioned attack is the > existence of a shortcut for binding establishment, which is > non-legitimate, but which is not prevented either. To prevent the > attack, the shortcut must be eliminated. And this means that binding > establishment should be based on the first packet independent of whether > this is a data packet or a control packet. Right, i concur with this, the savi state must be created with the firs packet, either data or control packet (dhcp, ND) > > The residual question therefore is whether or not data packets should be > used for binding establishment in addition to control packets. There > are pros and cons for either approach: > > - The advantage of using data packets is that statically configured > addresses become straightforward to support. Hosts with statically > configured addresses cannot be expected to engage in any exchange of > control packets, so a simple method to establish a binding in this > case is based on the first data packet. > Actually, i think there are more reasons for using data packets The main reason is that DAD is not reliable. The ND packet can be lost and not make it to the SAVI device (e.g. error in the packet for instance) Let's consider the following situation: Suppose that the SAVI device receives a data packet for which source address it doens't have a binding, what does the savi device does_? does it discards the packet? It seems an overkill to me, since we are not sure what happned. In the data based approach, we create the state. Using only control packet introduces this error mode. > - The advantage of /not/ using data packets is that it becomes less > likely for hosts and SAVI devices to lose sync regarding a host's > right to use an address. A host and its connected SAVI device then > always determine such right based on the same control packets, so in > the absence of control packet loss on the link segment between the > host and the SAVI device, it is impossible for the host and the SAVI > device to have different understanding regarding the host's right to > use an address. > I don't understand this. Suppose that a host configures the address performs DAD and then goes quit for a really long time. At some point the SAVI device will discard the state for that address. The node then sends a data packet, what happnes? In this case, they are out of sync and the straight forward way to deal with this is to react upon the reception of data packets. > However, neither of these is a strong argument for or against the use of > data packets for binding establishment. IMHO there is strong case for using data packets, as described above > Statically configured addresses > could also be supported if bindings were established based on only > control packets: A SAVI device could, e.g., initiate a Duplicate > Address Detection procedure on behalf of a host when the host sends the > first data packet from a statically configured address. Loss of > synchronization between hosts and SAVI devices could, e.g., also be > resolved with the Neighbor Unreachability Detection procedure, such as > proposed in draft-bagnulo-savi-fcfs. > Right, actually this is what i was thinking as inter switch protocol to spread the state crated using data packets > I think that, in order to move forward and decide whether or not to use > data packets for binding establishment, we should also consider the > affects on SAVI solution components other than the initial binding > establishment. One such component is inter-switch mobility: Would the > re-establishment of the binding in the new switch become easier based on > data packets or control packets? Does the node needs to perform DAD when the host moves from one swithc to another? How about the removal of the binding > in the old switch? Another component is SeND support (in the SeND-based > SAVI variant): If binding establishment is exclusively based on control > packets, the use of SeND automatically protects binding establishment. > This is not the case if data packets are used to establish bindings > because SeND does not protect the source address in data packets. The SEND based savi already performs a ND query to verify address ownership. i.e. upon the reception of a data packet it forces the sender to generate a control packet, which is ok for send imho Regards, marcelo SeND > can then only protect the Neighbor Unreachability Detection procedure, > which is used for garbage collection in draft-bagnulo-savi-fcfs. > > What does the working group think about this? Please comment. > > One final, important note: Of course, the FCFS principle, the core idea > of draft-bagnulo-savi-fcfs, is orthogonal to whether or not data packets > are used for binding establishment. And based on the feedback we got at > the SAVI meeting in Minneapolis and so far on this mailing list, the > FCFS principle is by many considered the way to go. > > - Christian > > > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid From christian.vogt@ericsson.com Wed Jan 7 19:35:22 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135F23A6984 for ; Wed, 7 Jan 2009 19:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 aNe5AVNKnHTq for ; Wed, 7 Jan 2009 19:35:21 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0079E3A681F for ; Wed, 7 Jan 2009 19:35:20 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 63EFF20445; Thu, 8 Jan 2009 04:35:06 +0100 (CET) X-AuditID: c1b4fb3e-ac06abb00000429e-13-4965746a8f35 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3640B20180; Thu, 8 Jan 2009 04:35:06 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jan 2009 04:35:05 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jan 2009 04:35:04 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 435E5245F; Thu, 8 Jan 2009 05:35:05 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 532F94DA9B; Thu, 8 Jan 2009 05:35:00 +0200 (EET) Message-Id: <73F7A221-7BAE-421B-AE3F-FC76E8B01F91@ericsson.com> From: Christian Vogt To: SAVI Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 7 Jan 2009 19:34:59 -0800 X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 08 Jan 2009 03:35:04.0796 (UTC) FILETIME=[186719C0:01C97142] X-Brightmail-Tracker: AAAAAA== Cc: Ana Kukec Subject: [savi] Adopting draft-bagnulo-savi-fcfs/send 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, 08 Jan 2009 03:35:22 -0000 Folks - We had a discussion regarding the adoption of individual Internet drafts as official documents of the SAVI working group. I would like to conclude this discussion for the following two Internet drafts: - draft-bagnulo-savi-fcfs - draft-bagnulo-savi-send The feedback we got at the SAVI meeting in Minneapolis and on this mailing list shows that there is strong support for the FCFS principle, which is the baseline of both of the above Internet drafts. A couple of issues have been identified, and these will have to be addressed. But the issues are no showstoppers in my opinion. In fact, many of them apply to specific instantiations of the FCFS principle rather than to the FCFS principle itself. I have therefore decided to adopt the above Internet drafts as SAVI working group documents. Draft-bagnulo-savi-fcfs will be continued as draft-ietf-savi-fcfs with Erik Nordmark, Marcelo Bagnulo, and Fred Baker as editors. Draft-bagnulo-savi-send will be continued as draft-ietf-savi-send with Ana Kukec, Marcelo Bagnulo, Jianping Wu, and Jun Bi as editors. Of course, the documents are far from completion; there is much work ahead. And part of this work will be to address the issues that were raised during the foregoing discussion. Those are in summary: - Lack of support for pre-configured, static addresses (Frank Xia). - Possible DoS attacks where an attacker tricks a SAVI device into blocking an address that a victim host is about to configure (Guang Yao). - Possible loss of synchronizing between a host and the responsible SAVI device regarding the host's right to use an address (Guang Yao). - Need to protect target addresses in Neighbor Discovery messages similarly to source addresses in regular packets (Guang Yao). - Filtering load for switches (Lin Tao): How much load do we impose on a switch by requiring it to filter out and monitoring certain packets. - Strength of binding anchors (Dong Zhang): SAVI will work with various binding anchors of different security strength. SAVI specifications should provide guidance for selecting a binding anchor. We already decided to provide such guidance in SAVI specifications. As a starting point, I would like the current, unmodified versions of above Internet drafts to be re-submitted with their new names (draft-ietf-savi-*). Editors, please go ahead and do so. - Christian From xiayangsong@huawei.com Wed Jan 7 19:52:05 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3B913A699C for ; Wed, 7 Jan 2009 19:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YplsxRMLPNCh for ; Wed, 7 Jan 2009 19:52:04 -0800 (PST) Received: from nlpi101.prodigy.net (nlpi101.prodigy.net [207.115.36.117]) by core3.amsl.com (Postfix) with ESMTP id 9AE3E3A681F for ; Wed, 7 Jan 2009 19:52:04 -0800 (PST) X-ORBL: [70.249.158.87] Received: from X24512z (ppp-70-249-158-87.dsl.rcsntx.swbell.net [70.249.158.87]) by nlpi101.prodigy.net (8.13.8 out.ldap.dk.spool/8.13.8) with ESMTP id n083pgTB024865; Wed, 7 Jan 2009 21:51:46 -0600 Message-ID: <005d01c97144$6cfd6370$0201a8c0@china.huawei.com> From: "Frank Xia" To: "Christian Vogt" , "SAVI Mailing List" References: <73F7A221-7BAE-421B-AE3F-FC76E8B01F91@ericsson.com> Date: Wed, 7 Jan 2009 21:50:55 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: Ana Kukec Subject: Re: [savi] Adopting draft-bagnulo-savi-fcfs/send 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, 08 Jan 2009 03:52:05 -0000 Hi Christian It seems to be a little bit rush :-). I don't think people have enough time to read your previous email. For my understanding, it is hard to hard to say "STRONG" support for the FCFS principle. At least, I can not find strong support through this long discussions in the mailing list. IMHO, the decision should be based rough consensus by WG. IETF is based on mailing list. BR Frank ----- Original Message ----- From: "Christian Vogt" To: "SAVI Mailing List" Cc: "Ana Kukec" Sent: Wednesday, January 07, 2009 9:34 PM Subject: [savi] Adopting draft-bagnulo-savi-fcfs/send > Folks - > > We had a discussion regarding the adoption of individual Internet drafts > as official documents of the SAVI working group. I would like to > conclude this discussion for the following two Internet drafts: > > - draft-bagnulo-savi-fcfs > - draft-bagnulo-savi-send > > The feedback we got at the SAVI meeting in Minneapolis and on this > mailing list shows that there is strong support for the FCFS principle, > which is the baseline of both of the above Internet drafts. A couple of > issues have been identified, and these will have to be addressed. But > the issues are no showstoppers in my opinion. In fact, many of them > apply to specific instantiations of the FCFS principle rather than to > the FCFS principle itself. > > I have therefore decided to adopt the above Internet drafts as SAVI > working group documents. Draft-bagnulo-savi-fcfs will be continued > as draft-ietf-savi-fcfs with Erik Nordmark, Marcelo Bagnulo, and Fred > Baker as editors. Draft-bagnulo-savi-send will be continued > as draft-ietf-savi-send with Ana Kukec, Marcelo Bagnulo, Jianping Wu, > and Jun Bi as editors. > > Of course, the documents are far from completion; there is much work > ahead. And part of this work will be to address the issues that were > raised during the foregoing discussion. Those are in summary: > > - Lack of support for pre-configured, static addresses (Frank Xia). > > - Possible DoS attacks where an attacker tricks a SAVI device into > blocking an address that a victim host is about to configure (Guang > Yao). > > - Possible loss of synchronizing between a host and the responsible SAVI > device regarding the host's right to use an address (Guang Yao). > > - Need to protect target addresses in Neighbor Discovery messages > similarly to source addresses in regular packets (Guang Yao). > > - Filtering load for switches (Lin Tao): How much load do we impose on > a switch by requiring it to filter out and monitoring certain > packets. > > - Strength of binding anchors (Dong Zhang): SAVI will work with various > binding anchors of different security strength. SAVI specifications > should provide guidance for selecting a binding anchor. We already > decided to provide such guidance in SAVI specifications. > > As a starting point, I would like the current, unmodified versions of > above Internet drafts to be re-submitted with their new names > (draft-ietf-savi-*). Editors, please go ahead and do so. > > - Christian > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From christian.vogt@ericsson.com Wed Jan 7 19:57:20 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 176AF3A699C for ; Wed, 7 Jan 2009 19:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.191 X-Spam-Level: X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 23dbLiyVatj1 for ; Wed, 7 Jan 2009 19:57:19 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 449923A6984 for ; Wed, 7 Jan 2009 19:57:19 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 18E2820E1D; Thu, 8 Jan 2009 04:55:41 +0100 (CET) X-AuditID: c1b4fb3c-acf5cbb00000304c-1e-4965793c4726 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EA22A208AF; Thu, 8 Jan 2009 04:55:40 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jan 2009 04:55:40 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jan 2009 04:55:40 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1591B26A7; Thu, 8 Jan 2009 05:55:39 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id ED02A4DA9B; Thu, 8 Jan 2009 05:55:35 +0200 (EET) Message-Id: <93341925-0B4B-4FDB-96A3-A9D641BD98C8@ericsson.com> From: Christian Vogt To: SAVI Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 7 Jan 2009 19:55:34 -0800 X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 08 Jan 2009 03:55:40.0209 (UTC) FILETIME=[F8C42A10:01C97144] X-Brightmail-Tracker: AAAAAA== Subject: [savi] Adopting draft-mcpherson-savi-threat-scope 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, 08 Jan 2009 03:57:20 -0000 Another Internet draft we have been considering for adoption by the SAVI working group is draft-mcpherson-savi-threat-scope. The feedback we got at the SAVI meeting in Minneapolis and on this mailing list shows that there is strong support for adopting the document. Some previous reviews of the documents, including Marcelo's and mine, are yet to be addressed, but the existing Internet draft was nonetheless considered a mature starting point for a working group document. I have therefore decided to adopt draft-mcpherson-savi-threat-scope as a SAVI working group document. The Internet draft will be continued as draft-ietf-savi-threats, and the editors will be Danny McPherson and Fred Baker. I would like the current, unmodified version of the Internet draft to first be re-submitted with its new name. An immediate next version of the document should then address the reviews that were made on the document. Editors, please go ahead. - Christian From fred@cisco.com Wed Jan 7 20:19:56 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D49243A6858 for ; Wed, 7 Jan 2009 20:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.469 X-Spam-Level: X-Spam-Status: No, score=-106.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaBIkM2-MytH for ; Wed, 7 Jan 2009 20:19:55 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E2A013A684C for ; Wed, 7 Jan 2009 20:19:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,231,1231113600"; d="scan'208";a="126247874" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 08 Jan 2009 04:19:43 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n084Jgrh028810; Wed, 7 Jan 2009 20:19:42 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n084JgHY027588; Thu, 8 Jan 2009 04:19:42 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jan 2009 20:19:42 -0800 Received: from stealth-10-32-244-220.cisco.com ([10.32.244.220]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jan 2009 20:19:42 -0800 From: Fred Baker To: "Frank Xia" In-Reply-To: <005d01c97144$6cfd6370$0201a8c0@china.huawei.com> X-Priority: 3 References: <73F7A221-7BAE-421B-AE3F-FC76E8B01F91@ericsson.com> <005d01c97144$6cfd6370$0201a8c0@china.huawei.com> Message-Id: <0D1BAF98-03EC-4C93-8395-9A4069E37F93@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 7 Jan 2009 20:19:40 -0800 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 08 Jan 2009 04:19:42.0399 (UTC) FILETIME=[5460E4F0:01C97148] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3764; t=1231388383; x=1232252383; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[savi]=20Adopting=20draft-bagnulo-savi- fcfs/send |Sender:=20; bh=miu/jfTBeNF3In09lC3GkKL1yGX/uk4DSTFdEUpVKR8=; b=iRcfD33YOii+3v5uouD7UWiGnqWzqGwKM/wj/XWQaigd2XB0k89kR8EMq8 bGD0sUJPP8LYYxKIEgkumI1U3KA2yMzUho2kdPlBn8kApH+Yal1RHvEFMOko P9aeIinvRT; Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Ana Kukec , SAVI Mailing List , Christian Vogt Subject: Re: [savi] Adopting draft-bagnulo-savi-fcfs/send 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, 08 Jan 2009 04:19:56 -0000 Yes, and I thought Iheard read some dissenting reviews. Maybe those who wrote them could remind us of their concerns? On Jan 7, 2009, at 7:50 PM, Frank Xia wrote: > Hi Christian > > It seems to be a little bit rush :-). > > I don't think people have enough > time to read your previous email. > > For my understanding, it is hard > to hard to say "STRONG" support > for the FCFS principle. > At least, I can not find strong support > through this long discussions in the mailing list. > > IMHO, the decision should be based > rough consensus by WG. IETF is based > on mailing list. > BR > Frank > > ----- Original Message ----- From: "Christian Vogt" > > To: "SAVI Mailing List" > Cc: "Ana Kukec" > Sent: Wednesday, January 07, 2009 9:34 PM > Subject: [savi] Adopting draft-bagnulo-savi-fcfs/send > > >> Folks - >> We had a discussion regarding the adoption of individual Internet >> drafts >> as official documents of the SAVI working group. I would like to >> conclude this discussion for the following two Internet drafts: >> - draft-bagnulo-savi-fcfs >> - draft-bagnulo-savi-send >> The feedback we got at the SAVI meeting in Minneapolis and on this >> mailing list shows that there is strong support for the FCFS >> principle, >> which is the baseline of both of the above Internet drafts. A >> couple of >> issues have been identified, and these will have to be addressed. >> But >> the issues are no showstoppers in my opinion. In fact, many of them >> apply to specific instantiations of the FCFS principle rather than to >> the FCFS principle itself. >> I have therefore decided to adopt the above Internet drafts as SAVI >> working group documents. Draft-bagnulo-savi-fcfs will be continued >> as draft-ietf-savi-fcfs with Erik Nordmark, Marcelo Bagnulo, and Fred >> Baker as editors. Draft-bagnulo-savi-send will be continued >> as draft-ietf-savi-send with Ana Kukec, Marcelo Bagnulo, Jianping Wu, >> and Jun Bi as editors. >> Of course, the documents are far from completion; there is much work >> ahead. And part of this work will be to address the issues that were >> raised during the foregoing discussion. Those are in summary: >> - Lack of support for pre-configured, static addresses (Frank Xia). >> - Possible DoS attacks where an attacker tricks a SAVI device into >> blocking an address that a victim host is about to configure (Guang >> Yao). >> - Possible loss of synchronizing between a host and the responsible >> SAVI >> device regarding the host's right to use an address (Guang Yao). >> - Need to protect target addresses in Neighbor Discovery messages >> similarly to source addresses in regular packets (Guang Yao). >> - Filtering load for switches (Lin Tao): How much load do we >> impose on >> a switch by requiring it to filter out and monitoring certain >> packets. >> - Strength of binding anchors (Dong Zhang): SAVI will work with >> various >> binding anchors of different security strength. SAVI specifications >> should provide guidance for selecting a binding anchor. We already >> decided to provide such guidance in SAVI specifications. >> As a starting point, I would like the current, unmodified versions of >> above Internet drafts to be re-submitted with their new names >> (draft-ietf-savi-*). Editors, please go ahead and do so. >> - Christian >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From fred@cisco.com Wed Jan 7 20:20:27 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 338323A684C for ; Wed, 7 Jan 2009 20:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.471 X-Spam-Level: X-Spam-Status: No, score=-106.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIZFOcBIk+5j for ; Wed, 7 Jan 2009 20:20:26 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6CFE23A68B4 for ; Wed, 7 Jan 2009 20:20:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,231,1231113600"; d="scan'208";a="126248000" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 08 Jan 2009 04:20:13 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n084KD5d029121; Wed, 7 Jan 2009 20:20:13 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n084KDJn027939; Thu, 8 Jan 2009 04:20:13 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jan 2009 20:20:12 -0800 Received: from stealth-10-32-244-220.cisco.com ([10.32.244.220]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jan 2009 20:20:12 -0800 Message-Id: <883B8B95-B282-4A8C-9873-18E5F465FE40@cisco.com> From: Fred Baker To: Christian Vogt In-Reply-To: <93341925-0B4B-4FDB-96A3-A9D641BD98C8@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 7 Jan 2009 20:20:12 -0800 References: <93341925-0B4B-4FDB-96A3-A9D641BD98C8@ericsson.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 08 Jan 2009 04:20:12.0712 (UTC) FILETIME=[66724A80:01C97148] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=451; t=1231388413; x=1232252413; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Adopting=20draft-mcpherson-savi-threat- scope |Sender:=20; bh=0lY5/rgTG+Ar4x4M8E/wi9+EF5SBOJsBw8MzWKQ3940=; b=LVpvGs7oC/t71LfQssQTzOxuGxNfUSUQyWJTGgnC6Q2jLrKIiX/4OEUOc8 F2+WxQ+7VUkMg8Yh5igRP6OUCz6ijYpx9sqBRAC9So2MrIRleAi/Qalnrnxj QPSVEUNica; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: SAVI Mailing List Subject: Re: [savi] Adopting draft-mcpherson-savi-threat-scope 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, 08 Jan 2009 04:20:27 -0000 On Jan 7, 2009, at 7:55 PM, Christian Vogt wrote: > I have therefore decided to adopt draft-mcpherson-savi-threat-scope > as a > SAVI working group document. The Internet draft will be continued > as draft-ietf-savi-threats, and the editors will be Danny McPherson > and > Fred Baker. I would like the current, unmodified version of the > Internet draft to first be re-submitted with its new name. Works for me if the WG concurs. From christian.vogt@ericsson.com Wed Jan 7 20:22:05 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 423183A6916 for ; Wed, 7 Jan 2009 20:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 G1WoHRJoAN0A for ; Wed, 7 Jan 2009 20:22:04 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 388983A6984 for ; Wed, 7 Jan 2009 20:22:04 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E4D93204E5; Thu, 8 Jan 2009 05:21:49 +0100 (CET) X-AuditID: c1b4fb3c-ae75fbb00000304c-35-49657f5d2a01 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B8B982046E; Thu, 8 Jan 2009 05:21:49 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jan 2009 05:21:49 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jan 2009 05:21:49 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D6643245F; Thu, 8 Jan 2009 06:21:48 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A8BDC4DA9B; Thu, 8 Jan 2009 06:21:44 +0200 (EET) From: Christian Vogt To: Frank Xia In-Reply-To: <005d01c97144$6cfd6370$0201a8c0@china.huawei.com> X-Priority: 3 References: <73F7A221-7BAE-421B-AE3F-FC76E8B01F91@ericsson.com> <005d01c97144$6cfd6370$0201a8c0@china.huawei.com> Message-Id: <8D6CDB28-19A3-4C6E-BFCF-364F7B41E72B@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 7 Jan 2009 20:21:42 -0800 X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 08 Jan 2009 04:21:49.0187 (UTC) FILETIME=[9FF33530:01C97148] X-Brightmail-Tracker: AAAAAA== Cc: SAVI Mailing List , Ana Kukec Subject: Re: [savi] Adopting draft-bagnulo-savi-fcfs/send 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, 08 Jan 2009 04:22:05 -0000 Frank - As I assured in my earlier email, those issues that have been raised are valid and will certainly have to be addressed. This includes your comment regarding the support for pre-configured addresses, as well as the question of whether binding establishment should be based on control or data packets, which I summarized in the email you are referring to. But the issues raised do not render the FCFS principle inappropriate for working group adoption. On the contrary, based on the feedback from the working group and the discussions I had with working group participants, I am very positive that there is in fact strong support for the FCFS principle. Hence the adoption of draft-bagnulo-savi-fcfs/send. - Christian On Jan 7, 2009, Frank Xia wrote: > Hi Christian > > It seems to be a little bit rush :-). > > I don't think people have enough > time to read your previous email. > > For my understanding, it is hard > to hard to say "STRONG" support > for the FCFS principle. > At least, I can not find strong support > through this long discussions in the mailing list. > > IMHO, the decision should be based > rough consensus by WG. IETF is based > on mailing list. > BR > Frank From christian.vogt@ericsson.com Wed Jan 7 20:31: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 39F703A684C for ; Wed, 7 Jan 2009 20:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.196 X-Spam-Level: X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 A1jVnYzbZmSo for ; Wed, 7 Jan 2009 20:31:56 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6CBF53A6827 for ; Wed, 7 Jan 2009 20:31:56 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D33A320A06; Thu, 8 Jan 2009 05:31:41 +0100 (CET) X-AuditID: c1b4fb3c-aa757bb00000304c-2c-496581ad83db Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9D14C208AF; Thu, 8 Jan 2009 05:31:41 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jan 2009 05:31:41 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jan 2009 05:31:41 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id DCABE245F; Thu, 8 Jan 2009 06:31:40 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A01A04DA9B; Thu, 8 Jan 2009 06:31:37 +0200 (EET) Message-Id: From: Christian Vogt To: SAVI Mailing List In-Reply-To: <73F7A221-7BAE-421B-AE3F-FC76E8B01F91@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 7 Jan 2009 20:31:36 -0800 References: <73F7A221-7BAE-421B-AE3F-FC76E8B01F91@ericsson.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 08 Jan 2009 04:31:41.0170 (UTC) FILETIME=[00CCA520:01C9714A] X-Brightmail-Tracker: AAAAAA== Cc: Ana Kukec Subject: Re: [savi] Adopting draft-bagnulo-savi-fcfs/send 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, 08 Jan 2009 04:31:57 -0000 Christian Vogt wrote: > I have therefore decided to adopt the above Internet drafts as SAVI > working group documents. Draft-bagnulo-savi-fcfs will be continued > as draft-ietf-savi-fcfs with Erik Nordmark, Marcelo Bagnulo, and Fred > Baker as editors. [...] This requires some clarification given that the SAVI working group was chartered to produce separate documents for IPv4 and IPv6 solutions: For the sake of simplicity, I suggest to start with a joint IPv4/IPv6 solution document, and to split this into two, IP-version-specific documents once we consider this useful. At this point, the IPv4 and IPv6 solutions are sufficiently similar to justify a joint document. - Christian From christian.vogt@ericsson.com Wed Jan 7 20:40:01 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06A153A681F for ; Wed, 7 Jan 2009 20:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.198 X-Spam-Level: X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 F3XDqK3Dlm9T for ; Wed, 7 Jan 2009 20:40:00 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2DB143A67B3 for ; Wed, 7 Jan 2009 20:39:59 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7337C208AF; Thu, 8 Jan 2009 05:39:45 +0100 (CET) X-AuditID: c1b4fb3c-abf5abb00000304c-a7-496583914620 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 558BA20619; Thu, 8 Jan 2009 05:39:45 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jan 2009 05:39:45 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jan 2009 05:39:44 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 99FC4245F; Thu, 8 Jan 2009 06:39:44 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7D06A4DA9B; Thu, 8 Jan 2009 06:39:43 +0200 (EET) Message-Id: From: Christian Vogt To: David Harrington , SAVI Mailing List In-Reply-To: <004301c965fb$5ef7bae0$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 7 Jan 2009 20:39:42 -0800 References: <00b001c96548$b6806bd0$0600a8c0@china.huawei.com> <20081224020122.p8webzgwgck8o4ok@webcartero01.uc3m.es> <004301c965fb$5ef7bae0$0600a8c0@china.huawei.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 08 Jan 2009 04:39:44.0791 (UTC) FILETIME=[210F5A70:01C9714B] X-Brightmail-Tracker: AAAAAA== Subject: [savi] Extended review deadline for draft-vogt-savi-rationale 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, 08 Jan 2009 04:40:01 -0000 David and all - > I also did not find draft-vogt-savi-rationale in the ID repository. You are right; I forgot to provide a link to Internet draft draft-vogt-savi-rationale. Even though Marcelo kindly did this for me, we should extend the review deadline for this draft. Please provide your feedback until Wednesday, Jan. 14, regarding the adoption of draft-vogt-savi-rationale as a SAVI working group document. Again, you find draft-vogt-savi-rationale under the following link. The draft should also appear soon in the official IETF repositories. http://users.piuha.net/chvogt/pub/2008/draft-vogt-savi-rationale-00.txt - Christian From xiayangsong@huawei.com Wed Jan 7 20:49:45 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55EEA3A6984 for ; Wed, 7 Jan 2009 20:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2pTFrKArSQf for ; Wed, 7 Jan 2009 20:49:44 -0800 (PST) Received: from nlpi101.prodigy.net (nlpi101.prodigy.net [207.115.36.117]) by core3.amsl.com (Postfix) with ESMTP id 7ADBF3A681F for ; Wed, 7 Jan 2009 20:49:44 -0800 (PST) X-ORBL: [70.249.158.87] Received: from X24512z (ppp-70-249-158-87.dsl.rcsntx.swbell.net [70.249.158.87]) by nlpi101.prodigy.net (8.13.8 out.ldap.dk.spool/8.13.8) with ESMTP id n084nLbb030976; Wed, 7 Jan 2009 22:49:27 -0600 Message-ID: <014201c9714c$7bc43840$0201a8c0@china.huawei.com> From: "Frank Xia" To: "Christian Vogt" , "Fred Baker" References: <73F7A221-7BAE-421B-AE3F-FC76E8B01F91@ericsson.com> <005d01c97144$6cfd6370$0201a8c0@china.huawei.com> <8D6CDB28-19A3-4C6E-BFCF-364F7B41E72B@ericsson.com> Date: Wed, 7 Jan 2009 22:49:20 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: Ana Kukec , SAVI Mailing List Subject: Re: [savi] Adopting draft-bagnulo-savi-fcfs/send 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, 08 Jan 2009 04:49:45 -0000 Hi Christian and Fred Thank Christian did a very good job! Just as Christian's email listed, there are 6 issues need to be discussed and studied. IMHO, some solutions of these issues probably are beyond capability of FCFS. I think it is not necessary to have a conclusion before initiating any discussion. I would also like to quote the email which says "Marcelo and Guang had an interesting discussion on whether FCFS SAVI should establish bindings based on data packets or based on control packets" I think this is disagreement on some principles. From my technical perspective, data plan learning and control plan snooping are totally different methods. BR Frank ----- Original Message ----- From: "Christian Vogt" To: "Frank Xia" Cc: "SAVI Mailing List" ; "Ana Kukec" Sent: Wednesday, January 07, 2009 10:21 PM Subject: Re: [savi] Adopting draft-bagnulo-savi-fcfs/send > Frank - > > As I assured in my earlier email, those issues that have been raised are > valid and will certainly have to be addressed. This includes your > comment regarding the support for pre-configured addresses, as well as > the question of whether binding establishment should be based on control > or data packets, which I summarized in the email you are referring to. > But the issues raised do not render the FCFS principle inappropriate for > working group adoption. On the contrary, based on the feedback from the > working group and the discussions I had with working group participants, > I am very positive that there is in fact strong support for the FCFS > principle. Hence the adoption of draft-bagnulo-savi-fcfs/send. > > - Christian > > > > On Jan 7, 2009, Frank Xia wrote: > >> Hi Christian >> >> It seems to be a little bit rush :-). >> >> I don't think people have enough >> time to read your previous email. >> >> For my understanding, it is hard >> to hard to say "STRONG" support >> for the FCFS principle. >> At least, I can not find strong support >> through this long discussions in the mailing list. >> >> IMHO, the decision should be based >> rough consensus by WG. IETF is based >> on mailing list. >> BR >> Frank > > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From xiayangsong@huawei.com Wed Jan 7 20:58:08 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF7263A6A6D for ; Wed, 7 Jan 2009 20:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGuiVQc9eYPk for ; Wed, 7 Jan 2009 20:58:08 -0800 (PST) Received: from nlpi087.prodigy.net (nlpi087.prodigy.net [207.115.36.103]) by core3.amsl.com (Postfix) with ESMTP id D25373A67AA for ; Wed, 7 Jan 2009 20:58:07 -0800 (PST) X-ORBL: [70.249.158.87] Received: from X24512z (ppp-70-249-158-87.dsl.rcsntx.swbell.net [70.249.158.87]) by nlpi087.prodigy.net (8.13.8 out.ldap.dk.spool/8.13.8) with ESMTP id n084vaxo020381; Wed, 7 Jan 2009 22:57:43 -0600 Message-ID: <014d01c9714d$a32e97d0$0201a8c0@china.huawei.com> From: "Frank Xia" To: "Christian Vogt" References: <73F7A221-7BAE-421B-AE3F-FC76E8B01F91@ericsson.com> <005d01c97144$6cfd6370$0201a8c0@china.huawei.com> <8D6CDB28-19A3-4C6E-BFCF-364F7B41E72B@ericsson.com> Date: Wed, 7 Jan 2009 22:57:35 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: SAVI Mailing List , Ana Kukec Subject: Re: [savi] Adopting draft-bagnulo-savi-fcfs/send 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, 08 Jan 2009 04:58:08 -0000 Hi Christian A little bit curious :). Why are you VERY POSITIVE? Have you any proof beyond SAVI mailing list? Probably, you can just do a simple poll, and IMO it looks more convincing :-). BR Frank ----- Original Message ----- From: "Christian Vogt" To: "Frank Xia" Cc: "Fred Baker" ; "Erik Nordmark" ; "Marcelo Bagnulo Braun" ; "Jianping Wu" ; "Jun Bi" ; "Ana Kukec" ; "Bill Fenner" ; "SAVI Mailing List" Sent: Wednesday, January 07, 2009 10:21 PM Subject: Re: [savi] Adopting draft-bagnulo-savi-fcfs/send > Frank - > > As I assured in my earlier email, those issues that have been raised are > valid and will certainly have to be addressed. This includes your > comment regarding the support for pre-configured addresses, as well as > the question of whether binding establishment should be based on control > or data packets, which I summarized in the email you are referring to. > But the issues raised do not render the FCFS principle inappropriate for > working group adoption. On the contrary, based on the feedback from the > working group and the discussions I had with working group participants, > I am very positive that there is in fact strong support for the FCFS > principle. Hence the adoption of draft-bagnulo-savi-fcfs/send. > > - Christian > > > > On Jan 7, 2009, Frank Xia wrote: > >> Hi Christian >> >> It seems to be a little bit rush :-). >> >> I don't think people have enough >> time to read your previous email. >> >> For my understanding, it is hard >> to hard to say "STRONG" support >> for the FCFS principle. >> At least, I can not find strong support >> through this long discussions in the mailing list. >> >> IMHO, the decision should be based >> rough consensus by WG. IETF is based >> on mailing list. >> BR >> Frank > > > > From marcelo@it.uc3m.es Thu Jan 8 05:23:45 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BD4228C0F4 for ; Thu, 8 Jan 2009 05:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.551 X-Spam-Level: X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[AWL=3.211, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 qQUPrPP93ah4 for ; Thu, 8 Jan 2009 05:23:44 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id EF6BA3A6AB4 for ; Thu, 8 Jan 2009 05:23:43 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [200.40.4.129])by smtp03.uc3m.es (Postfix) with ESMTP id 3715272B69D;Thu, 8 Jan 2009 14:23:23 +0100 (CET) Message-ID: <4965F346.4050900@it.uc3m.es> Date: Thu, 08 Jan 2009 13:36:22 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Frank Xia References: <73F7A221-7BAE-421B-AE3F-FC76E8B01F91@ericsson.com> <005d01c97144$6cfd6370$0201a8c0@china.huawei.com> In-Reply-To: <005d01c97144$6cfd6370$0201a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-19.9380 TC:1F TRN:72 TV:5.5.1026(16388.006) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Ana Kukec , SAVI Mailing List , Christian Vogt Subject: Re: [savi] Adopting draft-bagnulo-savi-fcfs/send 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, 08 Jan 2009 13:23:45 -0000 Hi Frank, I am a bit puzzled by you mail. During consensus call for adopting the FCFS draft as a WG item, you explicitly stated that you were not against FCFS as well. You raised a set of issues in your mail from 18 of dec, namely: >It seems to be hard to deal with the following scenarios: >1)A host is authorized to use a static address, while > the host does not connect the network >2)A IPv6 host periodically changes it's interface ID > from privacy consideration. >3)In dynamic address configuration, an IP address > can be reused by other hosts. I answer to each of these points in a follow up email in the same date answering some of the issues and asking for calrification on others, but you never answered back So either you agree with me and you feel the issues can be solved as i suggested or you should anser soemthing back. IETF work on rough consensus, which is build on disucssions. Saying that you don't like something and not describing why this is so it is hardly a good way to make progress. I don't think it is ok not to reply for weeks and then simply restate that you don't like something with no arguments. Regards, marcelo Frank Xia escribió: > Hi Christian > > It seems to be a little bit rush :-). > > I don't think people have enough > time to read your previous email. > > For my understanding, it is hard > to hard to say "STRONG" support > for the FCFS principle. > At least, I can not find strong support > through this long discussions in the mailing list. > > IMHO, the decision should be based > rough consensus by WG. IETF is based > on mailing list. > BR > Frank > > ----- Original Message ----- From: "Christian Vogt" > > To: "SAVI Mailing List" > Cc: "Ana Kukec" > Sent: Wednesday, January 07, 2009 9:34 PM > Subject: [savi] Adopting draft-bagnulo-savi-fcfs/send > > >> Folks - >> >> We had a discussion regarding the adoption of individual Internet drafts >> as official documents of the SAVI working group. I would like to >> conclude this discussion for the following two Internet drafts: >> >> - draft-bagnulo-savi-fcfs >> - draft-bagnulo-savi-send >> >> The feedback we got at the SAVI meeting in Minneapolis and on this >> mailing list shows that there is strong support for the FCFS principle, >> which is the baseline of both of the above Internet drafts. A couple of >> issues have been identified, and these will have to be addressed. But >> the issues are no showstoppers in my opinion. In fact, many of them >> apply to specific instantiations of the FCFS principle rather than to >> the FCFS principle itself. >> >> I have therefore decided to adopt the above Internet drafts as SAVI >> working group documents. Draft-bagnulo-savi-fcfs will be continued >> as draft-ietf-savi-fcfs with Erik Nordmark, Marcelo Bagnulo, and Fred >> Baker as editors. Draft-bagnulo-savi-send will be continued >> as draft-ietf-savi-send with Ana Kukec, Marcelo Bagnulo, Jianping Wu, >> and Jun Bi as editors. >> >> Of course, the documents are far from completion; there is much work >> ahead. And part of this work will be to address the issues that were >> raised during the foregoing discussion. Those are in summary: >> >> - Lack of support for pre-configured, static addresses (Frank Xia). >> >> - Possible DoS attacks where an attacker tricks a SAVI device into >> blocking an address that a victim host is about to configure (Guang >> Yao). >> >> - Possible loss of synchronizing between a host and the responsible SAVI >> device regarding the host's right to use an address (Guang Yao). >> >> - Need to protect target addresses in Neighbor Discovery messages >> similarly to source addresses in regular packets (Guang Yao). >> >> - Filtering load for switches (Lin Tao): How much load do we impose on >> a switch by requiring it to filter out and monitoring certain >> packets. >> >> - Strength of binding anchors (Dong Zhang): SAVI will work with various >> binding anchors of different security strength. SAVI specifications >> should provide guidance for selecting a binding anchor. We already >> decided to provide such guidance in SAVI specifications. >> >> As a starting point, I would like the current, unmodified versions of >> above Internet drafts to be re-submitted with their new names >> (draft-ietf-savi-*). Editors, please go ahead and do so. >> >> - Christian >> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From marcelo@it.uc3m.es Thu Jan 8 05:23: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 5A79D3A6AF5 for ; Thu, 8 Jan 2009 05:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.755 X-Spam-Level: ** X-Spam-Status: No, score=2.755 tagged_above=-999 required=5 tests=[AWL=-1.378, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 c4QMUaRRTMKW for ; Thu, 8 Jan 2009 05:23:54 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id CC35E28C0F4 for ; Thu, 8 Jan 2009 05:23:53 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [200.40.4.129])by smtp03.uc3m.es (Postfix) with ESMTP id C4ADB72B69D;Thu, 8 Jan 2009 14:23:32 +0100 (CET) Message-ID: <4965FC0F.60103@it.uc3m.es> Date: Thu, 08 Jan 2009 14:13:51 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Guang Yao References: <005901c96128$ea3185f0$420c7c0a@china.huawei.com> <494AA050.2060300@it.uc3m.es> <7141029F-A8F2-4892-977A-BFF510A405B7@ericsson.com> <002601c9641a$a6446fc0$2211990a@h3c.huawei3com.com> <60D2E2DD-9815-4374-9A48-EC646396198E@ericsson.com> <008901c964f7$ca10ad00$5e320700$@tsinghua.edu.cn> <4957CF87.9050601@it.uc3m.es> <001001c96973$3b508ce0$b1f1a6a0$@tsinghua.edu.cn> <49590EF6.4080407@it.uc3m.es> <001201c96a4f$8dc3cd70$a94b6850$@tsinghua.edu.cn> <495A300F.3090401@it.uc3m.es> <001e01c96e71$c31d7fe0$49587fa0$@tsinghua.edu.cn> In-Reply-To: <001e01c96e71$c31d7fe0$49587fa0$@tsinghua.edu.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-19.6621 TC:1F TRN:78 TV:5.5.1026(16388.006) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: 'Lin Tao' , 'SAVI Mailing List' , 'Christian Vogt' , 'Frank Xia' Subject: Re: [savi] =?gb2312?b?tPC4tDogtPC4tDogtPC4tDogtPC4tDogIFdvcmtpbmcg?= =?gb2312?b?R3JvdXAgQWRvcHRpb24gb2YgSW5kaXZpZHVhbCBTQVZJIERvY3Vt?= =?gb2312?b?ZW50cw==?= 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, 08 Jan 2009 13:23:55 -0000 I think i have missed this one... see below... Guang Yao escribi¨®: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~Guang, 1.4: > ~Yes, I agree it's not perfect. However, we can compare the failure > possibility of DAD snooping > ~and FCFS(false positive only): > ~1. FCFS fails if (1.1) normal DAD is being attacked; > ~ (1.2) DAD NA is missing; > ~ (1.3)Collision you mentioned > ~2. DAD snooping fails when (2.1) DAD NA is missing > ~ (2.2) Collision you mentioned > ~ > ~I think it is quite clear (1.2),(1.3) ,(2.1),(2.2) happen with very little > possibility, but (1.1) > ~can happen with great possibility. > ~And (1.2),(1.3) ,(2.1),(2.2) is the failure of DAD mechanism, not the fault > of SAVI. (1.1) is > ~the fault of SAVI. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > I simply don't agree with he way you compare the approaches For me, it makes sense to create the FCFS SAVI state based on the first packet that refers tot he soruce address, whether this packet is ND, dhcp or a data packet. So, the only disucssion we are having here is that i think we should use both data packets and control packets and you argue that you want to use only DAD packets. So, what we need to compare is FCFS SAVI using both control and data packets versus doing FCFS SAVI based only in DAD packets. In that case, it is clear that there are more failure modes that fail in the case of using only control packets, since it is a subset of the other that uses both control and data packets. Now, this is not enough to also use data packets, since we need to quantify if it is worth the additional complexity. the problems that is see with using only DAD packets are: - first, i don't think this flies for IPv4, since i would assume that DAD for v4 is not widely implemented. So for IPv4 we must use soemthing else. (in this case, i wonder if it is worth the complexity of using DAD, but this depends on how widely IPv4 DAD has been adopted) - second, even for IPv6, what would you do if you are only doing DAD and you receive a data apcket with a soruce address that is not in the SAVI data base? you would drop it? This means that if the DAD msg was corrupted, or lost or whatever, you are blocking a legitimate user, and as you say, false positives are very bad. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~Guang, 1.4: > ~SAVI device is always the device directly connected with the host(first hop > switch or router). > why? > ~So it is not hard to guarantee the first point. > what is the first point? > ~And I don't think we have to guarantee ND message is delivered to all > nodes. It is enforced > ~by standard and it only fails with little possibility. > agree, but if it fails, you have a false positive, which as you said is very bad. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > I mean, the problem with DAD robustness is that the topology can change > after the DAD procedure was done. So, suppose you have two lans that are > working and that at some point in time they are merged into one lan. In > that case, the nodes on each lan have already executed the DAD procedure > and they are not even aware of the merging, so they will not repeat the > DAD procedure. (this can happne when there is a failure and a network > gets partitioned and then repaired for example) > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~Guang, 1.4: > ~A great example. But > ~(1) If the nodes are not aware of merging, they must not leave their switch > right, but what i have in mind is that there are two switches connected to each other and each switch is performing the SAVI function. So, what breaks is the link between the two switches. So, the DAD msg is propagated but only to the node in the same switch. When the two switches are linked togheter again, the SAVI function of the other switch has not seen the DAD mesages in the other switch that were sent during they were separated > (or else it is the same > ~as a node is attached to the LAN for the first time.) and the switch must > be used in the new LAN. If > ~the binding is performed on the switch, there is no trouble. If the binding > is performed on the router, > ~also no trouble. wait, you said before that SAVI is performed in the first hop? So are you assuming that the savi is performed in the first hop or not? I don't think it is a reasomnable assumption to make, but you seem to contradict yourself here. > The binding information is always not removed and it can > be used again, without requirement > ~of another DAD. > ~(2) It is really an infrequent situation. > well, all the mechanimss for the creation of adjacencies in OSPF are intended to address problems like this when a network gets partitioned and these are pretty complex... i don't think they would do all that work if they thought the probablitly of such even was negligible > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > So DAD is inherently non robust cause the procedure is successful when > there is NO reply, but you cannot know if there is no reply cause there > is no address collision or because the packet was lost. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~Guang, 1.4: > ~(1) The SAVI device knows what the situation is clearly, because it has > recorded all addresses but DAD messages can get lost or have errors, right? My point is what happens in that situation? SAVI just starts droping the packets and blocks the host out of the network cause the DAD msg was lost? As you said, false positives are very bad. > . > ~(2) And my point is: We choose DAD snooping for host relies on DAD > exclusively, rather than > ~DAD is robust. > I can't parse this sentence > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >> But I think relying on data traffic has the >> same problem, right? >> >> >> > not really, cause there are many data packets. > So, if one data packet gets lost, there will be more to come, so sooner > or later one of them will make it (or we have bigger problems) > > The problem with DAD is that we send only one packet and if it is lost > we are out of luck. > BEsides, we could send several packets, but this would imply longer > delay, whcih is also bad. > Data pakcet otoh, there are plenty of them, so the problem is handled better > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~Guang, 1.4: > ~Well, I wonder will DAD message be dropped at the first link? I remember > link layer protocol > ~has acknowledgement and retransmission policy. > messages can get errors, lost in the hardware interface and so on... Are you assuming that links don't have errors in packets? > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > as i said several times, i thin it may be ok to use ND messages to > populate the SAVI DB, but i don't think we should rely solely on ND. I > think we need to use data packets as well, in case DAD packets are > missing for soem reason > BTW, i also think we should use dhcp messages if we can > > I think we need to understnad what do we gain by adding this complexity > (clearly relying solely on dat packets is simpler, but relying on > signaling packets as well may prevent som attacks, but we need to > understadn that better imho) > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~Guang, 1.4: > ~OK, I will make clear WHAT we lose if we use data packet solely. > I am not arguing we should only rely on data packets, My point is that we should create the FCFS state based on the first apcket referring that address, whether data or control packet We may want to disregard some control packets if they are not widely used, in particular i have some doubts w.r.t. IPv4 DAD as i am not sure how widely deployed this is. > >> 1.2 If there is a collision in local binding, and a DAD NA is >> replied from the address owner, it must >> ensure the NA will be delivered to the tentative node. >> >> > sure, this is basic DAD behaviour, nothing new here, right? > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~Guang, 1.4: > ~Yes. If every NA is delivered to the tentative node, the SAVI device > doesn't have to do anything here. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >> 1.3 If the address owner doesn't reply, it may either: 1, delete >> former binding and set up new binding; >> or 2 Send a NA to the tentative node instead of the address >> owner. >> >> > sure, this is done already in the FCFS draft, > > > >> 1.4 Any NA with spoofed Target Address must be dropped. >> 2 Data traffic is either dropped or forwarded according to binding, >> > without > >> triggering new binding entry. >> >> >> > here, i disagree > as i said, i think we should also use data traffic as well > > >> I think the security and completeness of DAD is necessary even using data >> traffic to bind address. >> >> > how do you plan to achieve that? > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~Guang, 1.4: > ~The security problem of DAD is easy to handle since the SAVI device has > recorded all the addresses > ~a node owns. No, you are assuming packet don't get lost and netowrks don't get partitioned This is simply not true Regards, marcelo From marcelo@it.uc3m.es Thu Jan 8 05:24:06 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E7CA28C105 for ; Thu, 8 Jan 2009 05:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.963 X-Spam-Level: X-Spam-Status: No, score=-0.963 tagged_above=-999 required=5 tests=[AWL=2.799, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 ZoDslLlEoKlt for ; Thu, 8 Jan 2009 05:24:05 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id DC2A128C101 for ; Thu, 8 Jan 2009 05:24:04 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [200.40.4.129])by smtp02.uc3m.es (Postfix) with ESMTP id BDF1365397D;Thu, 8 Jan 2009 14:23:43 +0100 (CET) Message-ID: <4965FD39.8010006@it.uc3m.es> Date: Thu, 08 Jan 2009 14:18:49 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Frank Xia References: <73F7A221-7BAE-421B-AE3F-FC76E8B01F91@ericsson.com> <005d01c97144$6cfd6370$0201a8c0@china.huawei.com> <8D6CDB28-19A3-4C6E-BFCF-364F7B41E72B@ericsson.com> <014d01c9714d$a32e97d0$0201a8c0@china.huawei.com> In-Reply-To: <014d01c9714d$a32e97d0$0201a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-24.1608 TC:1F TRN:47 TV:5.5.1026(16388.006) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: SAVI Mailing List , Christian Vogt , Ana Kukec Subject: Re: [savi] Adopting draft-bagnulo-savi-fcfs/send 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, 08 Jan 2009 13:24:06 -0000 Frank, could you please point out who disagreed with the FCFS principle for creating SAVI state? The disucssion so far was whether we use data packets and/or control packets for this, but it is always FCFS. My understanding of the situation is that the current draft only uses data packets and Guang has raised the issue (that i understnad actually was Fred who brought this up) that some attacks can be launched between the DAD and the first data packet I agreed and i am ok with using ND packets as well to create state (at least for IPv6, not clear about IPv4 though). Moreover, i also think we should use dhcp messages So, i don't see too much controversy here, but that we are converging to something. Regards, marcelo Frank Xia escribió: > Hi Christian > > A little bit curious :). > > Why are you VERY POSITIVE? > Have you any proof beyond SAVI mailing list? > > Probably, you can just do a simple poll, > and IMO it looks more convincing :-). > > BR > Frank > > ----- Original Message ----- From: "Christian Vogt" > > To: "Frank Xia" > Cc: "Fred Baker" ; "Erik Nordmark" > ; "Marcelo Bagnulo Braun" ; > "Jianping Wu" ; "Jun Bi" > ; "Ana Kukec" ; "Bill Fenner" > ; "SAVI Mailing List" > Sent: Wednesday, January 07, 2009 10:21 PM > Subject: Re: [savi] Adopting draft-bagnulo-savi-fcfs/send > > >> Frank - >> >> As I assured in my earlier email, those issues that have been raised are >> valid and will certainly have to be addressed. This includes your >> comment regarding the support for pre-configured addresses, as well as >> the question of whether binding establishment should be based on control >> or data packets, which I summarized in the email you are referring to. >> But the issues raised do not render the FCFS principle inappropriate for >> working group adoption. On the contrary, based on the feedback from the >> working group and the discussions I had with working group participants, >> I am very positive that there is in fact strong support for the FCFS >> principle. Hence the adoption of draft-bagnulo-savi-fcfs/send. >> >> - Christian >> >> >> >> On Jan 7, 2009, Frank Xia wrote: >> >>> Hi Christian >>> >>> It seems to be a little bit rush :-). >>> >>> I don't think people have enough >>> time to read your previous email. >>> >>> For my understanding, it is hard >>> to hard to say "STRONG" support >>> for the FCFS principle. >>> At least, I can not find strong support >>> through this long discussions in the mailing list. >>> >>> IMHO, the decision should be based >>> rough consensus by WG. IETF is based >>> on mailing list. >>> BR >>> Frank >> >> >> >> > > > From xiayangsong@huawei.com Thu Jan 8 06:23:11 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 D570A3A6862 for ; Thu, 8 Jan 2009 06:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjeQzK2uSeHW for ; Thu, 8 Jan 2009 06:23:07 -0800 (PST) Received: from nlpi101.prodigy.net (nlpi101.prodigy.net [207.115.36.117]) by core3.amsl.com (Postfix) with ESMTP id 862743A6859 for ; Thu, 8 Jan 2009 06:23:07 -0800 (PST) X-ORBL: [70.244.161.148] Received: from X24512z (ppp-70-244-161-148.dsl.rcsntx.swbell.net [70.244.161.148]) by nlpi101.prodigy.net (8.13.8 out.ldap.dk.spool/8.13.8) with ESMTP id n08EMbk8027713; Thu, 8 Jan 2009 08:22:42 -0600 Message-ID: <002801c9719c$909b6630$0201a8c0@china.huawei.com> From: "Frank Xia" To: "marcelo bagnulo braun" References: <73F7A221-7BAE-421B-AE3F-FC76E8B01F91@ericsson.com> <005d01c97144$6cfd6370$0201a8c0@china.huawei.com> <4965F346.4050900@it.uc3m.es> Date: Thu, 8 Jan 2009 08:22:36 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: Ana Kukec , SAVI Mailing List , Christian Vogt Subject: Re: [savi] Adopting draft-bagnulo-savi-fcfs/send 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, 08 Jan 2009 14:23:11 -0000 Hi Marcelo I am sorry for the ignorance because of my absence of SAVI work recently. Anyway, these days are holiday :-) I would like to prioritize SAVI work in next few days. BR Frank ----- Original Message ----- From: "marcelo bagnulo braun" To: "Frank Xia" Cc: "Christian Vogt" ; "SAVI Mailing List" ; "Ana Kukec" Sent: Thursday, January 08, 2009 6:36 AM Subject: Re: [savi] Adopting draft-bagnulo-savi-fcfs/send > Hi Frank, > > I am a bit puzzled by you mail. > > During consensus call for adopting the FCFS draft as a WG item, you > explicitly stated that you were not against FCFS as well. > You raised a set of issues in your mail from 18 of dec, namely: > > > >It seems to be hard to deal with the following scenarios: > >1)A host is authorized to use a static address, while > > the host does not connect the network > >2)A IPv6 host periodically changes it's interface ID > > from privacy consideration. > >3)In dynamic address configuration, an IP address > > can be reused by other hosts. > > I answer to each of these points in a follow up email in the same date > answering some of the issues and asking for calrification on others, but > you never answered back > > So either you agree with me and you feel the issues can be solved as i > suggested or you should anser soemthing back. IETF work on rough > consensus, which is build on disucssions. Saying that you don't like > something and not describing why this is so it is hardly a good way to > make progress. I don't think it is ok not to reply for weeks and then > simply restate that you don't like something with no arguments. > > Regards, marcelo > > > Frank Xia escribió: >> Hi Christian >> >> It seems to be a little bit rush :-). >> >> I don't think people have enough >> time to read your previous email. >> >> For my understanding, it is hard >> to hard to say "STRONG" support >> for the FCFS principle. >> At least, I can not find strong support >> through this long discussions in the mailing list. >> >> IMHO, the decision should be based >> rough consensus by WG. IETF is based >> on mailing list. >> BR >> Frank >> >> ----- Original Message ----- From: "Christian Vogt" >> >> To: "SAVI Mailing List" >> Cc: "Ana Kukec" >> Sent: Wednesday, January 07, 2009 9:34 PM >> Subject: [savi] Adopting draft-bagnulo-savi-fcfs/send >> >> >>> Folks - >>> >>> We had a discussion regarding the adoption of individual Internet drafts >>> as official documents of the SAVI working group. I would like to >>> conclude this discussion for the following two Internet drafts: >>> >>> - draft-bagnulo-savi-fcfs >>> - draft-bagnulo-savi-send >>> >>> The feedback we got at the SAVI meeting in Minneapolis and on this >>> mailing list shows that there is strong support for the FCFS principle, >>> which is the baseline of both of the above Internet drafts. A couple of >>> issues have been identified, and these will have to be addressed. But >>> the issues are no showstoppers in my opinion. In fact, many of them >>> apply to specific instantiations of the FCFS principle rather than to >>> the FCFS principle itself. >>> >>> I have therefore decided to adopt the above Internet drafts as SAVI >>> working group documents. Draft-bagnulo-savi-fcfs will be continued >>> as draft-ietf-savi-fcfs with Erik Nordmark, Marcelo Bagnulo, and Fred >>> Baker as editors. Draft-bagnulo-savi-send will be continued >>> as draft-ietf-savi-send with Ana Kukec, Marcelo Bagnulo, Jianping Wu, >>> and Jun Bi as editors. >>> >>> Of course, the documents are far from completion; there is much work >>> ahead. And part of this work will be to address the issues that were >>> raised during the foregoing discussion. Those are in summary: >>> >>> - Lack of support for pre-configured, static addresses (Frank Xia). >>> >>> - Possible DoS attacks where an attacker tricks a SAVI device into >>> blocking an address that a victim host is about to configure (Guang >>> Yao). >>> >>> - Possible loss of synchronizing between a host and the responsible SAVI >>> device regarding the host's right to use an address (Guang Yao). >>> >>> - Need to protect target addresses in Neighbor Discovery messages >>> similarly to source addresses in regular packets (Guang Yao). >>> >>> - Filtering load for switches (Lin Tao): How much load do we impose on >>> a switch by requiring it to filter out and monitoring certain >>> packets. >>> >>> - Strength of binding anchors (Dong Zhang): SAVI will work with various >>> binding anchors of different security strength. SAVI specifications >>> should provide guidance for selecting a binding anchor. We already >>> decided to provide such guidance in SAVI specifications. >>> >>> As a starting point, I would like the current, unmodified versions of >>> above Internet drafts to be re-submitted with their new names >>> (draft-ietf-savi-*). Editors, please go ahead and do so. >>> >>> - Christian >>> >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > > > From xiayangsong@huawei.com Thu Jan 8 07: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 88DAC3A68D6 for ; Thu, 8 Jan 2009 07:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovKFb2pZtciz for ; Thu, 8 Jan 2009 07:24:12 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 6326D3A68BD for ; Thu, 8 Jan 2009 07:24:12 -0800 (PST) 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 <0KD500KYFS3XXX@usaga02-in.huawei.com> for savi@ietf.org; Thu, 08 Jan 2009 07:23:58 -0800 (PST) Received: from X24512z ([10.124.12.66]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KD500HNUS3JP2@usaga02-in.huawei.com> for savi@ietf.org; Thu, 08 Jan 2009 07:23:57 -0800 (PST) Date: Thu, 08 Jan 2009 09:22:51 -0600 From: Frank Xia To: marcelo bagnulo braun Message-id: <000301c971a5$19ab2980$420c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 8BIT X-Priority: 3 X-MSMail-priority: Normal References: <73F7A221-7BAE-421B-AE3F-FC76E8B01F91@ericsson.com> <005d01c97144$6cfd6370$0201a8c0@china.huawei.com> <8D6CDB28-19A3-4C6E-BFCF-364F7B41E72B@ericsson.com> <014d01c9714d$a32e97d0$0201a8c0@china.huawei.com> <4965FD39.8010006@it.uc3m.es> Cc: Ana Kukec , SAVI Mailing List , Christian Vogt Subject: Re: [savi] Adopting draft-bagnulo-savi-fcfs/send 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, 08 Jan 2009 15:24:13 -0000 Hi Marcelo Please see my inline reply. BR Frank ----- Original Message ----- From: "marcelo bagnulo braun" To: "Frank Xia" Cc: "SAVI Mailing List" ; "Christian Vogt" ; "Ana Kukec" Sent: Thursday, January 08, 2009 7:18 AM Subject: Re: [savi] Adopting draft-bagnulo-savi-fcfs/send Frank, could you please point out who disagreed with the FCFS principle for creating SAVI state? Frank=>What I learn about SAVI is from http://tools.ietf.org/id/draft-bagnulo-savi-fcfs-00.txt. As to this draft, my friends sent me a simulation report, and the conclusion is not very optimistic. I am not 100% agreeing on the conclusion which says"We can see that FCFS is a very simple mechanism and this is the main advantage. But FCFS mechanism is regardless of Address Allocation Method and introduces a new stateless method, so it is not compatible with DHCP or manual method. Also, FCFS mechanism only bind IP to MAC or port, so it can not handle some special cases such as MMAC, MIF or LLM. At last, FCFS mechanism is vulnerable and is weak against DOS attacks." I think it does not matter who disagree with the FCFS, and it does matter if FCFS can deal with current issues. The disucssion so far was whether we use data packets and/or control packets for this, but it is always FCFS. Frank=>Good! From my understanding, using control packets are very important improvements. Of course, We can also call it FCFS. My understanding of the situation is that the current draft only uses data packets and Guang has raised the issue (that i understnad actually was Fred who brought this up) that some attacks can be launched between the DAD and the first data packet Frank=> We are always for SAVI state population based on control plane. Please check our draft http://www-etud.iro.umontreal.ca/~sarikaya/drafts/draft-kaippallimalil-savi-ipv6-bbnet-00.txt I agreed and i am ok with using ND packets as well to create state (at least for IPv6, not clear about IPv4 though). Frank=>Have you consider PPPoX scenario? Moreover, i also think we should use dhcp messages Frank=>Sure. Please see our draft. So, i don't see too much controversy here, but that we are converging to something. Frank=>Good. I am very open with converging and evolution. Regards, marcelo Frank Xia escribió: > Hi Christian > > A little bit curious :). > > Why are you VERY POSITIVE? > Have you any proof beyond SAVI mailing list? > > Probably, you can just do a simple poll, > and IMO it looks more convincing :-). > > BR > Frank > > ----- Original Message ----- From: "Christian Vogt" > > To: "Frank Xia" > Cc: "Fred Baker" ; "Erik Nordmark" > ; "Marcelo Bagnulo Braun" ; > "Jianping Wu" ; "Jun Bi" ; > "Ana Kukec" ; "Bill Fenner" ; "SAVI > Mailing List" > Sent: Wednesday, January 07, 2009 10:21 PM > Subject: Re: [savi] Adopting draft-bagnulo-savi-fcfs/send > > >> Frank - >> >> As I assured in my earlier email, those issues that have been raised are >> valid and will certainly have to be addressed. This includes your >> comment regarding the support for pre-configured addresses, as well as >> the question of whether binding establishment should be based on control >> or data packets, which I summarized in the email you are referring to. >> But the issues raised do not render the FCFS principle inappropriate for >> working group adoption. On the contrary, based on the feedback from the >> working group and the discussions I had with working group participants, >> I am very positive that there is in fact strong support for the FCFS >> principle. Hence the adoption of draft-bagnulo-savi-fcfs/send. >> >> - Christian >> >> >> >> On Jan 7, 2009, Frank Xia wrote: >> >>> Hi Christian >>> >>> It seems to be a little bit rush :-). >>> >>> I don't think people have enough >>> time to read your previous email. >>> >>> For my understanding, it is hard >>> to hard to say "STRONG" support >>> for the FCFS principle. >>> At least, I can not find strong support >>> through this long discussions in the mailing list. >>> >>> IMHO, the decision should be based >>> rough consensus by WG. IETF is based >>> on mailing list. >>> BR >>> Frank >> >> >> >> > > > _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi From christian.vogt@ericsson.com Thu Jan 8 11:10:25 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76CBD3A688F for ; Thu, 8 Jan 2009 11:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 fdiVX2smTNqJ for ; Thu, 8 Jan 2009 11:10:24 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 68B403A67B5 for ; Thu, 8 Jan 2009 11:10:24 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C982A209F7; Thu, 8 Jan 2009 20:10:09 +0100 (CET) X-AuditID: c1b4fb3c-ac75bbb00000304c-6d-49664f91ec85 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9E7A120569; Thu, 8 Jan 2009 20:10:09 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jan 2009 20:10:09 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jan 2009 20:10:08 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 096F6245E; Thu, 8 Jan 2009 21:10:09 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id EA2574DA9B; Thu, 8 Jan 2009 21:10:07 +0200 (EET) Message-Id: <8479BAF8-9B99-4661-9B82-A1F8D70D8C74@ericsson.com> From: Christian Vogt To: MARCELO BAGNULO BRAUN In-Reply-To: <20090108042844.jy12ki34coogggko@webcartero01.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 8 Jan 2009 11:10:06 -0800 References: <19ADF7C7-6E46-47F6-B7AC-2DF82C1F1636@ericsson.com> <20090108042844.jy12ki34coogggko@webcartero01.uc3m.es> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 08 Jan 2009 19:10:08.0853 (UTC) FILETIME=[B906D050:01C971C4] X-Brightmail-Tracker: AAAAAA== Cc: Guang Yao , SAVI Mailing List Subject: Re: [savi] Binding establishment based on data or control packets? 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, 08 Jan 2009 19:10:25 -0000 On Jan 7, 2009, MARCELO BAGNULO BRAUN wrote: > thanks for the summary > > some comments below... Marcelo - I agree with you that we cannot always expect a host to initiate control signaling before it sends data packets via a SAVI device that does not have a corresponding binding. Static addresses or loss of Neighbor Discovery messages, as you say, may create situations in which a SAVI device will receive packets with a source address that is legitimate, but for which the SAVI device does not have a binding. However, I don't think that having a SAVI device create a binding based on data packets in that case is the only way to handle said situations. A second option would be to have the SAVI device solicit the necessary control messages from the host, such as with a Neighbor Solicitation message. (Please note that I am not an advocate of either approach. I am just analyzing the solution space so as to make sure we pick the right solution. It may well be that we eventually choose to enable binding establishment via data packets.) The advantage of enabling data packets to create bindings is that it does not introduce extra signaling overhead. The extra signaling we would need if we restricted binding establishment to control packets does not have value unless (i) we use SeND, where the extra signaling would provide extra security in form of a cryptographic address ownership proof, or unless (ii) the signaling has the extra function of synchronizing multiple SAVI devices on a link. The advantage of restricting binding establishment to control packets is that it provides extra security where SeND is used, and that the extra signaling may be re-used to synchronize multiple SAVI devices on a link. We are certainly free to pick different solutions for the SeND-based and non-SeND variants of SAVI. But if we decide to use the same control signaling for both, binding establishment and inter-SAVI-device synchronization, then we may perhaps conclude to always restrict binding establishment to control packets. - Christian From christian.vogt@ericsson.com Thu Jan 8 11:15:26 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FAE83A6A68 for ; Thu, 8 Jan 2009 11:15:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 SOLBidkHORLz for ; Thu, 8 Jan 2009 11:15:26 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 19E503A67B5 for ; Thu, 8 Jan 2009 11:15:26 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AD599204D5; Thu, 8 Jan 2009 20:15:11 +0100 (CET) X-AuditID: c1b4fb3c-adf5ebb00000304c-fd-496650bffc2a Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7BC1020466; Thu, 8 Jan 2009 20:15:11 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jan 2009 20:15:10 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jan 2009 20:15:10 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CAFF1245F; Thu, 8 Jan 2009 21:15:10 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id BA3F94DA9B; Thu, 8 Jan 2009 21:15:09 +0200 (EET) Resent-To: Marcelo Bagnulo Braun From: Christian Vogt To: MARCELO BAGNULO BRAUN In-Reply-To: <20090108042844.jy12ki34coogggko@webcartero01.uc3m.es> Resent-From: Christian Vogt Resent-Cc: SAVI Mailing List , Guang Yao References: <19ADF7C7-6E46-47F6-B7AC-2DF82C1F1636@ericsson.com> <20090108042844.jy12ki34coogggko@webcartero01.uc3m.es> Message-Id: <8479BAF8-9B99-4661-9B82-A1F8D70D8C74@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Resent-Date: Thu, 8 Jan 2009 11:15:08 -0800 Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 8 Jan 2009 11:10:06 -0800 X-Mailer: Apple Mail (2.929.2) Resent-Message-Id: <20090108191509.BA3F94DA9B@nomadiclab.lmf.ericsson.se> X-OriginalArrivalTime: 08 Jan 2009 19:15:10.0684 (UTC) FILETIME=[6CEE91C0:01C971C5] X-Brightmail-Tracker: AAAAAA== Cc: Guang Yao , SAVI Mailing List Subject: Re: [savi] Binding establishment based on data or control packets? 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, 08 Jan 2009 19:15:26 -0000 On Jan 7, 2009, MARCELO BAGNULO BRAUN wrote: > thanks for the summary > > some comments below... Marcelo - I agree with you that we cannot always expect a host to initiate control signaling before it sends data packets via a SAVI device that does not have a corresponding binding. Static addresses or loss of Neighbor Discovery messages, as you say, may create situations in which a SAVI device will receive packets with a source address that is legitimate, but for which the SAVI device does not have a binding. However, I don't think that having a SAVI device create a binding based on data packets in that case is the only way to handle said situations. A second option would be to have the SAVI device solicit the necessary control messages from the host, such as with a Neighbor Solicitation message. (Please note that I am not an advocate of either approach. I am just analyzing the solution space so as to make sure we pick the right solution. It may well be that we eventually choose to enable binding establishment via data packets.) The advantage of enabling data packets to create bindings is that it does not introduce extra signaling overhead. The extra signaling we would need if we restricted binding establishment to control packets does not have value unless (i) we use SeND, where the extra signaling would provide extra security in form of a cryptographic address ownership proof, or unless (ii) the signaling has the extra function of synchronizing multiple SAVI devices on a link. The advantage of restricting binding establishment to control packets is that it provides extra security where SeND is used, and that the extra signaling may be re-used to synchronize multiple SAVI devices on a link. We are certainly free to pick different solutions for the SeND-based and non-SeND variants of SAVI. But if we decide to use the same control signaling for both, binding establishment and inter-SAVI-device synchronization, then we may perhaps conclude to always restrict binding establishment to control packets. - Christian From zhangdong_rh@huaweisymantec.com Wed Feb 4 01:21:49 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92ECC3A6C5B for ; Wed, 4 Feb 2009 01:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.678 X-Spam-Level: *** X-Spam-Status: No, score=3.678 tagged_above=-999 required=5 tests=[AWL=-1.358, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] 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 VU6S-6HkkBXx for ; Wed, 4 Feb 2009 01:21:48 -0800 (PST) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [121.15.168.142]) by core3.amsl.com (Postfix) with ESMTP id 6128D3A6B65 for ; Wed, 4 Feb 2009 01:21:27 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Content-type: text/plain; charset=gb2312 Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KEJ00M1WBB2IB70@hstga01-in.huaweisymantec.com> for savi@ietf.org; Wed, 04 Feb 2009 17:21:04 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KEJ007R5BB0Z700@hstml02-in.huaweisymantec.com> for savi@ietf.org; Wed, 04 Feb 2009 17:21:02 +0800 (CST) Received: from [10.27.140.94] by hstml02-in.huaweisymantec.com (mshttpd); Wed, 04 Feb 2009 17:21:00 +0800 From: ZhangDong To: marcelo bagnulo braun Message-id: Date: Wed, 04 Feb 2009 17:21:00 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <49857221.3040009@it.uc3m.es> References: <4978B663.8050301@it.uc3m.es> <49857221.3040009@it.uc3m.es> Content-transfer-encoding: quoted-printable Cc: SAVI Mailing List Subject: [savi] =?gb2312?b?u9i4tDogUmU6IEEgZmV3IGNvbW1lbnRzu9i4tDogIFtG?= =?gb2312?b?d2Q6IEktRCBBY3Rpb246ZHJhZnQtYmFnbnVsby1zYXZpLWZjZnMtMDEudHh0?= =?gb2312?b?XQ==?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 09:21:49 -0000 Sorry for the delay=2E =3E =3E=3E be stronger than that=2E On the other hand=2C if we use s= witch = =3E ports as =3E =3E=3E lower layer anchors (and there is only one host connected = to each =3E =3E=3E port) it is likely that the resulting SAVI solution will b= e =3E =3E=3E considerably more secure=2E =3E =3E=3E = =3E =3E In my opinion=2C the security of the layer 2 anchor should be = =3E considered in SAVI=2E =3E = =3E i agree with this =3E = =3E The proposal so far would be to have a defualt layer 2 anchor=2C wh= ich =3E could be the ports on switch for instance=2C to descibe the savi me= chanism =3E in the document and then to have a appendix at the end of the doucm= ent =3E considering the different layer 2 anchors and make considerations a= bout =3E each of them=2C does this sounds like a reasonable approahc to you=3F= =3E = It sounds useful=2E Is it necessary to introduce the concrete scenarios = of the savi mechnism=3F Starting an informational draft=3F =3E =3E The SAVI device should not rely on other mechnisms to protect = its = =3E reliability=2E =3E =3E = =3E but=2C by definition this is the case=2E=2E=2E I mean=2C so far=2C = the savi will =3E perform a bindiong between the IP address and the lower layer ancho= r=2E =3E An attacker has two possibel attack vectors=2E He can either try to= create =3E a false binding or it can spoof the layer 2 anchor that is containe= d = =3E in =3E the binding=2E The security of savi will be equivalent to the lower= =3E security of these two=2E So=2C depending on the lower layer anchor = is =3E selected=2C the security of savi will vary =3E = =3E =3E Maybe the SAVI device could check the MAC in the packet before = =3E creating the entry by enquiring whether the MAC is used or a = =3E legitimate one=2E =3E =3E = =3E = =3E but how do you do that=3F For instance=2C after receiving a packet from some node=2C the savi devi= ce may send a Neighbor Unreachability Detection message to the node by i= ts MAC=2E Succeed=2C create an entry in the DB=2E Or=2C the MAC in the p= acket may be forged=2C and the savi device drops the packet=2E What do you think about=3F Best regards Dong =3E = =3E regards=2C marcelo =3E = =3E = =3E =3E What is the opinion of others=3F =3E =3E =3E =3E best Regards=2C =3E =3E =3E =3E Dong Zhang =3E =3E =3E =3E =3E =3E ----- =D4=AD=CA=BC=D3=CA=BC=FE ----- =3E =3E =B7=A2=BC=FE=C8=CB=3A marcelo bagnulo braun =3Cmarcelo=40it=2Eu= c3m=2Ees=3E =3E =3E =C8=D5=C6=DA=3A 2009=C4=EA 1=D4=C2 23=C8=D5=2C =D0=C7=C6=DA=CE=E5= =2C =C9=CF=CE=E72=3A10 =3E =3E =D6=F7=CC=E2=3A =5Bsavi=5D =5BFwd=3A I-D Action=3Adraft-bagnulo= -savi-fcfs-01=2Etxt=5D =3E =3E =CA=D5=BC=FE=C8=CB=3A SAVI Mailing List =3Csavi=40ietf=2Eorg=3E= =3E =3E =3E =3E =3E =3E = =3E =3E=3E Hi=2C =3E =3E=3E = =3E =3E=3E we have submitted a new version of the draft trying to addr= ess = =3E the = =3E =3E=3E received comments=2E =3E =3E=3E This new version includes the usage of DAD and ACD to creat= e SAVI = =3E = =3E =3E=3E bindings and has an initial version of the security = =3E considerations=2C = =3E =3E=3E describing the DoS attacks countermeasures=2E =3E =3E=3E = =3E =3E=3E Comments are appreciated=2C =3E =3E=3E = =3E =3E=3E regards=2C marcelo =3E =3E=3E = =3E =3E=3E = =3E =3E=3E -------- Mensaje original -------- =3E =3E=3E Asunto=3A I-D Action=3Adraft-bagnulo-savi-fcfs-01=2Etxt =3E =3E=3E Fecha=3A Thu=2C 22 Jan 2009 10=3A00=3A01 -0800 (PST) =3E =3E=3E De=3A Internet-Drafts=40ietf=2Eorg =3E =3E=3E Responder a=3A internet-drafts=40ietf=2Eorg =3E =3E=3E Para=3A i-d-announce=40ietf=2Eorg =3E =3E=3E = =3E =3E=3E = =3E =3E=3E = =3E =3E=3E A New Internet-Draft is available from the on-line = =3E Internet-Drafts directories=2E =3E =3E=3E = =3E =3E=3E Title =3A First-Come First-Serve Source-Address = =3E Validation Implementation =3E =3E=3E Author(s) =3A E=2E Nordmark=2C M=2E Bagnulo =3E =3E=3E Filename =3A draft-bagnulo-savi-fcfs-01=2Etxt =3E =3E=3E Pages =3A 14 =3E =3E=3E Date =3A 2009-01-22 =3E =3E=3E = =3E =3E=3E This memo describes FCFS SAVI a mechanism to provide source= address =3E =3E=3E validation for IPv4 and IPv6 networks using the First-Come = First- =3E =3E=3E Serve approach=2E The proposed mechanism is intended to co= mplement =3E =3E=3E ingress filtering techniques to provide a higher granularit= y on the =3E =3E=3E control of the source addresses used=2E =3E =3E=3E = =3E =3E=3E A URL for this Internet-Draft is=3A =3E =3E=3E http=3A//www=2Eietf=2Eorg/internet-drafts/draft-bagnulo-sav= i-fcfs-01=2Etxt =3E =3E=3E = =3E =3E=3E Internet-Drafts are also available by anonymous FTP at=3A =3E =3E=3E ftp=3A//ftp=2Eietf=2Eorg/internet-drafts/ =3E =3E=3E = =3E =3E=3E Below is the data which will enable a MIME compliant mail r= eader =3E =3E=3E implementation to automatically retrieve the ASCII version = of the =3E =3E=3E Internet-Draft=2E =3E =3E=3E = =3E =3E=3E = =3E =3E=3E = =3E =3E=3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F =3E =3E=3E I-D-Announce mailing list =3E =3E=3E I-D-Announce=40ietf=2Eorg =3E =3E=3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/i-d-announce =3E =3E=3E Internet-Draft directories=3A http=3A//www=2Eietf=2Eorg/sha= dow=2Ehtml =3E =3E=3E or ftp=3A//ftp=2Eietf=2Eorg/ietf/1shadow-sites=2Etxt =3E =3E=3E = =3E =3E=3E = =3E =3E=3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F =3E =3E=3E savi mailing list =3E =3E=3E savi=40ietf=2Eorg =3E =3E=3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/savi =3E =3E=3E = =3E =3E=3E = =3E =3E =3E =3E = =3E = =3E From marcelo@it.uc3m.es Wed Feb 4 03:17: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 5D82B3A6881 for ; Wed, 4 Feb 2009 03:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=-2.812, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 zVV+IZMiG9H6 for ; Wed, 4 Feb 2009 03:17:40 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 8D4B93A6944 for ; Wed, 4 Feb 2009 03:17:39 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (186.pool85-53-146.dynamic.orange.es [85.53.146.186]) by smtp01.uc3m.es (Postfix) with ESMTP id 18E1AB4D8C6; Wed, 4 Feb 2009 12:17:18 +0100 (CET) Message-ID: <4989793D.2040207@it.uc3m.es> Date: Wed, 04 Feb 2009 12:17:17 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: yaog References: <19ADF7C7-6E46-47F6-B7AC-2DF82C1F1636@ericsson.com> <20090108042844.jy12ki34coogggko@webcartero01.uc3m.es> <0A3C8CC7DEE0F84C8B0B5E86F61EE522889F1F@eusrcmw721.eamcs.ericsson.se> <000801c98625$678ebf10$36ac3d30$@tsinghua.edu.cn> In-Reply-To: <000801c98625$678ebf10$36ac3d30$@tsinghua.edu.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16442.006 Cc: 'SAVI Mailing List' , 'Christian Vogt' Subject: Re: [savi] =?gb2312?b?tPC4tDogQmluZGluZyBlc3RhYmxpc2htZW50IGJhc2Vk?= =?gb2312?b?IG9uIGRhdGEgb3IgY29udHJvbCBwYWNrZXRzPw==?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 11:17:41 -0000 Hi Guang, yaog escribi¨®: > 1 Both data traffic and control traffic are used, and design a new protocol > to synch all the devices. > > 2 Only control traffic is used, and use option 3 to handle the exception of > DAD packet loss. > > the problem is not only DAD packet loss, but also aging of SAVI bindings. I mean, SAVI is using soft state, so it will need some form of garbage collection, right? So, suppose the following situation. A node configures its address, preforms DAD and the SAVI binding is created. After a while the node goes silent for a long period. The SAVI entry expires. The node sends a packet the SAVI device has deleted the entry (cause it has expired) so it will drop the packet. In other words, the SAVI device must do something upon the reception of a data packet with an unknown source address and i don't think dropping the packet is an option > I think these two ways are competitive. The first way has been completed by > Mr. Marcelo. not really > But > the second one has not been specified. Should we write a new draft to > specify the second way? > > IMHO, the problem about savi binding distribution protocol is how to authenticate the SAVI devices. If we can't authenticate the SAVI devices, we are in trouble, cause any attacker can inject false bindings, drop existent bindings and so on. the problem with auhtentication is that it is likely to require some configuration, which is not really that nice Regards, marcelo > Best regards, > Guang > -----ÓʼþÔ­¼þ----- > ·¢¼þÈË: Christian Vogt [mailto:christian.vogt@ericsson.com] > ·¢ËÍʱ¼ä: 2009Äê1ÔÂ22ÈÕ 9:51 > ÊÕ¼þÈË: MARCELO BAGNULO BRAUN > ³­ËÍ: SAVI Mailing List; Guang Yao > Ö÷Ìâ: RE: Binding establishment based on data or control packets? > > Marcelo - > > In your email below, you identified several situation in which a SAVI > device may erroneously discard packets if binding establishment was > based on control packets only. This is correct if you assume that the > SAVI device does not react to data packets. OTOH, the SAVI device may > initiate the necessary control packet exchange upon receiving a data > packet. This is what I was assuming to be the case, and what you were > assuming not to be the case, I guess. Hence the misunderstanding. I > think we are on the same page. > > Having said this, I like the summary of possible solution approaches > that you have suggested earlier: When a SAVI device receives a data > packet for which source address it does not have a binding, does it... > > (1) discard the packet > (2) create a binding for the packet's source address directly > (3) initiate a control packet exchange (such as NUD) to verify the > packet's source address before creating a binding > > I agree with you that option (3) does not have a directly apparent > advantage. The only /potential/ advantage that I can think of is that > the control packet exchanges initiated in option (3) might be re-usable > as a protocol for inter-SAVI-device coordination. However, this > requires more analysis. > > - Christian > > PS: Sorry for the delay in responding. I relocated to the U.S. > recently, and this has been consuming part of my time. > > > > >> -----Original Message----- >> From: MARCELO BAGNULO BRAUN [mailto:marcelo@it.uc3m.es] >> Sent: Wednesday, January 07, 2009 7:29 PM >> To: Christian Vogt >> Cc: SAVI Mailing List; Guang Yao >> Subject: Re: Binding establishment based on data or control packets? >> >> Hi Christian, >> >> thanks for the summary >> >> some comments below... >> >> Christian Vogt dijo: >> >> >> >>> More specifically, the reason for the aforementioned attack is the >>> existence of a shortcut for binding establishment, which is >>> non-legitimate, but which is not prevented either. To prevent the >>> attack, the shortcut must be eliminated. And this means >>> >> that binding >> >>> establishment should be based on the first packet independent of >>> whether this is a data packet or a control packet. >>> >> Right, i concur with this, the savi state must be created >> with the firs packet, either data or control packet (dhcp, ND) >> >> >>> The residual question therefore is whether or not data >>> >> packets should >> >>> be used for binding establishment in addition to control packets. >>> There are pros and cons for either approach: >>> >>> - The advantage of using data packets is that statically configured >>> addresses become straightforward to support. Hosts with >>> >> statically >> >>> configured addresses cannot be expected to engage in any >>> >> exchange of >> >>> control packets, so a simple method to establish a binding in this >>> case is based on the first data packet. >>> >>> >> Actually, i think there are more reasons for using data packets >> >> The main reason is that DAD is not reliable. The ND packet >> can be lost and not make it to the SAVI device (e.g. error in >> the packet for >> instance) >> >> Let's consider the following situation: >> Suppose that the SAVI device receives a data packet for which >> source address it doens't have a binding, what does the savi >> device does_? >> does it discards the packet? It seems an overkill to me, >> since we are not sure what happned. In the data based >> approach, we create the state. >> Using only control packet introduces this error mode. >> >> >>> - The advantage of /not/ using data packets is that it becomes less >>> likely for hosts and SAVI devices to lose sync regarding a host's >>> right to use an address. A host and its connected SAVI >>> >> device then >> >>> always determine such right based on the same control >>> >> packets, so in >> >>> the absence of control packet loss on the link segment between the >>> host and the SAVI device, it is impossible for the host >>> >> and the SAVI >> >>> device to have different understanding regarding the >>> >> host's right to >> >>> use an address. >>> >>> >> I don't understand this. >> Suppose that a host configures the address performs DAD and >> then goes quit for a really long time. At some point the SAVI >> device will discard the state for that address. The node then >> sends a data packet, what happnes? In this case, they are out >> of sync and the straight forward way to deal with this is to >> react upon the reception of data packets. >> >> >>> However, neither of these is a strong argument for or >>> >> against the use >> >>> of data packets for binding establishment. >>> >> IMHO there is strong case for using data packets, as described above >> >> >> >>> Statically configured addresses >>> could also be supported if bindings were established based on only >>> control packets: A SAVI device could, e.g., initiate a Duplicate >>> Address Detection procedure on behalf of a host when the host sends >>> the first data packet from a statically configured address. >>> >> Loss of >> >>> synchronization between hosts and SAVI devices could, e.g., also be >>> resolved with the Neighbor Unreachability Detection >>> >> procedure, such as >> >>> proposed in draft-bagnulo-savi-fcfs. >>> >>> >> Right, actually this is what i was thinking as inter switch >> protocol to spread the state crated using data packets >> >> >>> I think that, in order to move forward and decide whether or not to >>> use data packets for binding establishment, we should also consider >>> the affects on SAVI solution components other than the >>> >> initial binding >> >>> establishment. One such component is inter-switch mobility: Would >>> the re-establishment of the binding in the new switch become easier >>> based on data packets or control packets? >>> >> Does the node needs to perform DAD when the host moves from >> one swithc to another? >> >> How about the removal of the binding >> >>> in the old switch? Another component is SeND support (in the >>> SeND-based SAVI variant): If binding establishment is exclusively >>> based on control packets, the use of SeND automatically >>> >> protects binding establishment. >> >>> This is not the case if data packets are used to establish bindings >>> because SeND does not protect the source address in data packets. >>> >> The SEND based savi already performs a ND query to verify >> address ownership. i.e. upon the reception of a data packet >> it forces the sender to generate a control packet, which is >> ok for send imho >> >> Regards, marcelo >> >> >> SeND >> >>> can then only protect the Neighbor Unreachability Detection >>> >> procedure, >> >>> which is used for garbage collection in draft-bagnulo-savi-fcfs. >>> >>> What does the working group think about this? Please comment. >>> >>> One final, important note: Of course, the FCFS principle, the core >>> idea of draft-bagnulo-savi-fcfs, is orthogonal to whether >>> >> or not data >> >>> packets are used for binding establishment. And based on >>> >> the feedback >> >>> we got at the SAVI meeting in Minneapolis and so far on >>> >> this mailing >> >>> list, the FCFS principle is by many considered the way to go. >>> >>> - Christian >>> >>> >>> >>> >> >> -- >> ---- >> MARCELO BAGNULO BRAUN >> WebCartero >> Universidad Carlos III de Madrid >> >> >> > > > > From marcelo@it.uc3m.es Wed Feb 4 03:51: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 D78BD3A6B03 for ; Wed, 4 Feb 2009 03:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.711 X-Spam-Level: X-Spam-Status: No, score=-1.711 tagged_above=-999 required=5 tests=[AWL=-2.746, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 0g56+q4P36dJ for ; Wed, 4 Feb 2009 03:51:23 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 615AF3A69CB for ; Wed, 4 Feb 2009 03:51:22 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (186.pool85-53-146.dynamic.orange.es [85.53.146.186]) by smtp03.uc3m.es (Postfix) with ESMTP id E13A473282A; Wed, 4 Feb 2009 12:50:58 +0100 (CET) Message-ID: <49898120.8020206@it.uc3m.es> Date: Wed, 04 Feb 2009 12:50:56 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: yaog References: <19ADF7C7-6E46-47F6-B7AC-2DF82C1F1636@ericsson.com> <20090108042844.jy12ki34coogggko@webcartero01.uc3m.es> <0A3C8CC7DEE0F84C8B0B5E86F61EE522889F1F@eusrcmw721.eamcs.ericsson.se> <49784B7B.8000507@it.uc3m.es> <000e01c9862d$50790ad0$f16b2070$@tsinghua.edu.cn> In-Reply-To: <000e01c9862d$50790ad0$f16b2070$@tsinghua.edu.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16442.006 Cc: 'SAVI Mailing List' , 'Christian Vogt' Subject: Re: [savi] =?gb2312?b?tPC4tDogQmluZGluZyBlc3RhYmxpc2htZW50IGJhc2Vk?= =?gb2312?b?IG9uIGRhdGEgb3IgY29udHJvbCBwYWNrZXRzPw==?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 11:51:23 -0000 yaog escribi¨®: > -----ÓʼþÔ­¼þ----- > ·¢¼þÈË: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > ·¢ËÍʱ¼ä: 2009Äê1ÔÂ22ÈÕ 18:34 > ÊÕ¼þÈË: Christian Vogt > ³­ËÍ: SAVI Mailing List; Guang Yao > Ö÷Ìâ: Re: Binding establishment based on data or control packets? > > Christian Vogt escribi¨®: > >> Marcelo - >> >> In your email below, you identified several situation in which a SAVI >> device may erroneously discard packets if binding establishment was >> based on control packets only. This is correct if you assume that the >> SAVI device does not react to data packets. OTOH, the SAVI device may >> initiate the necessary control packet exchange upon receiving a data >> packet. This is what I was assuming to be the case, and what you were >> assuming not to be the case, I guess. Hence the misunderstanding. I >> think we are on the same page. >> >> Having said this, I like the summary of possible solution approaches >> that you have suggested earlier: When a SAVI device receives a data >> packet for which source address it does not have a binding, does it... >> >> (1) discard the packet >> (2) create a binding for the packet's source address directly >> (3) initiate a control packet exchange (such as NUD) to verify the >> packet's source address before creating a binding >> >> I agree with you that option (3) does not have a directly apparent >> advantage. The only /potential/ advantage that I can think of is that >> the control packet exchanges initiated in option (3) might be re-usable >> as a protocol for inter-SAVI-device coordination. However, this >> requires more analysis. >> >> > > right > I have been thinking about this > Triggering an NSOL upon the reception of a data packet for which there > is no binding in the SAVI device could have two potential advantages: > - first, that can be used to synchronize multiple SAVI devices. this is > indeed a benefit > - second that could allow a victim to know if an attacker is trying to > set up a savi state for the victim's address. Now this seems like an > advanatage, but after some thought, i don't think it is. > > Let's suppose that the savi device sends a RSOL packet upon the > reception of a data packet with an unknown source address. > Suppose the SAVI device receives two replies. What can the SAVI device > do with this? > > ~Comment Start~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~Guang: > And another comment: > If you mean two node can get the same address both legally, this just > means the nodes and SAVI devices are not well synched. > ~ Comment End~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > I don't understand what you mean here From marcelo@it.uc3m.es Wed Feb 4 04:00:48 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30D7928C201 for ; Wed, 4 Feb 2009 04:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=-2.684, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 S2JFFzZBivWa for ; Wed, 4 Feb 2009 04:00:46 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 1FCC328C24A for ; Wed, 4 Feb 2009 04:00:45 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (186.pool85-53-146.dynamic.orange.es [85.53.146.186]) by smtp01.uc3m.es (Postfix) with ESMTP id ACB73B4D5CD; Wed, 4 Feb 2009 13:00:21 +0100 (CET) Message-ID: <49898355.6060803@it.uc3m.es> Date: Wed, 04 Feb 2009 13:00:21 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: yaog References: <19ADF7C7-6E46-47F6-B7AC-2DF82C1F1636@ericsson.com> <20090108042844.jy12ki34coogggko@webcartero01.uc3m.es> <0A3C8CC7DEE0F84C8B0B5E86F61EE522889F1F@eusrcmw721.eamcs.ericsson.se> <49784B7B.8000507@it.uc3m.es> <000d01c9862a$fe207c20$fa617460$@tsinghua.edu.cn> In-Reply-To: <000d01c9862a$fe207c20$fa617460$@tsinghua.edu.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16442.006 Cc: 'SAVI Mailing List' , 'Christian Vogt' Subject: Re: [savi] =?gb2312?b?tPC4tDogQmluZGluZyBlc3RhYmxpc2htZW50IGJhc2Vk?= =?gb2312?b?IG9uIGRhdGEgb3IgY29udHJvbCBwYWNrZXRzPw==?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 12:00:48 -0000 yaog escribi¨®: > -----ÓʼþÔ­¼þ----- > ·¢¼þÈË: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > ·¢ËÍʱ¼ä: 2009Äê1ÔÂ22ÈÕ 18:34 > ÊÕ¼þÈË: Christian Vogt > ³­ËÍ: SAVI Mailing List; Guang Yao > Ö÷Ìâ: Re: Binding establishment based on data or control packets? > > Christian Vogt escribi¨®: > >> Marcelo - >> >> In your email below, you identified several situation in which a SAVI >> device may erroneously discard packets if binding establishment was >> based on control packets only. This is correct if you assume that the >> SAVI device does not react to data packets. OTOH, the SAVI device may >> initiate the necessary control packet exchange upon receiving a data >> packet. This is what I was assuming to be the case, and what you were >> assuming not to be the case, I guess. Hence the misunderstanding. I >> think we are on the same page. >> >> Having said this, I like the summary of possible solution approaches >> that you have suggested earlier: When a SAVI device receives a data >> packet for which source address it does not have a binding, does it... >> >> (1) discard the packet >> (2) create a binding for the packet's source address directly >> (3) initiate a control packet exchange (such as NUD) to verify the >> packet's source address before creating a binding >> >> I agree with you that option (3) does not have a directly apparent >> advantage. The only /potential/ advantage that I can think of is that >> the control packet exchanges initiated in option (3) might be re-usable >> as a protocol for inter-SAVI-device coordination. However, this >> requires more analysis. >> >> > > right > I have been thinking about this > Triggering an NSOL upon the reception of a data packet for which there > is no binding in the SAVI device could have two potential advantages: > - first, that can be used to synchronize multiple SAVI devices. this is > indeed a benefit > - second that could allow a victim to know if an attacker is trying to > set up a savi state for the victim's address. Now this seems like an > advanatage, but after some thought, i don't think it is. > > Let's suppose that the savi device sends a RSOL packet upon the > reception of a data packet with an unknown source address. > Suppose the SAVI device receives two replies. What can the SAVI device > do with this? > ~Comment Start~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~Guang: > Actually, I have a method to distinguish spoofing and a node with two > interfaces to the same LAN, which both can cause two replies. > The NA packet has such format: > [source address][dest address][target address] > If two replies are got, then we should get two source address S1, S2. > Generally S1,S2 are link local addresses. This point depends on the source > address the SAVI device chooses to send NS. > Then we can ask the attempt node if it knows S2(suppose it sends packet with > S1). > If it knows, they are the same nodes. > If it doesn¡¯t know, it is spoofing or incorrect configuration. > More details can be discussed. I have some ideas to make this procedure more > secure. > but this requires changes in the host, right? i think host changes are ut of scope > ~ Comment End~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Actually what happens when we design SAVI such that it sends RSOL > packets, is that the RSOL packet acts as a synchronization point, that > can be used by attacker to claim the address ownership and confuse the > SAVI device. In other words, the whole point of a FCFS appraoch, is that > requests arrive in the natural. If we introduce the RSOL > synchronization, the order is broken and we can hardly tell who is the > first one to request. > > ~Comment Start~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~Guang: > I don't think the SAVI device should allow spoofing NA. > Maybe you are considering the partial deployment, and there can be spoofing > from local nodes. This is a problem. If we specify that the mechanism should > work when partially deployed, many things should be re-considered. > what do you mean by partially deployed? > I don't quite catch this sentence: > " In other words, the whole point of a FCFS appraoch, is that > requests arrive in the natural. If we introduce the RSOL > synchronization, the order is broken and we can hardly tell who is the > first one to request." > The whole point in FCFS is that the first one that claims an address has it. Now, an attacker could claim all the addresses and if it does so, we have a problem (that is why i am more and more convinced that FCFS SAVI is not good enough for IPv4). In IPv6, the attacker cannot claim all the addresses cause there are simply too many addresses. So, an attacker needs to choose which addresses have "value". One of the things that gives value to an address is that this particular address is configured in a host. The problem that the attacker has is that in order to launch the attack it needs to know which address to attack. One way of knowing that is looking into DAD. That is the attack you described a while ago. The attacker learns what address has a value by looking into DAD and then creates a SAVI binding for that address. Now, we have closed that vulnerability by using the DAD to create the SAVI binding. Now, if we allow the SAVI device to send a NSOL for an address, this acts as a call for arms for the attacker. It bassically tells the attacker "this si the right moment to try to get over this address", and the savi device has no way to defend itself, cause it cannot know if the NADV comes from an attacker or not. Makes sense? > ~ Comment End~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > So, i don't think SAVI should send a RSOL upon the reception of a data > packet > > BTW this has implications for the inter savi protocol, since we > shouldn't use any broadcasted message (at least in the clear) cause it > would have the same effect > > ~Comment Start~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~Guang: > What I want to emphasize is, DAD packet loss is of little possibility. > Even the solution brings some false negative, it is still acceptable. > not really in a wireless network, i don't think the possibility of packets not being delivered is so small in addition, you have to deal with the case of gargabe collection, as i have described in the previous email regards, marcelo > ~ Comment End~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Regards, marcelo > > > > >> - Christian >> >> PS: Sorry for the delay in responding. I relocated to the U.S. >> recently, and this has been consuming part of my time. >> >> >> >> >> >>> -----Original Message----- >>> From: MARCELO BAGNULO BRAUN [mailto:marcelo@it.uc3m.es] >>> Sent: Wednesday, January 07, 2009 7:29 PM >>> To: Christian Vogt >>> Cc: SAVI Mailing List; Guang Yao >>> Subject: Re: Binding establishment based on data or control packets? >>> >>> Hi Christian, >>> >>> thanks for the summary >>> >>> some comments below... >>> >>> Christian Vogt dijo: >>> >>> >>> >>> >>>> More specifically, the reason for the aforementioned attack is the >>>> existence of a shortcut for binding establishment, which is >>>> non-legitimate, but which is not prevented either. To prevent the >>>> attack, the shortcut must be eliminated. And this means >>>> >>>> >>> that binding >>> >>> >>>> establishment should be based on the first packet independent of >>>> whether this is a data packet or a control packet. >>>> >>>> >>> Right, i concur with this, the savi state must be created >>> with the firs packet, either data or control packet (dhcp, ND) >>> >>> >>> >>>> The residual question therefore is whether or not data >>>> >>>> >>> packets should >>> >>> >>>> be used for binding establishment in addition to control packets. >>>> There are pros and cons for either approach: >>>> >>>> - The advantage of using data packets is that statically configured >>>> addresses become straightforward to support. Hosts with >>>> >>>> >>> statically >>> >>> >>>> configured addresses cannot be expected to engage in any >>>> >>>> >>> exchange of >>> >>> >>>> control packets, so a simple method to establish a binding in this >>>> case is based on the first data packet. >>>> >>>> >>>> >>> Actually, i think there are more reasons for using data packets >>> >>> The main reason is that DAD is not reliable. The ND packet >>> can be lost and not make it to the SAVI device (e.g. error in >>> the packet for >>> instance) >>> >>> Let's consider the following situation: >>> Suppose that the SAVI device receives a data packet for which >>> source address it doens't have a binding, what does the savi >>> device does_? >>> does it discards the packet? It seems an overkill to me, >>> since we are not sure what happned. In the data based >>> approach, we create the state. >>> Using only control packet introduces this error mode. >>> >>> >>> >>>> - The advantage of /not/ using data packets is that it becomes less >>>> likely for hosts and SAVI devices to lose sync regarding a host's >>>> right to use an address. A host and its connected SAVI >>>> >>>> >>> device then >>> >>> >>>> always determine such right based on the same control >>>> >>>> >>> packets, so in >>> >>> >>>> the absence of control packet loss on the link segment between the >>>> host and the SAVI device, it is impossible for the host >>>> >>>> >>> and the SAVI >>> >>> >>>> device to have different understanding regarding the >>>> >>>> >>> host's right to >>> >>> >>>> use an address. >>>> >>>> >>>> >>> I don't understand this. >>> Suppose that a host configures the address performs DAD and >>> then goes quit for a really long time. At some point the SAVI >>> device will discard the state for that address. The node then >>> sends a data packet, what happnes? In this case, they are out >>> of sync and the straight forward way to deal with this is to >>> react upon the reception of data packets. >>> >>> >>> >>>> However, neither of these is a strong argument for or >>>> >>>> >>> against the use >>> >>> >>>> of data packets for binding establishment. >>>> >>>> >>> IMHO there is strong case for using data packets, as described above >>> >>> >>> >>> >>>> Statically configured addresses >>>> could also be supported if bindings were established based on only >>>> control packets: A SAVI device could, e.g., initiate a Duplicate >>>> Address Detection procedure on behalf of a host when the host sends >>>> the first data packet from a statically configured address. >>>> >>>> >>> Loss of >>> >>> >>>> synchronization between hosts and SAVI devices could, e.g., also be >>>> resolved with the Neighbor Unreachability Detection >>>> >>>> >>> procedure, such as >>> >>> >>>> proposed in draft-bagnulo-savi-fcfs. >>>> >>>> >>>> >>> Right, actually this is what i was thinking as inter switch >>> protocol to spread the state crated using data packets >>> >>> >>> >>>> I think that, in order to move forward and decide whether or not to >>>> use data packets for binding establishment, we should also consider >>>> the affects on SAVI solution components other than the >>>> >>>> >>> initial binding >>> >>> >>>> establishment. One such component is inter-switch mobility: Would >>>> the re-establishment of the binding in the new switch become easier >>>> based on data packets or control packets? >>>> >>>> >>> Does the node needs to perform DAD when the host moves from >>> one swithc to another? >>> >>> How about the removal of the binding >>> >>> >>>> in the old switch? Another component is SeND support (in the >>>> SeND-based SAVI variant): If binding establishment is exclusively >>>> based on control packets, the use of SeND automatically >>>> >>>> >>> protects binding establishment. >>> >>> >>>> This is not the case if data packets are used to establish bindings >>>> because SeND does not protect the source address in data packets. >>>> >>>> >>> The SEND based savi already performs a ND query to verify >>> address ownership. i.e. upon the reception of a data packet >>> it forces the sender to generate a control packet, which is >>> ok for send imho >>> >>> Regards, marcelo >>> >>> >>> SeND >>> >>> >>>> can then only protect the Neighbor Unreachability Detection >>>> >>>> >>> procedure, >>> >>> >>>> which is used for garbage collection in draft-bagnulo-savi-fcfs. >>>> >>>> What does the working group think about this? Please comment. >>>> >>>> One final, important note: Of course, the FCFS principle, the core >>>> idea of draft-bagnulo-savi-fcfs, is orthogonal to whether >>>> >>>> >>> or not data >>> >>> >>>> packets are used for binding establishment. And based on >>>> >>>> >>> the feedback >>> >>> >>>> we got at the SAVI meeting in Minneapolis and so far on >>>> >>>> >>> this mailing >>> >>> >>>> list, the FCFS principle is by many considered the way to go. >>>> >>>> - Christian >>>> >>>> >>>> >>>> >>>> >>> -- >>> ---- >>> MARCELO BAGNULO BRAUN >>> WebCartero >>> Universidad Carlos III de Madrid >>> >>> >>> >>> >> >> > > > > From marcelo@it.uc3m.es Wed Feb 4 04:03: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 9F2A83A6B03 for ; Wed, 4 Feb 2009 04:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[AWL=-2.624, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 FyrZlR0LPLjw for ; Wed, 4 Feb 2009 04:03:38 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 740F93A6A95 for ; Wed, 4 Feb 2009 04:03:38 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (186.pool85-53-146.dynamic.orange.es [85.53.146.186]) by smtp01.uc3m.es (Postfix) with ESMTP id 3950BB4D89C; Wed, 4 Feb 2009 13:03:17 +0100 (CET) Message-ID: <49898405.8030800@it.uc3m.es> Date: Wed, 04 Feb 2009 13:03:17 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: yaog References: <19ADF7C7-6E46-47F6-B7AC-2DF82C1F1636@ericsson.com> <20090108042844.jy12ki34coogggko@webcartero01.uc3m.es> <0A3C8CC7DEE0F84C8B0B5E86F61EE522889F1F@eusrcmw721.eamcs.ericsson.se> <49784B7B.8000507@it.uc3m.es> <49790398.30309@it.uc3m.es> <000f01c9862d$c07ce270$4176a750$@tsinghua.edu.cn> In-Reply-To: <000f01c9862d$c07ce270$4176a750$@tsinghua.edu.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16442.006 Cc: 'SAVI Mailing List' , 'Christian Vogt' Subject: Re: [savi] =?gb2312?b?tPC4tDogIEJpbmRpbmcgZXN0YWJsaXNobWVudCBiYXNl?= =?gb2312?b?ZCBvbiBkYXRhIG9yIGNvbnRyb2wgcGFja2V0cz8=?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 12:03:39 -0000 yaog escribi¨®: > -----ÓʼþÔ­¼þ----- > ·¢¼þÈË: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > ·¢ËÍʱ¼ä: 2009Äê1ÔÂ23ÈÕ 7:39 > ÊÕ¼þÈË: Christian Vogt > ³­ËÍ: Guang Yao; SAVI Mailing List > Ö÷Ìâ: Re: [savi] Binding establishment based on data or control packets? > > Christian Vogt escribi¨®: > >> On Jan 22, 2009, marcelo bagnulo braun wrote: >> >> >>> Actually what happens when we design SAVI such that it sends RSOL >>> packets, is that the RSOL packet acts as a synchronization point, that >>> can be used by attacker to claim the address ownership and confuse the >>> SAVI device. In other words, the whole point of a FCFS appraoch, is that >>> requests arrive in the natural. If we introduce the RSOL >>> synchronization, the order is broken and we can hardly tell who is the >>> first one to request. >>> >> Marcelo - >> >> The potential issue that an attacker can trick a SAVI device into >> creating a false binding already exists in FCFS without binding >> distribution protocol. In that case, false bindings are limited to the >> SAVI device to which the attacker attaches directly. Why do you think >> the issue becomes so much worse if a binding distribution protocol >> enabled the attacker to create a false binding also in other SAVI >> devices? >> > > cause the difference here is that attacker knows what IP address is a > valuable target (i.e. the address included in the NSOL msg) > > The NSOL msg acts like a call for arms for the attacker to attack that > address. > > I mean, let's focus in the IPv6 case. In IPv6, the attacker cannot > attack all the addresses cause 2^64 are way too many addresses. So, it > needs some hint about which address is a good target. Issuing the RSOL > acts as such. > > Note that there is a difference between the attacker replying to the > NSOL issued by the end host during the DAD and the attacker replying to > the NSOL issued by a SAVI device. In the case of DAD, if the attacker > replies, the host will not sue that address. However, when the SAVI > issues the NSOL message, the host is already using the address, so > blocking the address would imply that the host cannot use the address it > has configured. > > ~Comment Start~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~Guang: > 1 We are actually blocking wrong configuration. It is reasonable. > I am not sure i understand blocking a packet sent by the rightfull owner of the address (which is what i described above) is _not_ ok > 2 Let pass the packets will cause more trouble. > letting pass the packets sent by the rightfull owner is the right thing to do > 3 I think it is still synch problem first. > not sure what you mean regards, marcelo > ~ Comment End~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Finally, suppose that the SAVI device actually sends the NSOL, then what > does the SAVI device does it receives two NADV replying? > I mean, there is no way to tell who is the rightful owner, so what > should the SAVI device do in that case? > > Regards, marcelo > > >> (I am saying "potential" issue above because the issue can be avoided if >> the SAVI device knows that the address is already being used elsewhere.) >> >> - Christian >> >> >> >> > > > > From marcelo@it.uc3m.es Wed Feb 4 04:06:53 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 71B893A6A78 for ; Wed, 4 Feb 2009 04:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.532 X-Spam-Level: X-Spam-Status: No, score=-1.532 tagged_above=-999 required=5 tests=[AWL=-2.567, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 Qb5xtR2qwf1Q for ; Wed, 4 Feb 2009 04:06:52 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 1B1AA28C1AE for ; Wed, 4 Feb 2009 04:06:51 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (186.pool85-53-146.dynamic.orange.es [85.53.146.186]) by smtp03.uc3m.es (Postfix) with ESMTP id DE86B732436; Wed, 4 Feb 2009 13:06:30 +0100 (CET) Message-ID: <498984C6.3070701@it.uc3m.es> Date: Wed, 04 Feb 2009 13:06:30 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: ZhangDong References: <4978B663.8050301@it.uc3m.es> <49857221.3040009@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16442.006 Cc: SAVI Mailing List Subject: Re: [savi] =?gb2312?b?u9i4tDogUmU6IEEgZmV3IGNvbW1lbnRzu9i4tDogIFtG?= =?gb2312?b?d2Q6IEktRCBBY3Rpb246ZHJhZnQtYmFnbnVsby1zYXZpLWZjZnMtMDEudHh0?= =?gb2312?b?XQ==?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 12:06:53 -0000 ZhangDong escribi¨®: > Sorry for the delay. > > >> >> 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. >> >> >> > In my opinion, the security of the layer 2 anchor should be >> considered in SAVI. >> >> i agree with this >> >> The proposal so far would be to have a defualt layer 2 anchor, which >> could be the ports on switch for instance, to descibe the savi mechanism >> in the document and then to have a appendix at the end of the doucment >> considering the different layer 2 anchors and make considerations about >> each of them, does this sounds like a reasonable approahc to you? >> >> > > It sounds useful. Is it necessary to introduce the concrete scenarios of the savi mechnism? Starting an informational draft? > > >> > The SAVI device should not rely on other mechnisms to protect its >> reliability. >> > >> but, by definition this is the case... I mean, so far, the savi will >> perform a bindiong between the IP address and the lower layer anchor. >> An attacker has two possibel attack vectors. He can either try to create >> a false binding or it can spoof the layer 2 anchor that is contained >> in >> the binding. The security of savi will be equivalent to the lower >> security of these two. So, depending on the lower layer anchor is >> selected, the security of savi will vary >> >> > Maybe the SAVI device could check the MAC in the packet before >> creating the entry by enquiring whether the MAC is used or a >> legitimate one. >> > >> >> but how do you do that? >> > > For instance, after receiving a packet from some node, the savi device may send a Neighbor Unreachability Detection message to the node by its MAC. Succeed, create an entry in the DB. Or, the MAC in the packet may be forged, and the savi device drops the packet. > What do you think about? > > but if the attacker has forged the MAC it will be able to reply to the NUD msg, right? I fail to see what additional defense is achieved with this... perhaps you could describe an attack that is prevented with this technique? regards, marcelo > Best regards > > Dong > > >> >> regards, marcelo >> >> >> > What is the opinion of others? >> > >> > best Regards, >> > >> > Dong Zhang >> > >> > >> > ----- ԭʼÓʼþ ----- >> > ·¢¼þÈË: marcelo bagnulo braun >> > ÈÕÆÚ: 2009Äê 1Ô 23ÈÕ, ÐÇÆÚÎå, ÉÏÎç2:10 >> > Ö÷Ìâ: [savi] [Fwd: I-D Action:draft-bagnulo-savi-fcfs-01.txt] >> > ÊÕ¼þÈË: SAVI Mailing List >> > >> > >> > >> >> Hi, >> >> >> >> we have submitted a new version of the draft trying to address >> the >> >> received comments. >> >> This new version includes the usage of DAD and ACD to create SAVI >> >> >> bindings and has an initial version of the security >> considerations, >> >> describing the DoS attacks countermeasures. >> >> >> >> Comments are appreciated, >> >> >> >> regards, marcelo >> >> >> >> >> >> -------- Mensaje original -------- >> >> Asunto: I-D Action:draft-bagnulo-savi-fcfs-01.txt >> >> Fecha: Thu, 22 Jan 2009 10:00:01 -0800 (PST) >> >> De: Internet-Drafts@ietf.org >> >> Responder a: internet-drafts@ietf.org >> >> Para: i-d-announce@ietf.org >> >> >> >> >> >> >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> >> >> >> Title : First-Come First-Serve Source-Address >> Validation Implementation >> >> Author(s) : E. Nordmark, M. Bagnulo >> >> Filename : draft-bagnulo-savi-fcfs-01.txt >> >> Pages : 14 >> >> Date : 2009-01-22 >> >> >> >> This memo describes FCFS SAVI a mechanism to provide source address >> >> validation for IPv4 and 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-bagnulo-savi-fcfs-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. >> >> >> >> >> >> >> >> _______________________________________________ >> >> I-D-Announce mailing list >> >> I-D-Announce@ietf.org >> >> https://www.ietf.org/mailman/listinfo/i-d-announce >> >> Internet-Draft directories: http://www.ietf.org/shadow.html >> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> >> >> >> _______________________________________________ >> >> savi mailing list >> >> savi@ietf.org >> >> https://www.ietf.org/mailman/listinfo/savi >> >> >> >> >> > >> > >> >> >> > > From christian.vogt@ericsson.com Fri Feb 13 19:13:45 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E1523A68F0 for ; Fri, 13 Feb 2009 19:13:45 -0800 (PST) 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 lukhW1i3NzZQ for ; Fri, 13 Feb 2009 19:13:44 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 615EE3A6765 for ; Fri, 13 Feb 2009 19:13:40 -0800 (PST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n1E3KBep032755; Fri, 13 Feb 2009 21:20:11 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 21:13:45 -0600 Received: from [155.53.229.77] ([155.53.229.77]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 21:13:45 -0600 Message-Id: <480E62D1-0D22-479B-9D4E-6AC03B08A8CE@ericsson.com> From: Christian Vogt To: marcelo bagnulo braun In-Reply-To: <49784B7B.8000507@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 13 Feb 2009 19:13:54 -0800 References: <19ADF7C7-6E46-47F6-B7AC-2DF82C1F1636@ericsson.com> <20090108042844.jy12ki34coogggko@webcartero01.uc3m.es> <0A3C8CC7DEE0F84C8B0B5E86F61EE522889F1F@eusrcmw721.eamcs.ericsson.se> <49784B7B.8000507@it.uc3m.es> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 14 Feb 2009 03:13:45.0163 (UTC) FILETIME=[3EF759B0:01C98E52] Cc: Guang Yao , SAVI Mailing List Subject: Re: [savi] Binding establishment based on data or control packets? 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, 14 Feb 2009 03:13:45 -0000 Marcelo - A late comment on our previous discussion on whether SAVI devices should initiate an NS/NA exchange upon reception of a data packet with a new source address. In this discussion, you had identified the following attack vulnerability that would appear if SAVI devices did initiate an NS/NA exchange in such a case*: > Triggering an NSOL upon the reception of a data packet for which there > is no binding in the SAVI device could have two potential advantages: > > - first, that can be used to synchronize multiple SAVI devices. this > is > indeed a benefit > > - second that could allow a victim to know if an attacker is trying to > set up a savi state for the victim's address. Now this seems like an > advanatage, but after some thought, i don't think it is. > > Let's suppose that the savi device sends a RSOL packet upon the > reception of a data packet with an unknown source address. Suppose the > SAVI device receives two replies. What can the SAVI device do with > this? > > Actually what happens when we design SAVI such that it sends RSOL > packets, is that the RSOL packet acts as a synchronization point, that > can be used by attacker to claim the address ownership and confuse the > SAVI device. In other words, the whole point of a FCFS appraoch, is > that > requests arrive in the natural. If we introduce the RSOL > synchronization, the order is broken and we can hardly tell who is the > first one to request. (* Replace "RSOL" with "NSOL" in the quotation; this was a typo.) What if SAVI devices blocked NA packets that do not correspond to any of their cached bindings? (I believe this is what Guang was alluding to in one of his earlier messages.) Then, if a SAVI device receives a data packet with a new source address, and if this SAVI device sends a "proxy" NS on behalf of the host sending the packet, an attacker won't be able to interfere by sending an NA for said source address. Blocking illegitimate NA packets would therefore prevent the attack that you have identified, which would exist if SAVI devices let the attacker's NA packet pass. So it would be a way to retain the natural FCFS order of address requests -- where an "address request" comes in form of a data packet with a new source address. Also, blocking illegitimate NA packets should make it impossible that a SAVI device receives two NA packets for its proxy NS. In other words, SAVI devices should use the following rules: - Let NS packets pass. If no corresponding binding exists, create such binding if no responding NA packet received during next X seconds. - Let NA packets pass if and only if a binding exists for the NA's target address. Otherwise, drop the NA packet. - Let data packets pass if a corresponding binding exists. - Send a proxy DAD NS packet if a data packet does not correspond to an existing binding. Create a corresponding binding if no responding NA packet is received during next X seconds. (We would need to discuss whether the SAVI device should drop, or let pass, any data packets received throughout the X seconds during which it waits for NA packets.) Does this make sense? - Christian From christian.vogt@ericsson.com Fri Feb 13 19:43:36 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E5203A67F2 for ; Fri, 13 Feb 2009 19:43:36 -0800 (PST) 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 uHHO7Ri7qQH5 for ; Fri, 13 Feb 2009 19:43:35 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id B11513A6765 for ; Fri, 13 Feb 2009 19:43:35 -0800 (PST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n1E3o7Vi004167; Fri, 13 Feb 2009 21:50:07 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 21:43:41 -0600 Received: from [155.53.229.77] ([155.53.229.77]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 21:43:41 -0600 Message-Id: From: Christian Vogt To: Guang Yao In-Reply-To: <001201c98670$92972d50$b7c587f0$@tsinghua.edu.cn> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 13 Feb 2009 19:43:51 -0800 References: <001201c98670$92972d50$b7c587f0$@tsinghua.edu.cn> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 14 Feb 2009 03:43:41.0718 (UTC) FILETIME=[6DCBE360:01C98E56] Cc: 'SAVI Mailing List' Subject: Re: [savi] Links with both SAVI-capable and legacy switches X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 03:43:36 -0000 [Forked from thread "Binding establishment based on data or control packets?"] On Feb 3, 2009, Guang Yao wrote: > Maybe you are considering the partial deployment, and there can be > spoofing from local nodes. This is a problem. If we specify that the > mechanism should work when partially deployed, many things should be > re-considered. Guang - If I understand you correctly, then what you mean by "partial deployment" is a link with multiple switches, some of which are SAVI-capable, some of which are legacy. Why do you think such a scenario would be problematic? Assuming that SAVI devices allow multiple source addresses per port, then it should be possible for a port to extent to a link segment with legacy switches and multiple hosts. Am I missing something? - Christian From christian.vogt@ericsson.com Fri Feb 13 20:25:12 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F6E23A6A59 for ; Fri, 13 Feb 2009 20:25:12 -0800 (PST) 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 GL8xhFXnKanz for ; Fri, 13 Feb 2009 20:25:11 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 6C11F3A67EC for ; Fri, 13 Feb 2009 20:25:09 -0800 (PST) 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 n1E4VenK010433; Fri, 13 Feb 2009 22:31:40 -0600 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 22:25:15 -0600 Received: from [155.53.229.77] ([155.53.229.77]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 22:25:14 -0600 Message-Id: From: Christian Vogt To: yaoguang In-Reply-To: <001801c98e59$4fe4ad70$efae0850$@tsinghua.edu.cn> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 13 Feb 2009 20:25:24 -0800 References: <001201c98670$92972d50$b7c587f0$@tsinghua.edu.cn> <001801c98e59$4fe4ad70$efae0850$@tsinghua.edu.cn> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 14 Feb 2009 04:25:14.0675 (UTC) FILETIME=[3BB6F030:01C98E5C] Cc: 'SAVI Mailing List' Subject: Re: [savi] Links with both SAVI-capable and legacy switches X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 04:25:12 -0000 Guang Yao wrote: > Many kinds of attacks can be designed in this situation. For instance, > send spoofing NA to prevent other hosts behind SAVI devices to get > stateless addresses. I don't agree. The attack you mention is impossible if SAVI devices drop NA packets for which the target address has no corresponding binding -- as I described in an earlier email. It is irrelevant whether the attacker is the only node on its SAVI switch port, or whether the attacker is on a link segment that connects to a SAVI switch port via legacy switches. - Christian From marcelo@it.uc3m.es Mon Feb 16 00:27: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 8982A3A6C03 for ; Mon, 16 Feb 2009 00:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.824 X-Spam-Level: X-Spam-Status: No, score=-5.824 tagged_above=-999 required=5 tests=[AWL=0.775, 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 2bSATy72HOwF for ; Mon, 16 Feb 2009 00:27:08 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id B68B228C0DC for ; Mon, 16 Feb 2009 00:27:07 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (217.pool85-53-134.dynamic.orange.es [85.53.134.217]) by smtp01.uc3m.es (Postfix) with ESMTP id 36B21B9FF9B; Mon, 16 Feb 2009 09:27:06 +0100 (CET) Message-ID: <49992357.9090303@it.uc3m.es> Date: Mon, 16 Feb 2009 09:27:03 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Christian Vogt References: <19ADF7C7-6E46-47F6-B7AC-2DF82C1F1636@ericsson.com> <20090108042844.jy12ki34coogggko@webcartero01.uc3m.es> <0A3C8CC7DEE0F84C8B0B5E86F61EE522889F1F@eusrcmw721.eamcs.ericsson.se> <49784B7B.8000507@it.uc3m.es> <480E62D1-0D22-479B-9D4E-6AC03B08A8CE@ericsson.com> In-Reply-To: <480E62D1-0D22-479B-9D4E-6AC03B08A8CE@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.5.0.1026-16466.006 Cc: Guang Yao , SAVI Mailing List Subject: Re: [savi] Binding establishment based on data or control packets? 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, 16 Feb 2009 08:27:13 -0000 Hi Chrstian, Christian Vogt escribió: > Marcelo - > > A late comment on our previous discussion on whether SAVI devices should > initiate an NS/NA exchange upon reception of a data packet with a new > source address. In this discussion, you had identified the following > attack vulnerability that would appear if SAVI devices did initiate an > NS/NA exchange in such a case*: > >> Triggering an NSOL upon the reception of a data packet for which there > >> is no binding in the SAVI device could have two potential advantages: >> >> - first, that can be used to synchronize multiple SAVI devices. this is >> indeed a benefit >> >> - second that could allow a victim to know if an attacker is trying to >> set up a savi state for the victim's address. Now this seems like an >> advanatage, but after some thought, i don't think it is. >> >> Let's suppose that the savi device sends a RSOL packet upon the >> reception of a data packet with an unknown source address. Suppose the >> SAVI device receives two replies. What can the SAVI device do with this? >> >> Actually what happens when we design SAVI such that it sends RSOL >> packets, is that the RSOL packet acts as a synchronization point, that >> can be used by attacker to claim the address ownership and confuse the >> SAVI device. In other words, the whole point of a FCFS appraoch, is that >> requests arrive in the natural. If we introduce the RSOL >> synchronization, the order is broken and we can hardly tell who is the >> first one to request. > > (* Replace "RSOL" with "NSOL" in the quotation; this was a typo.) > > What if SAVI devices blocked NA packets that do not correspond to any of > their cached bindings? (I believe this is what Guang was alluding to in > one of his earlier messages.) > > Then, if a SAVI device receives a data packet with a new source address, > and if this SAVI device sends a "proxy" NS on behalf of the host sending > the packet, an attacker won't be able to interfere by sending an NA for > said source address. > > Blocking illegitimate NA packets would therefore prevent the attack that > you have identified, which would exist if SAVI devices let the > attacker's NA packet pass. So it would be a way to retain the natural > FCFS order of address requests -- where an "address request" comes in > form of a data packet with a new source address. Also, blocking > illegitimate NA packets should make it impossible that a SAVI device > receives two NA packets for its proxy NS. > > In other words, SAVI devices should use the following rules: > > - Let NS packets pass. If no corresponding binding exists, create such > binding if no responding NA packet received during next X seconds. > > - Let NA packets pass if and only if a binding exists for the NA's > target address. Otherwise, drop the NA packet. > > - Let data packets pass if a corresponding binding exists. > > - Send a proxy DAD NS packet if a data packet does not correspond to an > existing binding. Create a corresponding binding if no responding > NA packet is received during next X seconds. (We would need to > discuss whether the SAVI device should drop, or let pass, any data > packets received throughout the X seconds during which it waits for > NA packets.) > What about legitimate NA for source addresses _not_ corresponding to an existing SAVI binding? I mean, SAVI bindings are soft state, hence it can and will be discarded at some point. So, it seem perfectly possible to me that a node sends a legitimate NA and that the binding if once existed, has been discarded. Dropping legitimate NA packets seems to be problematic, i think Regards, marcelo > Does this make sense? > > - Christian > > > From marcelo@it.uc3m.es Mon Feb 16 01:30:07 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CB703A6C2F for ; Mon, 16 Feb 2009 01:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=-3.131, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 j9H7eId5KTke for ; Mon, 16 Feb 2009 01:30:06 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 433953A679F for ; Mon, 16 Feb 2009 01:30:05 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (217.pool85-53-134.dynamic.orange.es [85.53.134.217]) by smtp03.uc3m.es (Postfix) with ESMTP id 58F6272C2CE; Mon, 16 Feb 2009 10:30:12 +0100 (CET) Message-ID: <49993224.2000407@it.uc3m.es> Date: Mon, 16 Feb 2009 10:30:12 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: yaoguang References: <19ADF7C7-6E46-47F6-B7AC-2DF82C1F1636@ericsson.com> <20090108042844.jy12ki34coogggko@webcartero01.uc3m.es> <0A3C8CC7DEE0F84C8B0B5E86F61EE522889F1F@eusrcmw721.eamcs.ericsson.se> <49784B7B.8000507@it.uc3m.es> <480E62D1-0D22-479B-9D4E-6AC03B08A8CE@ericsson.com> <49992357.9090303@it.uc3m.es> <002e01c99014$70aa1470$51fe3d50$@tsinghua.edu.cn> In-Reply-To: <002e01c99014$70aa1470$51fe3d50$@tsinghua.edu.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16466.006 Cc: 'SAVI Mailing List' , 'Christian Vogt' Subject: Re: [savi] =?gb2312?b?tPC4tDogQmluZGluZyBlc3RhYmxpc2htZW50IGJhc2Vk?= =?gb2312?b?IG9uIGRhdGEgb3IgY29udHJvbCBwYWNrZXRzPw==?= 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, 16 Feb 2009 09:30:07 -0000 yaoguang escribi¨®: > I mean, SAVI bindings are soft state, hence it can and will be discarded > at some point. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > I don't quite understand your meaning of " SAVI bindings are soft state ". > What i mean by this is that the state is created by the SAVI device as the response of a data or ND packet sent by the host (but that the goal of that packet is not to explicitly create state) and that the responsability of discarding that state is completelly up to the SAVI device i.e. the host will not send a FIN packet to delete the state. In other words, the SAVI device will receive a packet from the host, and will create the SAVI binding The SAVI binding will have a given lifetime. It is likely that the lifetime is extended if the host keeps on sending packets, but if a long period passes and no packets are seen by the SAVI device referring to that address, the SAVI device will unilaterally (i.e. without asking the host) will discard the state. This is essentially needed for memory reasons I guess a reasonable lifetime for a binding would be similar to the dhcp lease lifetime... so, between a day and a week, would seem reasonable to me (probably, if the SAVI device is under a DoS attack, it will need to discard the bindings earlier) So, it is perfectly possible that a host is the rightful owner of an address and that the SAVI device has discarded the binding regards, marcelo > When and why will SAVI bindings be discarded, and how often? > > I think they are somewhat soft, but they are not as soft as bubbles. > > > > From marcelo@it.uc3m.es Mon Feb 16 02:15:25 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E459E28C0E5 for ; Mon, 16 Feb 2009 02:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.483 X-Spam-Level: X-Spam-Status: No, score=-1.483 tagged_above=-999 required=5 tests=[AWL=-2.518, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 o510Rgq-KJlD for ; Mon, 16 Feb 2009 02:15:25 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id A1C2A3A67C0 for ; Mon, 16 Feb 2009 02:15:24 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (217.pool85-53-134.dynamic.orange.es [85.53.134.217]) by smtp03.uc3m.es (Postfix) with ESMTP id 4F1B473179E; Mon, 16 Feb 2009 11:15:29 +0100 (CET) Message-ID: <49993CC0.9090202@it.uc3m.es> Date: Mon, 16 Feb 2009 11:15:28 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: yaoguang , SAVI Mailing List References: <19ADF7C7-6E46-47F6-B7AC-2DF82C1F1636@ericsson.com> <20090108042844.jy12ki34coogggko@webcartero01.uc3m.es> <0A3C8CC7DEE0F84C8B0B5E86F61EE522889F1F@eusrcmw721.eamcs.ericsson.se> <49784B7B.8000507@it.uc3m.es> <480E62D1-0D22-479B-9D4E-6AC03B08A8CE@ericsson.com> <49992357.9090303@it.uc3m.es> <002e01c99014$70aa1470$51fe3d50$@tsinghua.edu.cn> <49993224.2000407@it.uc3m.es> <003201c9901d$72e45df0$58ad19d0$@tsinghua.edu.cn> In-Reply-To: <003201c9901d$72e45df0$58ad19d0$@tsinghua.edu.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16466.006 Subject: Re: [savi] =?gb2312?b?tPC4tDogtPC4tDogQmluZGluZyBlc3RhYmxpc2htZW50?= =?gb2312?b?IGJhc2VkIG9uIGRhdGEgb3IgY29udHJvbCBwYWNrZXRzPw==?= 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, 16 Feb 2009 10:15:26 -0000 mmm, i think you forgot to copy the ml so i added it yaoguang escribi¨®: > Thank your for your kind reply. > > I agree with your idea that there must be a lifetime for a binding entry. > As I know, other than manually configured address, SAC address and DHCP > address have their lifetime prescribed in the RFC doc. > > But why the SAVI device has to delete the bindings unilaterally when the > lifetime expires? > It can simply ask whether the owner is still using the address by a NS > message. > what about the case the node is asleep or standby mode but still has the address configured? what about the case the node is momentarily disconnected from the network? (this can easily happen quite often in a wireless network (at least it happens often to me) IMHO, it is not the best approach to try to build mechanisms to make sure that the binding information is reliably distributed, stored and deleted, but it makes more sense to have in place the mechanisms to be able to recover the information if it is missing. > In the case of DoS attack, because we have an assumption that the anchor is > unspoofable, > i am not sure when we made that assumption In other words, i disagree this is a valid assumption for me, the point is that the SAVI solution will be as secure as the lower layer anchor, but i am not assuming it is not spoofable > the SAVI device can just delete the entries related to the flooding packets. > > But, an attacker can send multiple packets with different source addresses, so you cannot distinguish the legitimate packets from the attack I mean, consider the example as follows. The case is SAVI implemented in ehternet switches. First of all, i understnad that we are planning to support partial deployment scenarios i.e. a scenario where some switches support SAVI and other not. This means that we need to be able to bind multiple source addresses to a given switch port (cause there may be a non savi switch in that port) So, how would you in that cae distinguish an attacker sending packets with different source addresses from legitimate users? Regards, marcelo > Best regards, > Guang > -----ÓʼþÔ­¼þ----- > ·¢¼þÈË: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > ·¢ËÍʱ¼ä: 2009Äê2ÔÂ16ÈÕ 17:30 > ÊÕ¼þÈË: yaoguang > ³­ËÍ: 'Christian Vogt'; 'SAVI Mailing List' > Ö÷Ìâ: Re: ´ð¸´: Binding establishment based on data or control packets? > > yaoguang escribi¨®: > >> I mean, SAVI bindings are soft state, hence it can and will be discarded >> at some point. >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> I don't quite understand your meaning of " SAVI bindings are soft state ". >> >> > > What i mean by this is that the state is created by the SAVI device as > the response of a data or ND packet sent by the host (but that the goal > of that packet is not to explicitly create state) and that the > responsability of discarding that state is completelly up to the SAVI > device i.e. the host will not send a FIN packet to delete the state. > > In other words, the SAVI device will receive a packet from the host, and > will create the SAVI binding > The SAVI binding will have a given lifetime. > It is likely that the lifetime is extended if the host keeps on sending > packets, but if a long period passes and no packets are seen by the SAVI > device referring to that address, the SAVI device will unilaterally > (i.e. without asking the host) will discard the state. This is > essentially needed for memory reasons > > I guess a reasonable lifetime for a binding would be similar to the dhcp > lease lifetime... so, between a day and a week, would seem reasonable to me > > (probably, if the SAVI device is under a DoS attack, it will need to > discard the bindings earlier) > > So, it is perfectly possible that a host is the rightful owner of an > address and that the SAVI device has discarded the binding > > regards, marcelo > > >> When and why will SAVI bindings be discarded, and how often? >> >> I think they are somewhat soft, but they are not as soft as bubbles. >> >> >> >> >> > > > > From christian.vogt@ericsson.com Mon Feb 16 20:12:53 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 EBE353A6883 for ; Mon, 16 Feb 2009 20:12:53 -0800 (PST) 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 Pf8tgf-cNbDG for ; Mon, 16 Feb 2009 20:12:53 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 257463A677C for ; Mon, 16 Feb 2009 20:12:53 -0800 (PST) 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 n1H4CwLY004069; Mon, 16 Feb 2009 22:12:59 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 22:12:58 -0600 Received: from [155.53.229.77] ([155.53.229.77]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 22:12:58 -0600 Message-Id: <66D5F2EC-C9DB-4D70-8EA2-F6F0CB97191A@ericsson.com> From: Christian Vogt To: marcelo bagnulo braun In-Reply-To: <49992357.9090303@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 16 Feb 2009 20:12:58 -0800 References: <19ADF7C7-6E46-47F6-B7AC-2DF82C1F1636@ericsson.com> <20090108042844.jy12ki34coogggko@webcartero01.uc3m.es> <0A3C8CC7DEE0F84C8B0B5E86F61EE522889F1F@eusrcmw721.eamcs.ericsson.se> <49784B7B.8000507@it.uc3m.es> <480E62D1-0D22-479B-9D4E-6AC03B08A8CE@ericsson.com> <49992357.9090303@it.uc3m.es> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 17 Feb 2009 04:12:58.0252 (UTC) FILETIME=[0402F4C0:01C990B6] Cc: Guang Yao , SAVI Mailing List Subject: Re: [savi] Binding establishment based on data or control packets? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 04:12:54 -0000 Marcelo - > What about legitimate NA for source addresses _not_ corresponding to > an > existing SAVI binding? I mean, SAVI bindings are soft state, hence it > can and will be discarded at some point. So, it seem perfectly > possible > to me that a node sends a legitimate NA and that the binding if once > existed, has been discarded. Dropping legitimate NA packets seems to > be > problematic, i think Yes, you are right; this is a problem. In fact, there are more variants of the case where the legitimate address owner's SAVI device does not have a binding for the address in question: It can also happen if the address in question was manually configured into the legitimate address owner, and the legitimate address owner has never used the address and hence never created a binding in its SAVI device. (This is a situation that Guang had described earlier.) Obviously, these cases need to be handled. Suggestions? Do we need to adopt manual configuration of SAVI bindings for manually configured addresses? - Christian From marcelo@it.uc3m.es Tue Feb 17 01:00:47 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D490C3A6B91 for ; Tue, 17 Feb 2009 01:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.311 X-Spam-Level: X-Spam-Status: No, score=-5.311 tagged_above=-999 required=5 tests=[AWL=1.288, 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 a-pWRsTnHCgi for ; Tue, 17 Feb 2009 01:00:47 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id A987D3A6A0F for ; Tue, 17 Feb 2009 01:00:46 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (206.pool85-53-136.dynamic.orange.es [85.53.136.206]) by smtp03.uc3m.es (Postfix) with ESMTP id 40E59731899; Tue, 17 Feb 2009 10:00:54 +0100 (CET) Message-ID: <499A7CC6.7090705@it.uc3m.es> Date: Tue, 17 Feb 2009 10:00:54 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Christian Vogt References: <19ADF7C7-6E46-47F6-B7AC-2DF82C1F1636@ericsson.com> <20090108042844.jy12ki34coogggko@webcartero01.uc3m.es> <0A3C8CC7DEE0F84C8B0B5E86F61EE522889F1F@eusrcmw721.eamcs.ericsson.se> <49784B7B.8000507@it.uc3m.es> <480E62D1-0D22-479B-9D4E-6AC03B08A8CE@ericsson.com> <49992357.9090303@it.uc3m.es> <66D5F2EC-C9DB-4D70-8EA2-F6F0CB97191A@ericsson.com> In-Reply-To: <66D5F2EC-C9DB-4D70-8EA2-F6F0CB97191A@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-16468.005 Cc: Guang Yao , SAVI Mailing List Subject: Re: [savi] Binding establishment based on data or control packets? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 09:00:47 -0000 Christian Vogt escribió: > Marcelo - > >> What about legitimate NA for source addresses _not_ corresponding to an >> existing SAVI binding? I mean, SAVI bindings are soft state, hence it >> can and will be discarded at some point. So, it seem perfectly possible >> to me that a node sends a legitimate NA and that the binding if once >> existed, has been discarded. Dropping legitimate NA packets seems to be >> problematic, i think > > Yes, you are right; this is a problem. In fact, there are more variants > of the case where the legitimate address owner's SAVI device does not > have a binding for the address in question: It can also happen if the > address in question was manually configured into the legitimate address > owner, and the legitimate address owner has never used the address and > hence never created a binding in its SAVI device. (This is a situation > that Guang had described earlier.) Obviously, these cases need to be > handled. Ok, we have two issues here: how to handle manually configured issues how to make the binding distribution protocol work Now, for the issue about manually configured addresses, for IPv6, there is no problem I re read rfc2462 and it states: 5.4. Duplicate Address Detection Duplicate Address Detection is performed on unicast addresses prior to assigning them to an interface whose DupAddrDetectTransmits variable is greater than zero. Duplicate Address Detection MUST take place on all unicast addresses, regardless of whether they are obtained through stateful, stateless or manual configuration, with the exception of the following cases: - Duplicate Address Detection MUST NOT be performed on anycast addresses. - Each individual unicast address SHOULD be tested for uniqueness. However, when stateless address autoconfiguration is used, address uniqueness is determined solely by the interface identifier, assuming that subnet prefixes are assigned correctly (i.e., if all of an interface's addresses are generated from the same identifier, either all addresses or none of them will be duplicates). Thus, for a set of addresses formed from the same interface identifier, it is sufficient to check that the link- local address generated from the identifier is unique on the link. In such cases, the link-local address MUST be tested for uniqueness, and if no duplicate address is detected, an implementation MAY choose to skip Duplicate Address Detection for additional addresses derived from the same interface identifier. So, manual configured addresses are not an issue, cause the perform the DAD procedure, so the savi device learn about them through it. Interestingly, we may need to do something with the global addresses if the DAD have been performed for the link local. But i guess the SAVI device could create binding for the associated global addresses upon the DAD for the link local address (note that if the address is used from a different lower layer anchor, the savi device will check the exisitng binding, which i guess is what we want) So, i think there is no problem here The problem is how to build the binding distribution protocol wihtout introducing new vulnerabilities. And at this point, i don't see any obvious answer beyond having some configuration in the savi devices (e.g. a shared key) which is certainly not the most attractive approach Regards, marcelo > > Suggestions? Do we need to adopt manual configuration of SAVI bindings > for manually configured addresses? > > - Christian > > > From christian.vogt@ericsson.com Mon Feb 23 16:03:44 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 817433A6A9B for ; Mon, 23 Feb 2009 16:03:44 -0800 (PST) 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 TuvHhFjdatIJ for ; Mon, 23 Feb 2009 16:03:43 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id AD4913A63D3 for ; Mon, 23 Feb 2009 16:03:43 -0800 (PST) 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 n1O040Yj028973; Mon, 23 Feb 2009 18:04:00 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Feb 2009 18:03:58 -0600 Received: from [155.53.229.77] ([155.53.229.77]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Feb 2009 18:03:58 -0600 Message-Id: <40D4658D-D051-42CE-93BB-819F23D2C4E7@ericsson.com> From: Christian Vogt To: yaoguang , Marcelo Bagnulo Braun In-Reply-To: <000001c9917c$5275bdb0$f7613910$@tsinghua.edu.cn> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 23 Feb 2009 16:04:01 -0800 References: <19ADF7C7-6E46-47F6-B7AC-2DF82C1F1636@ericsson.com> <20090108042844.jy12ki34coogggko@webcartero01.uc3m.es> <0A3C8CC7DEE0F84C8B0B5E86F61EE522889F1F@eusrcmw721.eamcs.ericsson.se> <49784B7B.8000507@it.uc3m.es> <480E62D1-0D22-479B-9D4E-6AC03B08A8CE@ericsson.com> <49992357.9090303@it.uc3m.es> <002e01c99014$70aa1470$51fe3d50$@tsinghua.edu.cn> <49993224.2000407@it.uc3m.es> <003201c9901d$72e45df0$58ad19d0$@tsinghua.edu.cn> <49993CC0.9090202@it.uc3m.es> <000001c9917c$5275bdb0$f7613910$@tsinghua.edu.cn> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 24 Feb 2009 00:03:58.0353 (UTC) FILETIME=[64078810:01C99613] Cc: SAVI Mailing List Subject: Re: [savi] Binding establishment based on data or control packets? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 00:03:44 -0000 Guang Yao wrote: > If the SAVI device asks the node before deleting bindings, it is > safe in > most cases and only fails in some specified examples. If the SAVI > device > doesn't ask the node and delete bindings unilaterally, it may fail > with > great possibility. So I don't think this is a good example to prove > querying the node is useless. I think the conclusion regarding the use of probing prior to removing soft-state bindings should be that (1) SAVI devices do probe to minimize premature binding removal, but that (2) we cannot rely on a binding to exist if a host is using the bound address. In other words, the probing can only be an optimization. Does this make sense? - Christian