From jeanmichel.combes@gmail.com Tue Dec 6 12:32:43 2011 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F028D21F8B13 for ; Tue, 6 Dec 2011 12:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OQrToDTA3Du for ; Tue, 6 Dec 2011 12:32:43 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 72B5921F8B12 for ; Tue, 6 Dec 2011 12:32:43 -0800 (PST) Received: by yenm7 with SMTP id m7so269063yen.31 for ; Tue, 06 Dec 2011 12:32:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=FGC3wTybwzymenBVxPBHCHfeeFeFcEXdU/8hmp42ZBA=; b=KwX4X+I+gpreXOMi5JkEtt8H75xHmBIJQ/q5DsDs6P4IrDg2N/ELbs8wBNjFi1lEBE mNv4rVl5iQyA1pQ62Hg/MEoo18K7v+EgnWWelPvTPaNUk6WiRIfFgIa2yiKJ/aVGgDIx 1LmoARkKbdmoSJrSA3yhEwX042AzuxGQ78RMk= MIME-Version: 1.0 Received: by 10.236.173.131 with SMTP id v3mr22226758yhl.112.1323203562944; Tue, 06 Dec 2011 12:32:42 -0800 (PST) Received: by 10.146.243.20 with HTTP; Tue, 6 Dec 2011 12:32:42 -0800 (PST) Date: Tue, 6 Dec 2011 21:32:42 +0100 Message-ID: From: Jean-Michel Combes To: SAVI Mailing List Content-Type: text/plain; charset=ISO-8859-1 Subject: [savi] [IETF82] Draft minutes X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 20:32:44 -0000 Folks, please find the draft minutes of the SAVI WG for the last IETF meeting here: http://www.ietf.org/proceedings/82/minutes/savi.txt If you have comments/questions/corrections, don't hesitate to reply to this email (deadline: 2011-12-15). Thanks to Pascal who accepted to be volunteer as minutes taker! Best regards. JMC. From jeanmichel.combes@gmail.com Tue Dec 6 12:39:17 2011 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF71A21F8BF9 for ; Tue, 6 Dec 2011 12:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=-1.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SUBJ_ALL_CAPS=2.077, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5APO7XisxTK for ; Tue, 6 Dec 2011 12:39:17 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE4B21F853E for ; Tue, 6 Dec 2011 12:39:13 -0800 (PST) Received: by ggnk5 with SMTP id k5so3495751ggn.31 for ; Tue, 06 Dec 2011 12:39:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=FI3dU4fv7NCtLuYuzQ18fbjyEaJzMGoEB04l0qE+0HU=; b=dLSZYOCahxtmgWXM/vh1xl5Z55C9PSy356BrCWrwAawphEhoGU8MNRtweynz5bQ6CN lS/yvxtaYOLaMz5iU2Za6oXWYI5qEILQYLNfqNO+z0ad5BRQI8c3gcPD7ChIQ1DbFWmr bW3B6dU1qeoD6KX021PZiEKhte4LU7wdauxc4= MIME-Version: 1.0 Received: by 10.101.112.10 with SMTP id p10mr3537864anm.80.1323203951919; Tue, 06 Dec 2011 12:39:11 -0800 (PST) Received: by 10.146.243.20 with HTTP; Tue, 6 Dec 2011 12:39:11 -0800 (PST) Date: Tue, 6 Dec 2011 21:39:11 +0100 Message-ID: From: Jean-Michel Combes To: SAVI Mailing List Content-Type: text/plain; charset=ISO-8859-1 Subject: [savi] [WGLC] MIX SAVI X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 20:39:17 -0000 Folks, I initiate a 3 weeks (due to Christmas holidays) WGLC for the MIX SAVI draft (http://tools.ietf.org/html/draft-ietf-savi-mix-01). Don't hesitate to read this document and to provide either comments or your agreement to move forward it. Thanks in advance. Best regards. JMC. From jeanmichel.combes@gmail.com Tue Dec 6 16:18:55 2011 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4111F0C4A for ; Tue, 6 Dec 2011 16:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.08 X-Spam-Level: X-Spam-Status: No, score=-103.08 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mT5hES3gaC4t for ; Tue, 6 Dec 2011 16:18:54 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABB21F0C35 for ; Tue, 6 Dec 2011 16:18:54 -0800 (PST) Received: by yenm7 with SMTP id m7so486979yen.31 for ; Tue, 06 Dec 2011 16:18:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+0i29nA1e0SzQLLU9eMiZwODIjD9xZJ1Jqwe17cU2wk=; b=XAq2outjm9XxOij8o2INYbiVpW+SMh0Lk6L5+Wx4dBEKbd2T8xy8bE77vsGhD00azf 9wOy4UloJwTF30VGqbWDhB4E9DZ6fqRVtQuR277q8qaIFwn0MrZIVAaKwWP6xroZVtz3 hevH5FmIHKwpXbXb8mDtkXuQsDZmBDXafImsY= MIME-Version: 1.0 Received: by 10.236.76.136 with SMTP id b8mr24814296yhe.9.1323217133866; Tue, 06 Dec 2011 16:18:53 -0800 (PST) Received: by 10.146.243.20 with HTTP; Tue, 6 Dec 2011 16:18:53 -0800 (PST) In-Reply-To: <4ED3D419.5020801@joelhalpern.com> References: <201109241504437330313@mail.tsinghua.edu.cn> <4ED3D419.5020801@joelhalpern.com> Date: Wed, 7 Dec 2011 01:18:53 +0100 Message-ID: From: Jean-Michel Combes To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: SAVI Mailing List , xuke@mail.tsinghua.edu.cn Subject: Re: [savi] [SAVI]possible future works X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 00:18:55 -0000 Hi, 2011/11/28 Joel M. Halpern : [snip] > > If there are problems or gaps in the existing practice, then it seem wort= h > looking to determine if we can improve the situation. =A0But I would expe= ct > some description of the source of those problems. I second this point: drafts explaining the problems are the minimum condition for a discussion. Best regards. JMC. > > Yours, > Joel M. Halpern > > PS: While not practiced as often as it should, it is considered a mark of > success for an IETF working group to deliver its output and either close = or > quiesce. > > > On 9/24/2011 3:06 AM, xuke wrote: >> >> Dear SAVI WG members >> >> There is no doubt, SAVI has made significant contribution for IP source >> address validation and anti-spoofing in the scenario of pure IPv6 Ethern= et >> access subnet. However, there are many efforts need SAVI workgroup to ma= ke >> and there are many works to be done for SAVI prompting, there are some >> possible future works I suggest: >> (1) =A0 =A0 Considering there would be a long period to transit IPv4 to = IPv6, >> workgroup should study SAVI how to work in the scenarios of 4 over 6, >> light-weighted 4 over 6 and NAT4-4-4 etc. >> (2) =A0 =A0 Applying SAVI technology into non-Ethernet access subnet >> circumstance. In the matter of fact, many netizens still use PPoE, ADSL = and >> ISDN technology to access Internet. It means a lot to telecommunication >> carriers for applying SAVI into those scenarios. >> (3) =A0 =A0 Even though SAVI has a preliminary application in WiFi scena= rio, >> its application in mobile communication(3G,LTE etc.) scenario still need= to >> be exploited. >> >> xuke >> >> _______________________________________________ >> 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 jeanmichel.combes@gmail.com Tue Dec 6 16:20:22 2011 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF0B11E8082 for ; Tue, 6 Dec 2011 16:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.253 X-Spam-Level: X-Spam-Status: No, score=-103.253 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8OfN03qyfBE for ; Tue, 6 Dec 2011 16:20:22 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2184C11E8081 for ; Tue, 6 Dec 2011 16:20:22 -0800 (PST) Received: by yenm7 with SMTP id m7so487868yen.31 for ; Tue, 06 Dec 2011 16:20:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=qACTaQe4pcMwsebxZvvtcnPrZggb+nCbRP071lpqUgI=; b=YFxRVcmwMiZhb7fIU6kzngvRA5OOgodLA5zHP0/FwsxIL8qR5gPYN8zUjlJcfS22QJ 1A3jexh+MNnz3/ojYzZRm3Gp6yazys9NGhbWO76MMF2BRuPFJIW5yTPHExR3sLX1YQsZ doTX1VcuFmhucZF/HjsiyxDIMLmxLJNnz4J0w= MIME-Version: 1.0 Received: by 10.236.76.136 with SMTP id b8mr24819031yhe.9.1323217221799; Tue, 06 Dec 2011 16:20:21 -0800 (PST) Received: by 10.146.243.20 with HTTP; Tue, 6 Dec 2011 16:20:21 -0800 (PST) Date: Wed, 7 Dec 2011 01:20:21 +0100 Message-ID: From: Jean-Michel Combes To: SAVI Mailing List Content-Type: text/plain; charset=ISO-8859-1 Subject: [savi] [IETF83] Important dates X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 00:20:22 -0000 Hi, just a friendly reminder (due to Christmas holidays, deadlines will arrive quickly): 2011-12-19 (Monday): Working Group and BOF scheduling begins. To request a Working Group session, use the IETF Meeting Session Request Tool. 2012-01-30 (Monday): Cutoff date for requests to schedule Working Group meetings at 17:00 PT (UTC -8). To request a Working Group session, use the IETF Meeting Session Request Tool. As said during the last SAVI meeting, if no real interest regarding topics for a potential rechartering on the ML, no meeting during the next IETF meeting and the WG will close as soon as current WG docs will be finalized. Hope that helps. Best regards. JMC. From yaoguang.china@gmail.com Mon Dec 12 09:53:05 2011 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B68921F8B84 for ; Mon, 12 Dec 2011 09:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v78Hbl0rI0Xs for ; Mon, 12 Dec 2011 09:53:02 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB91021F8B70 for ; Mon, 12 Dec 2011 09:53:01 -0800 (PST) Received: by ggnk5 with SMTP id k5so6580979ggn.31 for ; Mon, 12 Dec 2011 09:53:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=0V4vXFcsrclknlvzUP+J3gF40XQlKdZ2M0IkmqrqKoI=; b=h4AN1KF71syO7dfW53kr0/BKjewzJkrJgzPmgI5I9i0BEn1oWIGsq1DCCFA2Xy324e 4GdRkJjzJFwqfK73/wjxXG5P6Q9UfOkVqTg94pdtWD53kaYwI/oze8Ddw6n48KpwXYx7 fW/sm3ltMJ7laHOU9TkPlcGGQgnnue8kolazQ= Received: by 10.182.218.100 with SMTP id pf4mr3253086obc.12.1323712381383; Mon, 12 Dec 2011 09:53:01 -0800 (PST) Received: from yaoguangPC (th213181.ip.tsinghua.edu.cn. [59.66.213.181]) by mx.google.com with ESMTPS id d3sm7201853obp.5.2011.12.12.09.52.53 (version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 09:52:57 -0800 (PST) From: "Guang Yao" To: "'Jari Arkko'" , "'Jun Bi'" References: <4E7A2FB4.9080303@piuha.net> In-Reply-To: <4E7A2FB4.9080303@piuha.net> Date: Tue, 13 Dec 2011 01:52:44 +0800 Message-ID: <013d01ccb8f6$dcae5560$960b0020$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_013E_01CCB939.EAE23730" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI1A3HNfp1/0jGOb4Aue0d2P0We0AHADY3ZlPm/8WA= Content-Language: zh-cn Cc: 'SAVI Mailing List' Subject: Re: [savi] AD review of draft-ietf-savi-dhcp-10 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 17:53:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_013E_01CCB939.EAE23730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Jari, Thank you very much for the review. Sorry for this late reply. We have modified the document as the attachment. And I try to answer your questions as follows inline. Looking forward to your reply. Best regards, Guang > -----Original Message----- > From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Jari > Arkko > Sent: Thursday, September 22, 2011 2:41 AM > To: Jun Bi > Cc: SAVI Mailing List > Subject: [savi] AD review of draft-ietf-savi-dhcp-10 > > I have reviewed this draft. I have to apologize that it has taken so long, and I > know you are waiting for me on a number of other open issues in the working > group. I've been more busy than usual with day job, as well as having many > documents in my review queue. > > The draft is in pretty good shape, but there are a couple of issues that we still > need to work on. > > Technical: > > We need to have the DHC WG folks review this in detail. I am not expert > enough in verifying that everything is correct, and while we've had some DHCP > folk participate the work, I think more review would be useful. This is a general > principle in fact with all DHCP-related work in the IETF: we often like to run > parallel working group last calls in the home working group of a draft as well as > in DHC WG. I have asked for this review to be started now. > > I do not understand how the draft works with DNAv4 (RFC 4436) and the DHCP > rebinding procedure. The draft seems to be saying that it does not support L2 > mobility (either through something like radio moving to a different AP on a > WLAN) or through physical re-attachment on a different port. I think that it is > such a basic requirement that we need to support that. > > Couldn't the SAVI device follow the new messages on the DHCP as well as the > ARP messages from RFC 4436? > > Would making Section 8 process mandatory to implement help? [Guang Yao] We do want to support l2 mobility in IPv4. However, we find it is hard to distinguish an attack which uses reachability test to obtain binding belonging to another host from a normal l 2 movement. The message received by the SAVI device can be exactly the same. We decide the handle only one scenario, as discussed in section 11: "To be compatible with DNAv4 [RFC4436], after a binding anchor turns off-link, if reachability test message specified in section 2.1.1 of [RFC4436] is received from another binding anchor which turns on-link afterwards, the binding MAY be migrated to the latter binding anchor. The binding recovery procedure specified in section 8.1 MUST be performed to ensure the binding migration is reasonable." And the issue is discussed in section 13.6: "DNA [RFC4436] [RFC6059] is designed to decrease the handover latency after re-attachment to the same network. DNA mainly relies on sending unicast Neighbor Solicitation/ARP message to detect whether a previously configured address is still valid. In Simple DNAv6 [RFC6059], the DHCP exchange step is required, thus it is compatible with SAVI. However, in DNAv4 [RFC4436], the DHCP exchange procedure in current standards is not mandatory. If a binding is set up only through snooping the reachability test message, the binding can be invalid. For example, an attacker can perform reachability test with address bound to another host. If binding is migrated to the attacker, the attacker can successful obtain the binding from the victim. For security, in this mechanism, a binding can be migrated to a different binding anchor only if the previous binding anchor is off-link and the new binding anchor is on-link afterwards, as specified in section 11. If a binding anchor is on-link, its bindings will never migrate to another binding anchor. If a DNAv4 node moves without triggering link-down/up event on SAVI device, the binding will not migrate. In this case, the DNAv4 node MUST perform DHCP exchange to recover binding after re-attachment. But binding can also be recovered based on the binding recovery procedure specified in section 8.1, if the SAVI-BindRecovery attribute is set on the new binding anchor." Though making binding recovery process mandatory can help, it also brings risks. Anyway, the address is not assigned by DHCP server to the host; in fact, we just suppose the host is able to use the address because the address has been assigned by the DHCP server to someone on the link and it is not currently used by any other node. IMHO, the savi mechanism for DHCP address must strictly follow the DHCP exchange procedure. If binding is also set up based on snooping other messages, the benefit and the risk must be trade-off carefully. > > > Because > > no lease time will be contained in the REPLY from DHCP server, the > > SAVI device MUST send a LEASEQUERY [RFC5007 > > ] message querying by IP address > > to All_DHCP_Relay_Agents_and_Servers multicast address > > [RFC3315 ] or a configured server > address. > > This seems problematic. Can't the lease time be recovered from earlier > messages and stored in the SAVI data structures? Note that RFC 5007 requires > typically special security solutions (e.g., IPsec) and sets high requirements on > what the SAVI device must do with the DHCP server. > [Guang Yao] It's is a good idea to recovery lease time from bst if the host moves only on the same SAVI device. We have changed the text: "Because no lease time will be contained in the REPLY from DHCP server, the SAVI device MUST lookup in BST to determine whether there is an entry with the same address. If there is such an entry, it can be a local movement and the lifetime can be recovered from the entry. If there is not, the SAVI device MUST send a LEASEQUERY [RFC5007] message querying by IP address to All_DHCP_Relay_Agents_and_Servers multicast address [RFC3315] or a configured server address." And we change the text in 7.4.2 correspondingly: "If the Reply message is of Status Code Success, and there is an entry with the same address, set the Lifetime to be the remaining Lifetime of the existing entry, and remove the existing entry. If there is no entry with the same address, set the Lifetime of corresponding entry to MAX_LEASEQUERY_DELAY." > > Discard IPv6 Neighbor Solicitation (NS) and IPv4 gratuitous ARP > > whose source is not an address bound with the corresponding binding > > anchor. > > Please document if this has any implications for DNAv6 (RFC 6059). [Guang Yao] I don't think there is any implication for DNAv6. DNAv6 uses link local address to send detection message. Link local address is not assigned by DHCP and the corresponding binding and the implication should be specified in other document (maybe the mix document). > > > Whenever a binding anchor with attribute SAVI-Validation turns down, > > set a timer with OFFLINK_DELAY. Until the timer becomes zero, the > > bindings with the binding anchor SHOULD be kept. As an exception, to > > handle movement, if receiving DAD Neighbor Solicitation/Gratuitous > > ARP request targeting at the address during OFFLINK_DELAY, the entry > > MAY be removed. > > > > ... > > > > OFFLINK_DELAY 2s > > This seems awfully short time, what is the number based on? Do we know > what computers that go to short suspend state do when they wake up? Do > they re-DHCP, use DNAv4/6, or just continue if the period was short enough? > [Guang Yao] Previously we consider if the host is dis-connected for a certain time, its interface will re-initialized. Thus there is no need to keep the binding long. If considering L2 mobility, the require time must be more than T(movement)+T(interface initilization)+T(DHCP/DNA) to keep the entry until the host finish address configuration. We decide change it to 30 seconds. > Editorial: > > > Figure 2 Instance of BST > > First use of the abbreviation BST. Please expand somewhere. [Guang Yao] Done. in the title of the section. > > > Figure 3 Instance of FT > > As above. [Guang Yao] Done. in the title of the section. > > > If there is enough binding > > entry resource, > > resources [Guang Yao] Done > > > If the binding anchor is switch port, there can be vulnerability > > in > > > > a switch port [Guang Yao] Done. > > Jari > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi ------=_NextPart_000_013E_01CCB939.EAE23730 Content-Type: text/plain; name="draft-ietf-savi-dhcp-11.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-savi-dhcp-11.txt" SAVI J. Bi, J. Wu, G. Yao=0A= Internet Draft Tsinghua Univ.=0A= Intended status: Standard Tracks F. Baker=0A= Expires: June 2012 Cisco Systems=0A= December 13, 2011=0A= =0A= =0A= SAVI Solution for DHCP=0A= draft-ietf-savi-dhcp-11.txt=0A= =0A= =0A= Status of this Memo=0A= =0A= This Internet-Draft is submitted to IETF in full conformance with the=0A= provisions of BCP 78 and BCP 79. This document may not be modified,=0A= and derivative works of it may not be created, except to publish it=0A= as an RFC and to translate it into 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 other=0A= 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 June 7, 2012.=0A= =0A= Copyright Notice=0A= =0A= Copyright (c) 2011 IETF Trust and the persons identified as the=0A= document authors. All rights reserved.=0A= =0A= This document is subject to BCP 78 and the IETF Trust's Legal=0A= Provisions Relating to IETF Documents=0A= (http://trustee.ietf.org/license-info) in effect on the date of=0A= publication of this document. Please review these documents=0A= carefully, as they describe your rights and restrictions with respect=0A= to this document. Code Components extracted from this document must=0A= include Simplified BSD License text as described in Section 4.e of=0A= =0A= =0A= =0A= =0A= Bi Expires June 13, 2012 [Page 1]=0A= =0C=0A= Internet-Draft savi-dhcp December 2011=0A= =0A= =0A= the Trust Legal Provisions and are provided without warranty as=0A= described in the Simplified BSD License.=0A= =0A= Abstract=0A= =0A= This document specifies the procedure for creating bindings between a=0A= DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and a=0A= binding anchor [I-D.ietf-savi-framework] on SAVI (Source Address=0A= Validation Improvements) device. The bindings can be used to filter=0A= packets generated on the local link with forged source IP address.=0A= =0A= Table of Contents=0A= =0A= =0A= Copyright Notice ............................................... 1=0A= Abstract ....................................................... 2=0A= 1. Introduction ................................................ 3=0A= 2. Conventions used in this document............................ 4=0A= 3. Terminology ................................................. 4=0A= 4. SAVI-DHCP Scenario .......................................... 4=0A= 5. Data Structures ............................................. 5=0A= 5.1. Control Plane Data Structure: Binding State Table (BST). 5=0A= 5.2. Data Plane Data Structure: Filtering Table (FT)......... 6=0A= 5.3. Mapping Table from Link Layer Address to Binding Anchor. 6=0A= 6. Binding Anchor Attributes.................................... 7=0A= 6.1. No Attribute ........................................... 7=0A= 6.2. SAVI-Validation Attribute............................... 7=0A= 6.3. SAVI-DHCP-Trust Attribute............................... 7=0A= 6.4. SAVI-SAVI Attribute..................................... 8=0A= 6.5. SAVI-BindRecovery Attribute............................. 8=0A= 7. Binding Set Up .............................................. 8=0A= 7.1. Rationale .............................................. 9=0A= 7.2. Binding States Description ............................. 9=0A= 7.3. Events ................................................. 9=0A= 7.3.1. Timer Expiration Event............................. 9=0A= 7.3.2. Control Message Arriving Events ................... 9=0A= 7.4. Process of DHCP Packet Snooping ....................... 10=0A= 7.4.1. From NO_BIND to Other States ..................... 10=0A= 7.4.1.1. Trigger Event................................ 10=0A= 7.4.1.2. Following Actions............................ 10=0A= 7.4.2. From INIT_BIND to Other States ................... 12=0A= 7.4.2.1. Trigger Event................................ 12=0A= 7.4.2.2. Following Actions............................ 12=0A= 7.4.3. From BOUND to Other States ....................... 13=0A= 7.4.3.1. Trigger Event................................ 13=0A= 7.4.3.2. Following Actions............................ 13=0A= 7.5. State Machine of DHCP Snooping ........................ 14=0A= =0A= =0A= Bi Expires June 13, 2012 [Page 2]=0A= =0C=0A= Internet-Draft savi-dhcp December 2011=0A= =0A= =0A= 8. Supplemental Binding Process................................ 15=0A= 8.1. Binding Recovery Process............................... 15=0A= 9. Filtering Specification..................................... 16=0A= 9.1. Data Packet Filtering.................................. 17=0A= 9.2. Control Packet Filtering............................... 17=0A= 10. State Restoration ......................................... 18=0A= 11. Handle Binding Anchor Off-link Event ...................... 18=0A= 12. Constants ................................................. 18=0A= 13. Security Considerations.................................... 19=0A= 13.1. Security Problem about Binding Triggered by=0A= EVE_DHCP_REPLY_NULL ........................................ 19=0A= 13.2. Binding Number Limitation............................. 20=0A= 13.3. Risk from Link Layer Routing Dynamic ................. 20=0A= 13.4. Duplicate Bindings of Same Address ................... 21=0A= 13.5. Security Problems about Binding Recovery Process...... 21=0A= 13.6. Compatibility with DNA (Detecting Network Attachment). 21=0A= 13.7. Residual Threats...................................... 22=0A= 14. IANA Considerations........................................ 22=0A= 15. References ................................................ 23=0A= 15.1. Normative References.................................. 23=0A= 15.2. Informative References................................ 24=0A= 16. Acknowledgments ........................................... 24=0A= 17. Change Log ................................................ 25=0A= =0A= 1. Introduction=0A= =0A= This document describes the procedure for creating bindings between=0A= DHCP addresses and binding anchor on SAVI device [I-D.ietf-savi-=0A= framework]. The removal and restoration of the bindings are also=0A= specified in this document.=0A= =0A= Bindings can be used to filter or identify packets with forged source=0A= IP address. Section 9 suggests usage of these bindings for common=0A= practice.=0A= =0A= The mechanism specified in this document is designed to provide a=0A= binding anchor granularity validation, as a supplement to BCP38=0A= [BCP38]. This mechanism is deployed on the access device (including=0A= access switch, wireless access point/controller, etc), and performs=0A= mainly DHCP snooping to set up bindings between IP addresses assigned=0A= by DHCP and corresponding binding anchors. The binding process is=0A= inspired by the work of IP Source Guard [IP Source Guard].=0A= =0A= This solution is designed for stateful DHCP scenario [RFC2131],=0A= [RFC3315]. In stateless DHCP scenarios [RFC3736], a node must have=0A= obtained its IPv6 addresses through some other mechanisms and so the=0A= address of the client SHOULD be bound based on other SAVI solutions=0A= =0A= =0A= Bi Expires June 13, 2012 [Page 3]=0A= =0C=0A= Internet-Draft savi-dhcp December 2011=0A= =0A= =0A= This solution is primarily designed for a pure DHCP scenario in which=0A= only DHCP address is legitimate global address. How to use this=0A= mechanism in multiple address assignments scenario is discussed in=0A= [I-D.ietf-savi-mix].=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", "NOT RECOMMENDED", "MAY", and=0A= "OPTIONAL" in this document are to be interpreted as described in=0A= [RFC2119].=0A= =0A= 3. Terminology=0A= =0A= Lease time: Lease time in IPv4 [RFC2131] and valid lifetime in=0A= IPv6 [RFC3315]=0A= =0A= 4. SAVI-DHCP Scenario=0A= =0A= Figure 1 shows the main elements in a DHCP network. At least one DHCP=0A= server must be deployed in the network, and DHCP relay may be used to=0A= relay message between client and server. Multiple SAVI devices and=0A= non-SAVI devices can co-exist on link. A SAVI device can be connected=0A= to DHCP client, DHCP relay (even DHCP server), SAVI device and non-=0A= SAVI device.=0A= =0A= Other address assignment mechanisms may be also used in such a=0A= network. However, this solution is primarily designed for a pure DHCP=0A= scenario, in which only DHCP servers can assign valid global address.=0A= =0A= Note that in IPv6 environment, DHCP procedure cannot be performed on=0A= an interface without a link-local address pre-assigned. Thus, to make=0A= this solution work, a SAVI solution for link-local address MUST be=0A= enabled. Knowing that (1) in IPv6 environment, DHCPv6 exchanges=0A= mainly use link local addresses as source IP address and (2) by=0A= default in DHCP SAVI, a packet with an unbound source IP address is=0A= dropped, a SAVI solution for link-local addresses, e.g. [I-D.ietf-=0A= savi-fcfs], MUST be deployed in addition to DHCP SAVI.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Bi Expires June 13, 2012 [Page 4]=0A= =0C=0A= Internet-Draft savi-dhcp December 2011=0A= =0A= =0A= =0A= /------------\=0A= +--------+ | |=0A= | DHCP |-----| Router A |=0A= | Server | | |=0A= +--------+ \------------/=0A= ......................|..........=0A= . | .=0A= . Protection | .=0A= . Perimeter | .=0A= . | .=0A= . | .=0A= . | .=0A= . +----------+ +----'-----+ . +----------+=0A= . | SAVI | | SAVI | . | Non SAVI|=0A= . | Device A|----| Device B|------| Device |=0A= . +/---.-----+ +-.------.-+ . +-----.----+=0A= ................................. |=0A= | | | |=0A= | | | |=0A= +----/-----+ +----\-+ +\-----+ +--\---+=0A= | Router B | |DHCP | |Client| |Client|=0A= | | |Relay | | A | | B |=0A= +----------+ +------+ +------+ +------+=0A= Figure 1 DHCP Scenario=0A= =0A= =0A= =0A= 5. Data Structures=0A= =0A= This section describes the data structures used in this mechanism.=0A= =0A= Two main data structures are used to record bindings and their states=0A= respectively. There is redundancy between the two structures, for the=0A= consideration of separation of data plane and control plane.=0A= =0A= Besides the two main data structures, a mapping table from link layer=0A= address to binding anchor may be required, as described in section=0A= 7.4.1.=0A= =0A= 5.1. Control Plane Data Structure: Binding State Table (BST)=0A= =0A= This table contains the state of binding between source address and=0A= binding anchor. Entries are keyed on the binding anchor and source IP=0A= address. Each entry has a lifetime field recording the remaining=0A= lifetime of the entry, a state field recording the state of the=0A= binding and a TID field recording transaction ID of DHCP message. The=0A= =0A= =0A= Bi Expires June 13, 2012 [Page 5]=0A= =0C=0A= Internet-Draft savi-dhcp December 2011=0A= =0A= =0A= lifetime field is used to help remove expired bindings. The state=0A= field is used to identify state. The TID field is used to keep the=0A= Transaction ID (TID) [RFC2131][RFC3315] in DHCP request. The TID=0A= field can be cleared after the state is changed to BOUND.=0A= =0A= +---------+----------+----------+-----------+-------+=0A= | Anchor | Address | State | Lifetime |TID |=0A= +---------+----------+----------+-----------+-------+=0A= | A | IP_1 | BOUND | 65535 |TID 1 |=0A= +---------+----------+----------+-----------+-------+=0A= | A | IP_2 | BOUND | 10000 |TID 2 |=0A= +---------+----------+----------+-----------+-------+=0A= | B | IP_3 |INIT_BIND | 1 |TID_3 |=0A= +---------+----------+----------+-----------+-------+=0A= Figure 2 Instance of BST=0A= =0A= =0A= 5.2. Data Plane Data Structure: Filtering Table (FT)=0A= =0A= This table contains the bindings between binding anchor and address,=0A= keyed on binding anchor and address. This table doesn't contain any=0A= state of the binding. This table is only used to filter packets. An=0A= Access Control List can be regarded as a practical instance of this=0A= table. This table SHOULD be updated by other SAVI mechanisms [I-=0A= D.ietf-savi-mix] when DHCP SAVI is deployed in IPv6 environment, as=0A= explained in section 4.=0A= =0A= +---------+----------+=0A= | Anchor |Address |=0A= +---------+----------+=0A= |A |IP_1 |=0A= +---------+----------+=0A= |A |IP_2 |=0A= +---------+----------+=0A= Figure 3 Instance of FT=0A= =0A= 5.3. Mapping Table from Link Layer Address to Binding Anchor=0A= =0A= As described in section 7.4.1, whenever binding anchor must be=0A= recovered from DCHP Reply, such a mapping table is required. This=0A= table maps link layer address to binding anchor, so as that the SAVI=0A= device can determine on which binding anchor to set up a binding only=0A= based on a DHCP Reply message.=0A= =0A= Such a table can already exist on SAVI device. For example, if the=0A= binding anchor is switch port, the mapping table from MAC address to=0A= switch port is required on switch for switching frames. We don't=0A= =0A= =0A= Bi Expires June 13, 2012 [Page 6]=0A= =0C=0A= Internet-Draft savi-dhcp December 2011=0A= =0A= =0A= require SAVI device to set up a different mapping table from the=0A= existing one. Instead, SAVI device MUST only use the existing one. If=0A= there is not such a mapping table yet, SAVI device MUST NOT set up=0A= binding based on EVE_DHCP_REPLY_NULL (cf. 7.4.1).=0A= =0A= The set up and update of this table is out of the scope of this=0A= document.=0A= =0A= 6. Binding Anchor Attributes=0A= =0A= This section specifies the binding anchor attributes used in this=0A= mechanism.=0A= =0A= Attribute of each binding anchor is configurable. By default, binding=0A= anchor has no attribute. A binding anchor MAY be configured to have=0A= one or more compatible attributes.=0A= =0A= 6.1. No Attribute=0A= =0A= Before configuration, by default, a binding anchor has no attribute.=0A= To filter bogus DHCP server message by default, server type DHCP=0A= message from binding anchor with no attribute MUST be dropped.=0A= However, to avoid discarding legitimate traffic, other packets SHOULD=0A= NOT be dropped before any binding is setup on such binding anchor.=0A= Generally, each binding anchor is configured to have one or more=0A= attributes after configuration. However, a binding anchor MAY always=0A= have no attribute if it is connected to another link. For example, in=0A= Figure 1, on the binding anchor of SAVI Device A connected to Router=0A= B, it is unreasonable either to set up bindings for host behind=0A= Router B, or filter out traffic from Router B, or allow bogus DHCP=0A= message from Router B. Thus, no attribute should be configured on=0A= this binding anchor.=0A= =0A= 6.2. SAVI-Validation Attribute=0A= =0A= SAVI-Validation attribute is used on binding anchor on which the=0A= source address of data packet and DHCP message is to be validated.=0A= The filtering process on binding anchor with such attribute is=0A= described in section 9. In Figure 1, the binding anchor between SAVI=0A= Device B and Client A, and the binding anchor between SAVI Device B=0A= and Non SAVI Device should be configured to have this attribute.=0A= =0A= 6.3. SAVI-DHCP-Trust Attribute=0A= =0A= SAVI-DHCP-Trust Attribute is used on binding anchor on the path to a=0A= trustable DHCP server/relay. DHCP server/relay message coming from=0A= binding anchor with this attribute will be forwarded. In Figure 1,=0A= =0A= =0A= Bi Expires June 13, 2012 [Page 7]=0A= =0C=0A= Internet-Draft savi-dhcp December 2011=0A= =0A= =0A= the binding anchor between SAVI Device B and DHCP Relay, and the=0A= binding anchor between SAVI Device B and Router A, should be=0A= configured to have this attribute.=0A= =0A= 6.4. SAVI-SAVI Attribute=0A= =0A= This attribute is used on binding anchor from which the data traffic=0A= is not to be checked. Binding will not be set up on binding anchor=0A= with this attribute. All data packets will be allowed directly. In=0A= Figure 1, the binding anchor between SAVI Device A and SAVI Device B=0A= should be configured with this attribute.=0A= =0A= Through configuring this attribute on binding anchor that joins two=0A= or more SAVI devices, SAVI-Validation and SAVI-SAVI attributes=0A= implement the security perimeter concept in [I-D.ietf-savi-=0A= framework]. Since no binding entry is needed on such binding anchor,=0A= the resource requirement can be reduced greatly.=0A= =0A= Though there is no factual difference in packet process between a=0A= binding anchor with no attribute and a binding anchor only with SAVI-=0A= SAVI attribute, their connotations are different. SAVI-SAVI attribute=0A= is configured on binding anchor between SAVI devices on the same link=0A= inside the protection perimeter. But only when a binding anchor is on=0A= the protection perimeter and connected to another link, it can have=0A= no attribute after configuration.=0A= =0A= This attribute is mutually exclusive with SAVI-Validation.=0A= =0A= 6.5. SAVI-BindRecovery Attribute=0A= =0A= This attribute is used on binding anchor that requires data-triggered=0A= binding recovery described in section 8.1. It can be configured on=0A= any binding anchor with SAVI-Validation attribute, especially, the=0A= binding anchor not directly attached by client. In Figure 1, it is=0A= suggested to configure this attribute on binding anchor between SAVI=0A= Device B and Non SAVI Device.=0A= =0A= This attribute is mutually exclusive with SAVI-SAVI.=0A= =0A= 7. Binding Set Up=0A= =0A= This section specifies the procedure of setting up bindings based on=0A= DHCP message snooping. The binding procedure specified here is=0A= exclusively designed for binding anchor with SAVI-Validation=0A= attribute.=0A= =0A= =0A= =0A= =0A= Bi Expires June 13, 2012 [Page 8]=0A= =0C=0A= Internet-Draft savi-dhcp December 2011=0A= =0A= =0A= 7.1. Rationale=0A= =0A= The rationale of this mechanism is that if a node attached to a=0A= binding anchor is legitimate to use a DHCP address, the DHCP=0A= procedure which assigns the address to the node must have been=0A= performed on the same binding anchor. This basis stands when the link=0A= layer routing is stable. However, layer-2 mobility and unstable link=0A= layer routing may result in that data packet is received from a=0A= different binding anchor. Infrequent link layer path change can be=0A= handled (but not perfectly) by the mechanism described in section 8.=0A= Section 13.3 discusses the situation that link layer routing is=0A= naturedly unstable. A solution for this issue is outside the scope of=0A= this document.=0A= =0A= 7.2. Binding States Description=0A= =0A= This section describes the binding states of this mechanism.=0A= =0A= NO_BIND The state before a binding has been set up.=0A= =0A= INIT_BIND A DHCP request (or a DHCPv6 Confirm, or a DHCPv6=0A= Solicitation with Rapid Commit option) has been received from host,=0A= and it may trigger a new binding.=0A= =0A= BOUND The address is authorized to the client.=0A= =0A= 7.3. Events=0A= =0A= 7.3.1. Timer Expiration Event=0A= =0A= EVE_ENTRY_EXPIRE: The lifetime of an entry expires=0A= =0A= 7.3.2. Control Message Arriving Events=0A= =0A= Only if a control message can pass the check in section 9.2, the=0A= corresponding event is a valid event.=0A= =0A= EVE_DHCP_REQUEST: A DHCP Request message is received from a binding=0A= anchor with SAVI-Validation attribute, and the binding entry limit=0A= (cf. section 13.2) on the binding anchor has not been reached.=0A= =0A= EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received from a binding=0A= anchor with SAVI-Validation attribute, and the binding entry limit on=0A= the binding anchor has not been reached.=0A= =0A= EVE_DHCP_OPTION_RC: A DHCPv6 Solicitation message with Rapid Commit=0A= option is received from a binding anchor with SAVI-Validation=0A= =0A= =0A= Bi Expires June 13, 2012 [Page 9]=0A= =0C=0A= Internet-Draft savi-dhcp December 2011=0A= =0A= =0A= attribute, and the binding entry limit on the binding anchor has not=0A= been reached.=0A= =0A= EVE_DHCP_REPLY: A DHCPv4 Acknowledgement or DHCPv6 Reply message is=0A= received from a binding anchor with SAVI-DHCP-Trust attribute, and=0A= the message should be forwarded to a binding anchor with SAVI-=0A= Validation attribute.=0A= =0A= EVE_DHCP_REPLY_NULL: A DHCPv4 Acknowledgement or DHCPv6 Reply message=0A= is received from a binding anchor with SAVI-DHCP-Trust attribute, and=0A= there is no entry in state INIT_BIND contains the same TID as the=0A= message.=0A= =0A= EVE_DHCP_DECLINE: A DHCP Decline message is received from a binding=0A= anchor with SAVI-Validation attribute.=0A= =0A= EVE_DHCP_RELEASE: A DHCP Release message is received from a binding=0A= anchor with SAVI-Validation attribute.=0A= =0A= EVE_LEASEQUERY_REPLY: A successful DHCP LEASEQUERY_REPLY is received=0A= from a binding anchor with SAVI-DHCP-Trust attribute.=0A= =0A= 7.4. Process of DHCP Packet Snooping=0A= =0A= 7.4.1. From NO_BIND to Other States=0A= =0A= 7.4.1.1. Trigger Event=0A= =0A= EVE_DHCP_REQUEST, EVE_DHCP_CONFIRM, EVE_DHCP_OPTION_RC,=0A= EVE_DHCP_REPLY_NULL.=0A= =0A= 7.4.1.2. Following Actions=0A= =0A= If the triggering event is EVE_DHCP_REQUEST/EVE_DHCP_OPTION_RC:=0A= =0A= The SAVI device MUST forward the message.=0A= =0A= The SAVI device MUST generate an entry for the binding anchor in=0A= the Binding State Table (BST) and set the state field to INIT_BIND.=0A= The lifetime of this entry MUST set to be MAX_DHCP_RESPONSE_TIME.=0A= The TID field of the request packet MUST be recorded in the entry.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Bi Expires June 13, 2012 [Page 10]=0A= =0C=0A= Internet-Draft savi-dhcp December 2011=0A= =0A= =0A= +---------+-------+---------+-----------------------+-------+=0A= | Anchor |Address| State | Lifetime |TID |=0A= +---------+-------+---------+-----------------------+-------+=0A= | A | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID |=0A= +---------+-------+---------+-----------------------+-------+=0A= Figure 4 Binding entry in BST on client triggered initialization=0A= =0A= The TID is stored because it will be used in a future step (cf.=0A= section 7.4.2.2) to correctly associate the assigned address to the=0A= binding anchor.=0A= =0A= If the triggering event is EVE_DHCP_CONFIRM:=0A= =0A= Besides forwarding the message and generating corresponding entry,=0A= the address to be confirmed MUST be recorded in the entry. Because=0A= no lease time will be contained in the REPLY from DHCP server, the=0A= SAVI device MUST lookup in BST to determine whether there is an=0A= entry with the same address. If there is such an entry, it can be a=0A= local movement and the lifetime can be recovered from the entry. If=0A= there is not, the SAVI device MUST send a LEASEQUERY [RFC5007]=0A= message querying by IP address to All_DHCP_Relay_Agents_and_Servers=0A= multicast address [RFC3315] or a configured server address.=0A= =0A= +---------+--------+---------+-----------------------+-------+=0A= | Anchor | Address| State | Lifetime |TID |=0A= +---------+--------+---------+-----------------------+-------+=0A= | A | Addr |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID |=0A= +---------+--------+---------+-----------------------+-------+=0A= Figure 5 Binding entry in BST on Confirm triggered initialization=0A= =0A= If the triggering event is EVE_DHCP_REPLY_NULL:=0A= =0A= If the binding anchor is not link layer address and there is not a=0A= mapping table from link layer address to binding anchor, the=0A= message SHOULD be discarded.=0A= =0A= Else:=0A= =0A= The SAVI device MUST deliver the message to the destination.=0A= =0A= The SAVI device MUST generate as many new entries in BST and FT as=0A= the number of IADDR found in the message. If the binding anchor=0A= type inside the BST is not link layer address, the binding anchor=0A= for an entry is recovered from the mapping table from link layer=0A= address to binding anchor (cf. section 5.3) based on the=0A= destination link layer address inside the DHCP message.=0A= =0A= =0A= =0A= Bi Expires June 13, 2012 [Page 11]=0A= =0C=0A= Internet-Draft savi-dhcp December 2011=0A= =0A= =0A= The states of the corresponding entries are set to be BOUND. The=0A= lifetime of the entries MUST be set to be the lease time.=0A= =0A= The binding entry limit can be exceeded when setting up bindings=0A= for all addresses in a REPLY message. If there is enough binding=0A= entry resources, corresponding new entries MUST be generated even=0A= the binding number limit is exceeded. In case that there is not=0A= enough resource left, as many as possible entries SHOULD be set up.=0A= =0A= If the binding anchor is a switch port, there can be vulnerability=0A= in this process which is discussed in section 13.1. Similar problem=0A= can happen with other binding anchors.=0A= =0A= +---------+----------+-------+------------------------+-------+=0A= | Anchor | Address | State | Lifetime |TID |=0A= +---------+----------+-------+------------------------+-------+=0A= | A | Addr1 | BOUND | Lease time 1 |TID |=0A= +---------+----------+-------+------------------------+-------+=0A= | A | Addr2 | BOUND | Lease time 2 |TID |=0A= +---------+----------+-------+------------------------+-------+=0A= Figure 6 Binding entry in BST on Reply triggered initialization=0A= =0A= +---------+----------+=0A= | Anchor |Address |=0A= +---------+----------+=0A= |A |Addr1 |=0A= +---------+----------+=0A= |A |Addr2 |=0A= +---------+----------+=0A= =0A= Figure 7 Binding entry in FT on Reply triggered initialization=0A= =0A= 7.4.2. From INIT_BIND to Other States=0A= =0A= 7.4.2.1. Trigger Event=0A= =0A= EVE_DHCP_REPLY, EVE_ENTRY_EXPIRE, EVE_LEASEQUERY_REPLY.=0A= =0A= 7.4.2.2. Following Actions=0A= =0A= If the trigger event is EVE_DHCP_REPLY:=0A= =0A= The SAVI device MUST deliver the message to the destination.=0A= =0A= If the Address field is null, the lease time in Reply message MUST=0A= be recorded in the entry with matched TID. The state of the entry=0A= is changed to be BOUND. If more than one IADDR is found in the=0A= =0A= =0A= Bi Expires June 13, 2012 [Page 12]=0A= =0C=0A= Internet-Draft savi-dhcp December 2011=0A= =0A= =0A= message, if there is enough binding entry resource, corresponding=0A= new entries MUST be generated even the binding number limit is=0A= exceeded. In case that there is not enough resource left, as many=0A= as possible entries SHOULD be set up.=0A= =0A= If the Address field is not null, the Reply is in response to a=0A= Confirm message. If the Reply message is of Status Code Success,=0A= and there is an entry with the same address, set the Lifetime to=0A= be the remaining Lifetime of the existing entry, and remove the=0A= existing entry. If there is no entry with the same address, set=0A= the Lifetime of corresponding entry to MAX_LEASEQUERY_DELAY. The=0A= state of the entry is changed to be BOUND.=0A= =0A= +---------+----------+-------+------------------------+-------+=0A= | Anchor | Address | State | Lifetime |TID |=0A= +---------+----------+-------+------------------------+-------+=0A= | A | Addr | BOUND | Lease time |TID |=0A= +---------+----------+-------+------------------------+-------+=0A= Figure 8 From INIT_BIND to BOUND=0A= =0A= A corresponding entry MUST also be generated in FT.=0A= =0A= If the trigger event is EVE_ENTRY_EXPIRE:=0A= =0A= The entry MUST be deleted from BST.=0A= =0A= If the trigger event is EVE_LEASEQUERY_REPLY:=0A= =0A= The Lifetime field of entry with corresponding IP address MUST be=0A= set to the lease time in the LEASEQUERY_REPLY. The state of the entry=0A= is changed to BOUND.=0A= =0A= 7.4.3. From BOUND to Other States=0A= =0A= 7.4.3.1. Trigger Event=0A= =0A= EVE_ENTRY_EXPIRE, EVE_DHCP_RELEASE, EVE_DHCP_DECLINE,=0A= EVE_DHCP_REPLY_RENEW.=0A= =0A= 7.4.3.2. Following Actions=0A= =0A= If the trigger event is EVE_ENTRY_EXPIRE:=0A= =0A= Remove the corresponding entry in BST and FT.=0A= =0A= If the trigger event is EVE_DHCP_RELEASE or EVE_DHCP_DECLINE:=0A= =0A= =0A= =0A= Bi Expires June 13, 2012 [Page 13]=0A= =0C=0A= Internet-Draft savi-dhcp December 2011=0A= =0A= =0A= Remove the corresponding entry in BST and FT. The Release or=0A= Decline message MUST be forwarded.=0A= =0A= If the trigger event is EVE_DHCP_REPLY_RENEW:=0A= =0A= Set the lifetime of the address to be the new lease time.=0A= =0A= 7.5. State Machine of DHCP Snooping=0A= =0A= The main state transits are listed as follows.=0A= =0A= State Event Action Next State=0A= =0A= NO_BIND REQ/RC Generate entry INIT_BIND=0A= =0A= NO_BIND CFM Generate entry and send Leasequery INIT_BIND=0A= =0A= *NO_BIND RPL_NULL Generate entry with lease BOUND=0A= =0A= INIT_BIND RPL Record lease time/set LQ_DLY BOUND=0A= =0A= INIT_BIND Timeout Remove entry NO_BIND=0A= =0A= INIT_BIND LQR Record lease time BOUND=0A= =0A= BOUND RLS/DCL Remove entry NO_BIND=0A= =0A= BOUND Timeout Remove entry NO_BIND=0A= =0A= BOUND RNW Set new lifetime BOUND=0A= =0A= *: optional but NOT RECOMMENDED.=0A= =0A= REQ: EVE_DHCP_REQUEST=0A= =0A= CFM: EVE_DHCP_CONFIRM=0A= =0A= RC: EVE_DHCP_OPTION_RC=0A= =0A= RPL: EVE_DHCP REPLY=0A= =0A= RPL_NULL: EVE_DHCP REPLY_NULL=0A= =0A= DCL: DHCP DECLINE=0A= =0A= RLS: DHCP RELEASE=0A= =0A= =0A= =0A= Bi Expires June 13, 2012 [Page 14]=0A= =0C=0A= Internet-Draft savi-dhcp December 2011=0A= =0A= =0A= RNW: EVE_DHCP_RPL_RENEW=0A= =0A= LQR: EVE_LEASEQUERY_REPLY=0A= =0A= Timeout: EVE_ENTRY_EXPIRE=0A= =0A= LQ_DLY: MAX_LEASEQUERY_DELAY=0A= =0A= 8. Supplemental Binding Process=0A= =0A= Supplemental binding process is designed to cover scenarios where a=0A= packet is sent by node but no previous DHCP exchanges have occurred=0A= to update correctly the SAVI device's BST. A typical situation is=0A= when the link topology changes after the binding has been set up, and=0A= then the node will send packet through a different port than the=0A= bound port. Another scenario is that a node moves on the local link=0A= without re-configuration process.=0A= =0A= Supplemental binding process is designed to avoid blocking=0A= permanently legitimate traffic. It is not supposed to set up a=0A= binding whenever a data packet with unbound source address is=0A= received. Generally, longer time and more packets are needed to=0A= trigger supplemental binding processes, as explained in the following=0A= section.=0A= =0A= Binding Recovery Process is a conditional SHOULD. This function=0A= SHOULD be implemented if the vendor has such ability, unless the=0A= implementation is known to be directly attached to host. If an=0A= implementation is directly attached to host, change in link topology=0A= will not affect the bindings, and host will always start re-=0A= configuration process after interface is re-connected. Thus, there is=0A= no need to use additional process to recovery bindings. If the=0A= mechanism is not implemented and managed hosts are not directly=0A= attached, permanent legitimate traffic blocking can happen until the=0A= node is reconfigured.=0A= =0A= 8.1. Binding Recovery Process=0A= =0A= If a binding anchor is set to have SAVI-BindRecovery attribute,=0A= packet without matched binding can trigger the SAVI device to check=0A= if the source address can be used by corresponding node:=0A= =0A= 1. Check if the address has a local conflict through:=0A= =0A= IPv4 address: performing Address Resolution Protocol (ARP)=0A= [RFC826] or Address Conflict Detection [RFC5227] twice on the=0A= address;=0A= =0A= =0A= Bi Expires June 13, 2012 [Page 15]=0A= =0C=0A= Internet-Draft savi-dhcp December 2011=0A= =0A= =0A= IPv6 address: performing Duplicate Address Detection (DAD)=0A= [RFC4862] twice on the address.=0A= =0A= If duplicate detection fails, the packet MUST be discarded.=0A= Otherwise, go to the next step.=0A= =0A= 2.=0A= =0A= IPv4 address:=0A= =0A= Send a DHCPLEASEQUERY [RFC4388] message querying by IP address to=0A= all DHCPv4 servers with IP Address Lease Time option (option 51).=0A= The server addresses can be found through DHCPv4 Discovery or from=0A= configuration. If no DHCPLEASEACTIVE message with IP Address Lease=0A= Time option is received, discard the packet; otherwise generate a=0A= new binding entry for the address, with the life time set to the=0A= value encoded in IP Address Lease Time option of the=0A= DHCPLEASEACTIVE message.=0A= =0A= IPv6 address:=0A= =0A= Send a LEASEQUERY [RFC5007] message querying by IP address to=0A= All_DHCP_Relay_Agents_and_Servers multicast address or a configured=0A= server address. If no successful LEASEQUERY-REPLY is received,=0A= discard the packet; otherwise generate a new binding entry for the=0A= address, with the lifetime set to the valid lifetime extracted from=0A= OPTION_CLIENT_DATA option in the LEASEQUERY-REPLY message. The SAVI=0A= device MAY repeat this process if a LEASEQUERY-REPLY with=0A= OPTION_CLIENT_LINK is received, in order to set up binding entries=0A= for all the address of the client.=0A= =0A= In case that SAVI device is pure layer-2 device without IP address,=0A= it is impossible to perform DHCP LEASEQUERY. Besides, this process=0A= may fail if any DHCP server doesn't support DHCP LEASEQUERY.=0A= =0A= The security issues about this process is discussed is section 13.5.=0A= =0A= 9. Filtering Specification=0A= =0A= This section specifies how to use bindings to filter packets.=0A= =0A= Filtering policies are different for data packet and control packet.=0A= DHCP and NDP (Neighbor Discovery Protocol) [RFC4861] messages that=0A= may cause state transit are classified into control packet. Neighbor=0A= Advertisement (NA) and ARP Response are also included in control=0A= packet, because the Target Address of NA and ARP Response should be=0A= =0A= =0A= =0A= Bi Expires June 13, 2012 [Page 16]=0A= =0C=0A= Internet-Draft savi-dhcp December 2011=0A= =0A= =0A= checked to prevent spoofing. All other packets are considered to be=0A= data packets.=0A= =0A= 9.1. Data Packet Filtering=0A= =0A= Data packets with a binding anchor which has attribute SAVI-=0A= Validation MUST be checked.=0A= =0A= If the source of a packet is correctly associated with its binding=0A= anchor in the FT, this packet MUST be forwarded else the packet MUST=0A= be discarded. The SAVI device SHOULD record any violation.=0A= =0A= 9.2. Control Packet Filtering=0A= =0A= For binding anchors with SAVI-Validation attribute:=0A= =0A= Discard DHCPv4 Discovery with non-all-zeros source IP address.=0A= Discard DHCPv4 Request whose source IP address is neither all zeros=0A= nor a bound address in FT.=0A= =0A= Discard DHCPv6 Request whose source is not bound with the=0A= corresponding binding anchor in FT. Discard DHCPv6 Confirm/Solicit=0A= whose source is not a link local address bound with the=0A= corresponding binding anchor in FT. The link layer address may be=0A= bound based on FCFS SLAAC solution [I-D.ietf-savi-fcfs] or other=0A= solutions.=0A= =0A= Discard other types of DHCP messages whose source is not an address=0A= bound with the corresponding binding anchor.=0A= =0A= Discard IPv6 Neighbor Solicitation (NS) and IPv4 gratuitous ARP=0A= whose source is not an address bound with the corresponding binding=0A= anchor.=0A= =0A= Discard NA and ARP Replies messages whose target address and source=0A= address are not bound with the corresponding binding anchor.=0A= =0A= For other binding anchors:=0A= =0A= Discard DHCP Reply/Ack messages not from binding anchor with the=0A= SAVI-DHCP-Trust attribute or SAVI-SAVI attribute.=0A= =0A= The SAVI device SHOULD record any violation of the previous rules.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Bi Expires June 13, 2012 [Page 17]=0A= =0C=0A= Internet-Draft savi-dhcp December 2011=0A= =0A= =0A= 10. State Restoration=0A= =0A= If a SAVI device reboots accidentally or designedly, the states kept=0A= in volatile memory will get lost. This may cause legitimate traffic=0A= from hosts indirectly attached to the SAVI device to be blocked until=0A= a binding recovery. Purely using the Binding Recovery Process is=0A= expansive and results delay to recover a large number of bindings.=0A= Thus, recovery from non-volatile storage, as specified below, is=0A= recommended.=0A= =0A= If this function is supported by hardware, binding entries MUST be=0A= saved into non-volatile storage whenever a new binding entry changes=0A= to BOUND state or a binding with BOUND state is removed.=0A= =0A= Immediately after reboot, the SAVI device MUST restore binding states=0A= from the non-volatile storage. The system time of save process MUST=0A= be stored. After rebooting, the SAVI device MUST check whether each=0A= entry has been obsolete through comparing the saved lifetime and the=0A= difference between current system time and saved system time.=0A= =0A= 11. Handle Binding Anchor Off-link Event=0A= =0A= Port DOWN event MUST be handled if switch port is used as binding=0A= anchor. In more general case, if a binding anchor turns off-link,=0A= this event MUST be handled.=0A= =0A= Whenever a binding anchor with attribute SAVI-Validation turns down,=0A= set a timer with OFFLINK_DELAY. Until the timer becomes zero, the=0A= bindings with the binding anchor SHOULD be kept. As an exception, to=0A= handle node movement, if receiving DAD Neighbor=0A= Solicitation/Gratuitous ARP request targeting at the address during=0A= OFFLINK_DELAY, the entry MAY be removed.=0A= =0A= To be compatible with DNAv4 [RFC4436], after a binding anchor turns=0A= off-link, if reachability test message specified in section 2.1.1 of=0A= [RFC4436] is received from another binding anchor which turns on-link=0A= afterwards, the binding MAY be migrated to the latter binding anchor.=0A= The binding recovery procedure specified in section 8.1 MUST be=0A= performed to ensure the binding migration is reasonable.=0A= =0A= If the binding anchor turns on-link during OFFLINK_DELAY, turn off=0A= the timer and keep corresponding bindings.=0A= =0A= 12. Constants=0A= =0A= MAX_DHCP_RESPONSE_TIME 120s=0A= =0A= =0A= =0A= Bi Expires June 13, 2012 [Page 18]=0A= =0C=0A= Internet-Draft savi-dhcp December 2011=0A= =0A= =0A= BIND_RECOVERY_INTERVAL 60s and configurable=0A= =0A= MAX_LEASEQUERY_DELAY 10s=0A= =0A= OFFLINK_DELAY 30s=0A= =0A= 13. Security Considerations=0A= =0A= 13.1. Security Problem about Binding Triggered by=0A= EVE_DHCP_REPLY_NULL=0A= =0A= When the binding anchor is switch port, binding based on=0A= EVE_DHCP_REPLY_NULL can result in security threats. The assigned=0A= address could be bound to a wrong switch port if an attack can=0A= poison the table mapping a link layer address to switch port (cf.=0A= section 5.3).=0A= =0A= For example, host A requests address from port 1. When SAVI switch=0A= receives a DHCP REPLY with assigned address IP_A and destination=0A= link layer address MAC_A, it will check its MAC/port table to find=0A= the right binding port. But MAC/port table might be polluted by an=0A= attacker host B attached to port 2. Then SAVI switch will find the=0A= MAC_A is at port 2 from the polluted MAC/port table and it will=0A= result in a wrong binding which binds IP_A and port 2.=0A= =0A= If one of the following conditions is satisfied, the security can be=0A= ensured.=0A= =0A= 1. DHCP Option 82 is used to keep binding anchor in DHCP Request and=0A= Reply.=0A= =0A= DHCP Option 82 can be used to keep the circuit information of the=0A= client and returned by the DHCP server. Thus the binding anchor=0A= can be determined from the circuit information in the Option. It=0A= can be used whenever an implementation doesn't want to create an=0A= entry on the DHCP Request message.=0A= =0A= 2. Unspoofable MAC is used as binding anchor (802.11i, 802.1ae/af).=0A= =0A= 3. The mapping table from MAC to binding anchor is secure.=0A= =0A= If the binding anchor is a link layer address, or there are=0A= mechanisms preventing the corruption of the table mapping the=0A= link layer to a switch port, mapping link layer address to=0A= binding anchor may be considered as secure.=0A= =0A= =0A= =0A= =0A= Bi Expires June 13, 2012 [Page 19]=0A= =0C=0A= Internet-Draft savi-dhcp December 2011=0A= =0A= =0A= It is NOT RECOMMENDED to initialize a binding based on DHCP Reply,=0A= unless a mechanism protecting the mapping table from corruption is=0A= also implemented.=0A= =0A= Similar problem may happen with binding anchors not based on link=0A= layer addresses.=0A= =0A= 13.2. Binding Number Limitation=0A= =0A= It is suggested to configure some mechanism in order to prevent a=0A= single node from exhausting the binding table entries on the SAVI=0A= device. Either of the following mechanism is sufficient to prevent=0A= such attack.=0A= =0A= 1. Set the upper bound of binding number for each binding anchor with=0A= SAVI-Validation.=0A= =0A= 2. Reserve a number of binding entries for each binding anchor with=0A= SAVI-Validation attribute and all binding anchors share a pool of=0A= the other binding entries.=0A= =0A= 3. Limit DHCP Request rate per binding anchor.=0A= =0A= 13.3. Risk from Link Layer Routing Dynamic=0A= =0A= An implicit assumption of this solution is that data packet must=0A= arrive at the same binding anchor with the binding anchor that the=0A= control packets have arrived at. If this assumption is not valid,=0A= this control packet based solution will fail or at least discard=0A= legitimate packet. Unfortunately, the link layer routing between host=0A= and SAVI device can be inconsistent from time to time. Time=0A= consistency of link layer routing is not assured by link layer=0A= routing protocol. For example, TRILL, a recent link layer routing=0A= protocol, is flexible and multiple link layer paths are allowed.=0A= =0A= To make the basic assumption stand, the best way is enforcing that=0A= there should be only one topology path from downstream host to the=0A= SAVI device. For example, SAVI device is directly attached by hosts.=0A= =0A= If the assumption doesn't stand, a better solution is requiring=0A= inter-operation between SAVI protocol and the link layer routing=0A= protocol to make SAVI protocol sensitive to the link layer routing=0A= change. This solution is above the scope of this document.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Bi Expires June 13, 2012 [Page 20]=0A= =0C=0A= Internet-Draft savi-dhcp December 2011=0A= =0A= =0A= 13.4. Duplicate Bindings of Same Address=0A= =0A= The same address may be bound with multiple binding anchors, only if=0A= the binding processes are finished on each binding anchor=0A= successfully respectively. This mechanism is designed in=0A= consideration that a node may move on the local ink, and a node may=0A= have multiple binding anchors. However, the traceability of address=0A= is reduced.=0A= =0A= Note that the local link movement scenario is not handled perfectly.=0A= The former binding may not be removed, unless the node is directly=0A= attached to SAVI device. The nodes sharing the same former binding=0A= anchor of the moving node have the ability to use its address.=0A= =0A= 13.5. Security Problems about Binding Recovery Process=0A= =0A= The Binding Recovery Process (cf. section 8.1) MUST be rate limited=0A= to avoid Denial of Services attack against the SAVI device itself. A=0A= constant BIND_RECOVERY_INTERVAL is used to control the frequency. Two=0A= data-triggered recovery processes on one binding anchor MUST have a=0A= minimum interval time BIND_RECOVERY_INTERVAL. This constant SHOULD be=0A= configured prudently to avoid Denial of Service attacks.=0A= =0A= This process is not strict secure. The node with SAVI-BindRecovery=0A= binding anchor has the ability to use the address of an inactive=0A= node, which doesn't reply to the detection probes.=0A= =0A= 13.6. Compatibility with DNA (Detecting Network Attachment)=0A= =0A= DNA [RFC4436] [RFC6059] is designed to decrease the handover latency=0A= after re-attachment to the same network. DNA mainly relies on sending=0A= unicast Neighbor Solicitation/ARP message to detect whether a=0A= previously configured address is still valid.=0A= =0A= In Simple DNAv6 [RFC6059], the DHCP exchange step is required, thus=0A= it is compatible with SAVI. However, in DNAv4 [RFC4436], the DHCP=0A= exchange procedure in current standards is not mandatory. If a=0A= binding is set up only through snooping the reachability test message,=0A= the binding can be invalid. For example, an attacker can perform=0A= reachability test with address bound to another host. If binding is=0A= migrated to the attacker, the attacker can successful obtain the=0A= binding from the victim.=0A= =0A= For security, in this mechanism, a binding can be migrated to a=0A= different binding anchor only if the previous binding anchor is off-=0A= link and the new binding anchor is on-link afterwards, as specified=0A= =0A= =0A= =0A= Bi Expires June 13, 2012 [Page 21]=0A= =0C=0A= Internet-Draft savi-dhcp December 2011=0A= =0A= =0A= in section 11. If a binding anchor is on-link, its bindings will=0A= never migrate to another binding anchor.=0A= =0A= If a DNAv4 node moves without triggering link-down/up event on SAVI=0A= device, the binding will not migrate. In this case, the DNAv4 node=0A= MUST perform DHCP exchange to recover binding after re-attachment.=0A= But binding can also be recovered based on the binding recovery=0A= procedure specified in section 8.1, if the SAVI-BindRecovery=0A= attribute is set on the new binding anchor.=0A= =0A= 13.7. Residual Threats=0A= =0A= As described in [I-D.ietf-savi-framework], this solution cannot=0A= strictly prevent spoofing. There are two scenarios in which spoofing=0A= can still happen:=0A= =0A= 1. The binding anchor is spoofable=0A= =0A= If the binding anchor is spoofable, e.g., plain MAC address, an=0A= attacker can use forged binding anchor to send packet which will not=0A= be regarded as spoofing by SAVI device.=0A= =0A= Indeed, using binding anchor that can be easily spoofed is dangerous.=0A= An attacker can use the binding anchor of another host to perform a=0A= lot of DHCP procedures, and the SAVI device will refuse to set up new=0A= binding for the host whenever the binding number limitation has been=0A= reached. Thus, it is RECOMMENDED to use strong enough binding anchor,=0A= e.g., switch port, secure association in 802.11ae/af and 802.11i.=0A= =0A= 2. The binding anchor is shared by more than one host=0A= =0A= If the binding anchor is shared by more than one host, they can spoof=0A= the addresses of each other. For example, a number of hosts can=0A= attach to the same switch port of a SAVI device through a hub. The=0A= SAVI device cannot distinguish packets from different hosts and thus=0A= the spoofing between them will not be detected. This problem can be=0A= solved through not sharing binding anchor between hosts.=0A= =0A= 14. IANA Considerations=0A= =0A= This document has no IANA actions.=0A= =0A= [RFC Editor: please remove this section prior to publication.]=0A= =0A= =0A= =0A= =0A= =0A= =0A= Bi Expires June 13, 2012 [Page 22]=0A= =0C=0A= Internet-Draft savi-dhcp December 2011=0A= =0A= =0A= 15. References=0A= =0A= 15.1. Normative References=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=0A= Requirement Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= [I-D.ietf-savi-framework]=0A= =0A= Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt,=0A= "Source Address Validation Improvement Framework", draft-=0A= ietf-savi-framework-04 (work in progress), March 2011.=0A= =0A= [I-D.ietf-savi-fcfs]=0A= =0A= Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS-=0A= SAVI: First-Come First-Serve Source-Address Validation for=0A= Locally Assigned IPv6 Addresses", draft-ietf-savi-fcfs-09=0A= (work in progress), April 2011.=0A= =0A= [I-D.ietf-savi-mix]=0A= =0A= Jun Bi, Guang Yao, J. Halpern and E. Levy-Abegnoli, "SAVI=0A= for Mixed Address Assignment Methods Scenario", draft-ietf-=0A= savi-mix-00 (work in progress), March 2011.=0A= =0A= [RFC826] Plummer, D.C., "Ethernet Address Resolution Protocol: Or=0A= converting network protocol addresses to 48.bit Ethernet=0A= address for transmission on Ethernet hardware", STD 37, RFC=0A= 826, November 1982.=0A= =0A= [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC2131,=0A= March 1997.=0A= =0A= [RFC3315] R. Droms, Ed. "Dynamic Host Configuration Protocol for IPv6=0A= (DHCPv6)", RFC3315, July 2003.=0A= =0A= [RFC3736] R. Droms, "Stateless Dynamic Host Configuration Protocol=0A= (DHCP) Service for IPv6", RFC 3736, April 2004.=0A= =0A= [RFC4388] R. Woundy and K. Kinnear, "Dynamic Host Configuration=0A= Protocol (DHCP) Leasequery", RFC4388, February 2006.=0A= =0A= [RFC4426] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network=0A= Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.=0A= =0A= =0A= Bi Expires June 13, 2012 [Page 23]=0A= =0C=0A= Internet-Draft savi-dhcp December 2011=0A= =0A= =0A= [RFC4861] T. Narten, E. Nordmark, W. Simpson, and H. Soliman,=0A= "Neighbor Discovery for IP version 6 (IPv6)", RFC4861,=0A= September 2007.=0A= =0A= [RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless=0A= Autoconfiguration", RFC4862, September, 2007.=0A= =0A= [RFC5007] J. Brzozowski, K. Kinnear, B. Volz, S. Zeng, "DHCPv6=0A= Leasequery", RFC5007, September 2007.=0A= =0A= [RFC6059] S. Krishnan, G. Daley, "Simple Procedures for Detecting=0A= Network Attachment in IPv6", RFC6059, November 2010.=0A= =0A= 15.2. Informative References=0A= =0A= [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering:=0A= Defeating Denial of Service Attacks which employ IP Source=0A= Address Spoofing", BCP 38, RFC 2827, May 2000.=0A= =0A= [RFC5227] S. Cheshire, "IPv4 Address Conflict Detection", RFC5227,=0A= July 2008.=0A= =0A= [IP Source Guard]=0A= =0A= Baker, F., "Cisco IP Version 4 Source Guard", IETF Internet=0A= draft (work in progress), November 2007.=0A= =0A= 16. Acknowledgments=0A= =0A= Special thanks to Jari Arkko, Jean-Michel Combes, Christian Vogt, =0A= Joel M. Halpern, Eric Levy-Abegnoli and Alberto Garcia for careful =0A= review and valuation comments on the state machine and text.=0A= Thanks to Marcelo Bagnulo Braun, Mark Williams, Erik Nordmark, Mikael=0A= Abrahamsson, David Harrington, Pekka Savola, Xing Li, Lixia=0A= Zhang, Robert Raszuk, Greg Daley, John Kaippallimalil and Tao Lin for=0A= their valuable contributions.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Bi Expires June 13, 2012 [Page 24]=0A= =0C=0A= Internet-Draft savi-dhcp December 2011=0A= =0A= =0A= Authors' Addresses=0A= =0A= Jun Bi=0A= Tsinghua University=0A= Network Research Center, Tsinghua University=0A= Beijing 100084=0A= China=0A= Email: junbi@tsinghua.edu.cn=0A= =0A= Jianping Wu=0A= Tsinghua University=0A= Computer Science, Tsinghua University=0A= Beijing 100084=0A= China=0A= Email: jianping@cernet.edu.cn=0A= =0A= =0A= Guang Yao=0A= Tsinghua University=0A= Computer Science, Tsinghua University=0A= Beijing 100084=0A= China=0A= Email: yaog@netarchlab.tsinghua.edu.cn=0A= =0A= Fred Baker=0A= Cisco Systems=0A= Santa Barbara, CA 93117=0A= United States=0A= Email: fred@cisco.com=0A= =0A= =0A= 17. Change Log=0A= =0A= From 02 to 03:=0A= =0A= - Section 12, data trigger and counter trigger are combined to=0A= binding recovery process. The expression "one of MUST" is=0A= changed to "conditional MUST. Conditions related with the=0A= implementation are specified. Related constants are changed=0A= in section 26."=0A= =0A= =0A= =0A= =0A= =0A= Bi Expires June 13, 2012 [Page 25]=0A= =0C=0A= Internet-Draft savi-dhcp December 2011=0A= =0A= =0A= Main changes from 03 to 04:=0A= =0A= - Section "Prefix configuration" is removed.=0A= =0A= - Section "Supplemental binding process" is modified in=0A= requirement level.=0A= =0A= - Sub-section 9.1 "Rationale" is added.=0A= =0A= - Section "Filtering during Detection" is removed.=0A= =0A= - Section "Handling layer 2 path change" is changed to=0A= "Consideration on Link layer routing complexity"=0A= =0A= - Section "Background and related protocols" is removed.=0A= =0A= Main changes from 04 to 05:=0A= =0A= - Trigger events are listed explicitly in section 8.=0A= =0A= - Detection and Live states are deleted, together with=0A= corresponding sections.=0A= =0A= Main change from 05 to 06:=0A= =0A= - Section 8.1: reference to section 20 is changed to section=0A= 15.=0A= =0A= Main changes from 06 to 07:=0A= =0A= - So many changes in this modification. We suggest to track=0A= http://www.ietf.org/mailarchive/web/savi/current/msg01543.ht=0A= ml. Changes are made according to the comments.=0A= =0A= Main changes from 07 to 08,09:=0A= =0A= - The modifications are made according to the comments from=0A= Jean-Michel Combes.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Bi Expires June 13, 2012 [Page 26]=0A= =0C=0A= ------=_NextPart_000_013E_01CCB939.EAE23730-- From pthubert@cisco.com Tue Dec 13 10:36:51 2011 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78FD21F889A for ; Tue, 13 Dec 2011 10:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.211 X-Spam-Level: X-Spam-Status: No, score=-10.211 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CoafhHHQ8N6 for ; Tue, 13 Dec 2011 10:36:51 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C6E2D21F84BA for ; Tue, 13 Dec 2011 10:36:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2636; q=dns/txt; s=iport; t=1323801411; x=1325011011; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=tC8+Zcx7BMPVrv8fWPiSz1TuRej9H2uCdUvfVJ0zkzI=; b=QTLisG5itEznRqJGWF6fSj6KnVE5Mx7lLcYT+R8mx/EetaX+YFNk8Bpo 4NpXg3PbwSkaH1ZXGz72HY1LI+H0+XPfoiXkBQLzweo322WoE2NArU30r A4WMB4sg5vgkMM+vtdWYfaDHe4CwICvAnferItTXZibJHdSB2hT2bLZKd Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPya506Q/khR/2dsb2JhbABDhQekfoEagQWBcgEBAQQSARANBEMOBgEIEQQBAQMCBgYXAQICAwFEBwEBBQQBBBMIGp1xgSYBjFuRUIEviR4zYwSnGw X-IronPort-AV: E=Sophos;i="4.71,347,1320624000"; d="scan'208";a="123639770" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 13 Dec 2011 18:36:49 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pBDIan5J024343 for ; Tue, 13 Dec 2011 18:36:49 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Dec 2011 19:36:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 13 Dec 2011 19:35:38 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-thubert-savi-ra-throttler-00.txt Thread-Index: Acy5xf+pV/wJUZwxR7e0H4FBrxaMIA== From: "Pascal Thubert (pthubert)" To: "SAVI Mailing List" X-OriginalArrivalTime: 13 Dec 2011 18:36:49.0560 (UTC) FILETIME=[2CF1A980:01CCB9C6] Subject: [savi] FW: New Version Notification for draft-thubert-savi-ra-throttler-00.txt X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 18:36:51 -0000 SGk6DQoNCkkganVzdCBwb3N0ZWQgYSBkcmFmdCB0aGF0IGlsbHVzdHJhdGVzIGEgcHJvcG9zZWQg bmV3IHdvcmsgaXRlbSBmb3IgdGhpcyBncm91cC4gVGhpcyB3b3JrIGl0ZW0gaXMgYWJvdXQgdGhl IHByb3RlY3Rpb24gb2YgdGhlIG5ldHdvcmsgYWdhaW5zdCBvdmVydXNlIG9mIHRoZSBiYW5kd2lk dGggYnkgY2VydGFpbiBtdWx0aWNhc3QgcGFja2V0cyBhcyBvcHBvc2VkIHRvIGRlZmVuZGluZyB0 aGUgbmV0d29yayBhZ2FpbnN0IGF0dGFja3MuIFRoZSBzcGVjaWZpYyBkcmFmdCBJIHB1Ymxpc2hl cyBwcm9wb3NlcyBtZXRob2RzIGJ5IHdoaWNoIGEgc3dpdGNoIG1pZ2h0IGRlY2lkZSBub3QgdG8g Y29weSBjZXJ0YWluIG11bHRpY2FzdCBSQSBtZXNzYWdlcyBvbnRvIGNlcnRhaW4gcG9ydHMsIHR5 cGljYWxseSBwb3J0cyBsZWFkaW5nIHRvIGEgd2lyZWxlc3MgZWRnZSwgc28gYXMgdG8gcHJvdGVj dCB0aGF0IHRoZSBsaW1pdGVkIGJhbmR3aWR0aCB0aGVyZS4NCg0KQXMgdXN1YWwsIGNvbW1lbnRz IGFyZSB2ZXJ5IHdlbGNvbWU7DQoNClBhc2NhbA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddIA0KU2VudDogbWFyZGkgMTMgZMOpY2VtYnJlIDIwMTEgMTk6MzANClRvOiBQ YXNjYWwgVGh1YmVydCAocHRodWJlcnQpDQpDYzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0K U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC10aHViZXJ0LXNhdmkt cmEtdGhyb3R0bGVyLTAwLnR4dA0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdGh1YmVy dC1zYXZpLXJhLXRocm90dGxlci0wMC50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBQYXNjYWwgVGh1YmVydCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoN CkZpbGVuYW1lOgkgZHJhZnQtdGh1YmVydC1zYXZpLXJhLXRocm90dGxlcg0KUmV2aXNpb246CSAw MA0KVGl0bGU6CQkgVGhyb3R0bGluZyBSQXMgb24gY29uc3RyYWluZWQgaW50ZXJmYWNlcw0KQ3Jl YXRpb24gZGF0ZToJIDIwMTEtMTItMTMNCldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0K TnVtYmVyIG9mIHBhZ2VzOiAxMw0KDQpBYnN0cmFjdDoNCiAgIEluIGEgbGFyZ2Ugc3dpdGNoZWQg dG9wb2xvZ3kgd2l0aCBlaXRoZXIgbWFueSByb3V0ZXJzIG9yIHJvdXRlcnMgdGhhdA0KICAgdHJh bnNtaXQgYSBoaWdoIHJhdGUgb2YgbXVsdGljYXN0IGFkdmVydGlzZW1lbnRzIHBlciByb3V0ZXIs IGFzDQogICBzdWdnZXN0ZWQgdG8gc3VwcG9ydCBtb2JpbGUgbm9kZXMsIHRoZSBjb3N0IG9mIGRp c3RyaWJ1dGluZyB0aGUgbWFueQ0KICAgcmVzdWx0aW5nIG11bHRpY2FzdCBtZXNzYWdlcyB0byBj ZXJ0YWluIGNsYXNzZXMgb2YgZGV2aWNlcyBtaWdodCBiZQ0KICAgcHJvaGliaXRpdmUuICBUaGlz IGlzIHRoZSBjYXNlIG9mIGEgZGV2aWNlIHRoYXQgcnVucyBvbiBiYXR0ZXJpZXMsIG9yDQogICBh IGRldmljZSB0aGF0IGlzIHJlYWNoYWJsZSBvdmVyIGEgd2lyZWxlc3MgaW50ZXJmYWNlLiAgRm9y IHRoaXMNCiAgIGRldmljZSwgaXQgY2FuIGJlIGJlbmVmaWNpYWwgdG8gZmlsdGVyIGEgY2VydGFp biBhbW91bnQgb2YgbXVsdGljYXN0DQogICBtZXNzYWdlcyBzdWNoIGFzIHRoZSBSb3V0ZXIgQWR2 ZXJ0aXNlbWVudCB3aGlsZSBwcmVzZXJ2aW5nIHRoZQ0KICAgZnVuY3Rpb25hbGl0eSBleHBlY3Rl ZCBpbiB0aGUgSVB2NiBOZWlnaGJvciBEaXNjb3ZlcnkgUHJvdG9jb2wuDQoNCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQo= From junbi@tsinghua.edu.cn Fri Dec 16 04:36:42 2011 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F2221F8B6B for ; Fri, 16 Dec 2011 04:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.053 X-Spam-Level: X-Spam-Status: No, score=-98.053 tagged_above=-999 required=5 tests=[AWL=-2.450, BAYES_50=0.001, DNS_FROM_RFC_DSN=1.495, J_CHICKENPOX_31=0.6, MANGLED_PILL=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgTgLHSk8YoK for ; Fri, 16 Dec 2011 04:36:40 -0800 (PST) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6F19821F8B62 for ; Fri, 16 Dec 2011 04:36:38 -0800 (PST) Received: from [59.66.24.157] (helo=junbiVAIOz138) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1RbX1b-0008Co-7I; Fri, 16 Dec 2011 20:36:31 +0800 Message-ID: <6AAE1DE7608446428A2B8E47040A1175@junbiVAIOz138> From: "Jun Bi" To: "Jean-Michel Combes" , "SAVI Mailing List" , "Bjorn Liu" References: In-Reply-To: Date: Fri, 16 Dec 2011 20:36:37 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_028F_01CCBC32.687A3D50" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 Subject: [savi] Problem statement drafts of SAVI in intra-AS and inter-AS X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 12:36:42 -0000 这是一封 MIME 格式的多方邮件。 ------=_NextPart_000_028F_01CCBC32.687A3D50 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit Dear WG Chair, Last SAVI meeting at IETF82, we had good discussion on problem of SAVI beyond the first hop. Some good points such as fast reroute was raised at WG meeting, and I was asked to make draft s of the problem. The attached files are preliminary versions of two drafts, one is for inside a AS, another is for inter-AS scenario. Since we already had good participants in IETF 82 and many people go to the mic to comment, I think this issue needs to be further addressed. Therefore, please request a SAVI WG meeting session at IETF83, so that we can continue the discussion. thanks, Jun Bi -----鍘熷閭欢----- From: Jean-Michel Combes Sent: Wednesday, December 07, 2011 8:20 AM To: SAVI Mailing List Subject: [savi] [IETF83] Important dates Hi, just a friendly reminder (due to Christmas holidays, deadlines will arrive quickly): 2011-12-19 (Monday): Working Group and BOF scheduling begins. To request a Working Group session, use the IETF Meeting Session Request Tool. 2012-01-30 (Monday): Cutoff date for requests to schedule Working Group meetings at 17:00 PT (UTC -8). To request a Working Group session, use the IETF Meeting Session Request Tool. As said during the last SAVI meeting, if no real interest regarding topics for a potential rechartering on the ML, no meeting during the next IETF meeting and the WG will close as soon as current WG docs will be finalized. Hope that helps. Best regards. JMC. _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi ------=_NextPart_000_028F_01CCBC32.687A3D50 Content-Type: text/plain; format=flowed; name="draft-bi-savi-problem-intraas-00-new.txt"; reply-type=original Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-bi-savi-problem-intraas-00-new.txt" Network Working Group J. Bi Internet-Draft B. Liu Intended status: Informational Tsinghua Univ. Expires: June 15, 2012 December 13, 2011 Problem Statement of RPF in Intra-AS Scenario draft-bi-savi-problem-intraas-00 Abstract Reverse Path Forwarding (RPF) [BCP38]/[BCP84] is designed to mitigate IP source address spoofing. In the intra-AS (autonomous system) environment, RPF is implemented on routers or layer 3 switches above the access network level. However RPF may deny legitimate packets (false positive) or fail to recognize spoofing packets (false negative) in some intra-AS scenarios. This document states these problems of RPF in intra-AS environment. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on June 15, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Bi, et al. Expires June 15, 2012 [Page 1] =0C Internet-Draft RPF Problem (Intra-AS) December 2011 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Bi, et al. Expires June 15, 2012 [Page 2] =0C Internet-Draft RPF Problem (Intra-AS) December 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7. Informative References . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Bi, et al. Expires June 15, 2012 [Page 3] =0C Internet-Draft RPF Problem (Intra-AS) December 2011 1. Introduction RPF [BCP38]/[BCP84] is now the only practical anti-spoofing technique. However, it is not so widely deployed as supposed. According to the report [ARBOR] by ARBOR Networks in 2009, of the 132 network operators, only about 35% deployed [BCP38] at dedicated customer edge, about 35% deployed it at broadband edge, and about 45% deployed it at peering edge. And the measurement by MIT ANA Spoofer project [Spoofer] shows that 31% of the test clients were able to successfully spoof an arbitrary, routable source address, while 77% of clients otherwise unable to spoof could forge an address within their own /24 subnetwork, and no mitigation improvement against spoofing over four years of measurement. The reasons why ISP met difficulties in deploying RPF implies the intrinsic problems of RPF. Detailed in [BCP84], RPF has five ways of implementation. The first implementation technique is Ingress Access Lists, which are typically maintained manually and thus difficult to be practical. Strict Reverse Path Forwarding (Strict RPF) and Feasible Path Reverse Path Forwarding (Feasible RPF) take advantage of the Reverse Path Forwarding (RPF) technique, and they share the same flaw with RPF, i.e. droping legitimate packets (false positive) under asymmetric routing. Loose Reverse Path Forwarding (Loose RPF) and Loose Reverse Path Forwarding Ignoring Default Routes (Loose RPF Ignoring Default Routes) check the existence of a route instead of where the route points to. These two ways of implementation, of course, have lower false positive, but they in a lot of cases cannot recognize spoofing packets (false negative) and thus are known as very inefficient. With the application of Fast Reroute in the intra-AS scenario, the backup forwarding path chosen when the primary path fails may be denied by RPF, which also causes false positive. In Section 2, the problems of each mode of RPF in the intra-AS scenario, in terms of difficulties in implementation, false positive (FP) and false negative (FN), are stated. Future discussion is presented in Section 3. 2. Problems In this section, we examine each mode of RPF, and explore possible practical problems. 2.1. Ingress Access Lists Ingress Access Lists are typically maintained manually, and it is only applicable where the number of prefix is small and the routing is stable over time. However, when dynamic intra-AS routing Bi, et al. Expires June 15, 2012 [Page 4] =0C Internet-Draft RPF Problem (Intra-AS) December 2011 protocols (e.g. OSPF, IS-IS and RIP) are in use, routing will oscillate in case of link failure, new link creation and configuration changing. Thus Ingress Access Lists may filter out valid packets (false positive). 2.2. Strict Reverse Path Forwarding Strict RPF causes false positive in the presence of asymmetric routing. Unfortunately, asymmetric is not uncommon in intra-AS routing. For instance, in OSPF, the cost of a link in the reverse direction can be different than the cost of it in the forward direction, which may result in asymmetric routing. Besides, if static routing co-exists with dynamic routing, asymmetric routing is also expected. 2.3. Feasible Reverse Path Forwarding Feasible RPF extends Strict RPF by inserting alternative routes (if any) into FIB, instead of just inserting one best route. A well- known implementation of Feasible RPF is RPF check considering ECMP (Equal Cost Multiple Paths). ECMP installs multiple best routes into FIB. All the ECMP out-interfaces are considered valid as the in- interfaces of the given source address prefix. The problem is that there can be many (tens of) ECMPs for a prefix, but the implementation of routers can only hold several (e.g. 4 or 8) of them. Thus the ECMPs for the prefix installed in FIB may be different in different routers, which eventually causes asymmetric routing and false positive of Feasible RPF. Besides, a router R may choose a high-cost path to destination D by static routing configuration, and this path may not exist in D's valid Feasible RPF candidate list, which also causes false positive. 2.4. Loose Reverse Path Forwarding Loose RPF is algorithmically similar to strict RPF, but differs in that it checks only for the existence of a route. The obvious drawback is that Loose RPF could be very inefficient, because all the intra-AS prefixes will be stored in routers. If default route presents in the FIB, the false negative can be even higher. In a more rigorous case, a slightly smarter attacker can use only routable source addresses, which nullifies the effect of Loose RPF completely. Compared with other modes of RPF, Loose RPF has lower false positive. However, in the figure below, we reveal the scenario where Loose RPF causes false positive. In this figure, router S and D take advantage of static routing. The FIB of S and D is shown below. In this case, a packet (src=3D1.0.0.1, dst=3D1.3.0.1) will be delivered via the = path (S Bi, et al. Expires June 15, 2012 [Page 5] =0C Internet-Draft RPF Problem (Intra-AS) December 2011 -> R2 -> D). However, according to the FIB of D, this packet is supposed to come from R1 if Loose RPF is used by D. Thus the packet is denied by D, which causes false positive. In general, if static routing is used, the routers have different views about the network, and false positive may occur. S 10.0.0.0/16 / \ / \ 10.1.0.0/16 R1 R2 10.2.0.0/16 \ / \ / D 10.3.0.0/16 +-------------+----------+ | Prefix | Next Hop | +-------------+----------+ | 10.0.0.0/16 | local | | 10.1.0.0/16 | R1 | | 0.0.0.0/0 | R2 | +-------------+----------+ FIB of S +-------------+----------+ | Prefix | Next Hop | +-------------+----------+ | 10.3.0.0/16 | local | | 10.2.0.0/16 | R2 | | 0.0.0.0/0 | R1 | +-------------+----------+ FIB of D 2.5. Loose Reverse Path Forwarding Ignoring Default Routes The false positive and false negative of Loose RPF also holds with Loose RPF Ignoring Default Routes. The only difference is that false negative stays the same if default route exists. 3. Discussion When we see the false positive and false negative of RPF, it is reasonable to ask what additional information RPF needs to perform source address checking correctly, or what is complete set of information that is sufficient to perform source address checking correctly. In this section, we discuss this issue in the case of Bi, et al. Expires June 15, 2012 [Page 6] =0C Internet-Draft RPF Problem (Intra-AS) December 2011 distance-vector routing protocols and link-state routing protocols seperately. The fundamental issue of distance-vector routing protocols (e.g. RIP and EIGRP) is that the node does not have the full information of the graph. Actually the node only knows the direction in which router or exit interface a packet should be forwarded, and the distance from its destination. However, in order to perform source address checking, a node should know other nodes' routing decision, because the direction to the destination does not necessarily have to be the direction chosen by the destination, especially when equal-cost multi-path (ECMP) presents, or the cost of a link is evaluated different from different directions (for EIGRP only). It may be very challeging for a node to have complete information to perform source address checking if a distance-vector routing protocol is used. In link-state routing protocols (e.g. OSPF and IS-IS), a node spreads its link-state advertisement (LSA) across the network, so each node can build the entire network graph. However, under ECMP, a node may also fail to decide the incoming direction of a packet with the limitation of ECMP entries in the router implementation. Besides, there are might be some local decisions that are not spread across the network, such as static routing configuration. Another issue is fast reroute, where a node transmits packet to a pre- configured backup path in case of the failure of the primary path. Therefore, a packet may arrive from an unexpected direction due to fast reroute, and false positive occurs. A possible extension to link-state routing protocols is to spread the local routing decisions, such as static routing and backup path configuration, along with the LSAs. The key issue of source address checking is to get the complete and up-to-date routing information. Either incomplete or out-of-date information may result in false postive and false negative. Future enhancement to RPF may focus on how to get the complete and up-to- date routing information. 4. Acknowledgment This document was generated using the xml2rfc tool. 5. IANA Considerations This memo asks the IANA for no new parameters. Note to RFC Editor: This section will have served its purpose if it Bi, et al. Expires June 15, 2012 [Page 7] =0C Internet-Draft RPF Problem (Intra-AS) December 2011 correctly tells IANA that no new assignments or registries are required, or if those assignments or registries are created during the RFC publication process. From the authors' perspective, it may therefore be removed upon publication as an RFC at the RFC Editor's discretion. 6. Security Considerations 7. Informative References [ARBOR] McPherson, D., Dobbins, R., Hollyman, M., Labovitz, C., and J. Nazario, "Network Infrastructure Security Report", February 2009. [BCP38] Paul, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2827, BCP 38, May 2000. [BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", RFC 3704, BCP 84, March 2004. [Spoofer] Beverly, R., Berger, A., Hyun, Y., and k. claffy, "Understanding the Efficacy of Deployed Internet Source Address Validation Filtering", August 2009. Authors' Addresses Jun Bi Tsinghua University Network Research Center, Tsinghua University Beijing 100084 China Email: junbi@tsinghua.edu.cn Bingyang Liu Tsinghua University Computer Science, Tsinghua University Beijing 100084 China Email: liuby@netarchlab.tsinghua.edu.cn Bi, et al. Expires June 15, 2012 [Page 8] =0C Internet-Draft RPF Problem (Intra-AS) December 2011 Bi, et al. Expires June 15, 2012 [Page 9] =0C ------=_NextPart_000_028F_01CCBC32.687A3D50 Content-Type: text/plain; format=flowed; name="draft-bi-savi-problem-interas-00-new.txt"; reply-type=original Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-bi-savi-problem-interas-00-new.txt" Network Working Group J. Bi Internet-Draft B. Liu Intended status: Informational Tsinghua Univ. Expires: June 15, 2012 December 13, 2011 Problem Statement of RPF in Inter-AS Scenario draft-bi-savi-problem-interas-00 Abstract Reverse Path Forwarding (RPF) [BCP38]/[BCP84] is designed to mitigate IP source address spoofing. In the inter-AS (autonomous system) environment, RPF can filter packets with spoofed source address before their entering or leaving an AS. However RPF may deny legitimate packets (false positive) or fail to recognize spoofing packets (false negative) in some inter-AS scenarios. Also RPF fails to provide sufficient incentives to Internet Service Providers (ISP) to deploy, which is very importantfor inter-AS deployment. This document states these problems of RPF in the inter-AS environment. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on June 15, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Bi, et al. Expires June 15, 2012 [Page 1] =0C Internet-Draft RPF Problem (Inter-AS) December 2011 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Bi, et al. Expires June 15, 2012 [Page 2] =0C Internet-Draft RPF Problem (Inter-AS) December 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Deployment Incentive . . . . . . . . . . . . . . . . . . . . . 8 4. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 9 5. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Informative References . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Bi, et al. Expires June 15, 2012 [Page 3] =0C Internet-Draft RPF Problem (Inter-AS) December 2011 1. Introduction RPF [BCP38]/[BCP84] is now the only practical anti-spoofing technique. However, it is not so widely deployed as supposed. According to the report [ARBOR] by ARBOR Networks in 2009, of the 132 network operators, only about 35% deployed [BCP38] at dedicated customer edge, about 35% deployed it at broadband edge, and about 45% deployed it at peering edge. And the measurement by MIT ANA Spoofer project [Spoofer] shows that 31% of the test clients were able to successfully spoof an arbitrary, routable source address, while 77% of clients otherwise unable to spoof could forge an address within their own /24 subnetwork, and no mitigation improvement against spoofing over four years of measurement. The reasons why ISP met difficulties in deploying RPF implies the intrinsic problems of RPF. Detailed in [BCP84], RPF has five ways of implementation. The first implementation technique is Ingress Access Lists, which are typically maintained manually and thus difficult to be practical. Strict Reverse Path Forwarding (Strict RPF) and Feasible Path Reverse Path Forwarding (Feasible RPF) take advantage of the Reverse Path Forwarding (RPF) technique, and they share the same flaw with RPF, i.e. droping legitimate packets (false positive) under asymmetric routing. Loose Reverse Path Forwarding (Loose RPF) and Loose Reverse Path Forwarding Ignoring Default Routes (Loose RPF Ignoring Default Routes) check the existence of a route instead of where the route points to. These two ways of implementation, of course, have lower false positive, but they in a lot of cases cannot recognize spoofing packets (false negative) and thus are known as very inefficient. Besides, an important feature of inter-AS anti- spoofing is that the deployment incentive is a dominating factor in the real deployment, and RPF fails to provide high deployment incentive. In section 2, the problems of RPF in the inter-AS scenario, in terms of difficulties in implementation, false positive (FP) and false negative (FN), are stated. In section 3, we examine the deployment incentives of RPF, and explain why ISPs may not have incentives to deploy it. Eventually we discuss about possible inter-AS source address validation solutions in section 4. 2. Problems The autonomous systems (AS) can be classified into three categories: single-homed edge AS (or stub AS), multi-homed edge AS, and transit AS. Bi, et al. Expires June 15, 2012 [Page 4] =0C Internet-Draft RPF Problem (Inter-AS) December 2011 o Single-homed Edge AS: A single-homed edge AS, also known as stub AS, is an AS who connects with only one other AS. The AS it connects to provides Internet connection service to it, and thus called its provider. The typical single-homed edge ASes are universities and companies, who consume the Internet connection service rather than provide Internet connection service to other ASes. A singled-homed edge AS may have multiple physical or logical connections with its only provider for robustness or quality of service (QoS). o Multi-homed Edge AS: A multi-homed edge AS is defined almost the same as a single-homed edge AS except that a multi-homed edge AS connects to more than one provider ASes. o Transit AS: A transit AS is an AS that provides Internet connection service through itself to other ASes. A transit AS can have its own providers, peers and customers. A transit AS typically exchanges routes with its neighbors using BGP, but some small ASes may also use a default route pointing its provider. In this section, we examine each mode of RPF, find out which classes of ASes it can be applied to, and explore possible practical problems. 2.1. Ingress Access Lists Ingress Access Lists are typically maintained manually, and it is only applicable where the number of prefix is small and the routing is stable over time. So a single-homed edge AS or a multi-homed edge AS may want to deploy it at the border of its network. However, due to the dynamics of inter-AS routing, the addition of a new prefix or the deletion of an existing prefix happen frequently in BGP advertisement, which cause the fasle positive and the false negative of Ingress Access Lists respectively. 2.2. Strict Reverse Path Forwarding Strict RPF causes false positive in the presence of asymmetric routing. Unfortunately, due to routing policy, hot-potato routing and traffic engineering, asymmetric is not uncommon in inter-AS routing, especially for transit ASes. For single-homed edge ASes and multi-homed edge ASes, Strict RPF can be applied if they can make sure that no asymmetric routing exists. However, for a single-homed edge AS, may not benefit from Strict RPF a lot, because all the inbound traffic is supposed to come from the single provider and thus the Strict RPF checking can only filter inbound traffic whose source addresses are martian addresses, unallocated addresses, unroutable addresses and local addresses. Things get worse if a default routing Bi, et al. Expires June 15, 2012 [Page 5] =0C Internet-Draft RPF Problem (Inter-AS) December 2011 pointing to the provider is used by the single-homed edge AS, in which case all traffic from the provider will be accepted. For a multi-homed edge AS, if only one provider is used as primary uplink and others are used as backup, the efficiency of Strict RPF is the same as the case of single-homed edge AS. 2.3. Feasible Reverse Path Forwarding Feasible RPF extends Strict RPF by inserting alternative routes (if any) into FIB, instead of just inserting one best route. Feasible RPF can be applied by single-homed edge ASes but the efficiency is low, as discussed in the last subsection (Strict RPF). Feasible RPF can also cause false positive when applied by multi-homed edge ASes and transit ASes. Consider a multi-homed edge AS C, who has two providers P1 and P2, and an AS D, who connects with P1 and P2. D can either be a multi-homed edge AS or a transit AS. C announces a prefix 10.0.0.0/22 to both P1 and P2. P1 aggregated the prefix with its own prefix, and announces only 10.0.0.0/19 to D. In contrast, P2 announces 10.0.0.0/22 to D. Thus a piece of FIB of D is shown as the table below. D ^ ^ 10.0.0.0/19 / \ 10.0.0.0/22 / \ P1 P2 ^ ^ 10.0.0.0/22 \ / 10.0.0.0/22 \ / C +-------------+----------+ | Prefix | Next Hop | +-------------+----------+ | 10.0.0.0/22 | P2 | | 10.0.0.0/19 | P1 | +-------------+----------+ Assuming that C prefers P1 to P2 as the next hop for destination D, the AS path for a legitimate packet (s, d) would be "S -> P1 -> D". If Feasible RPF is applied by D, this packet (s, d) will be denied by D, because the only valid next hop for s is P2 rather than P1. An underlying reason for this false positive is that the routers always do longest prefix match, and prefix aggregation on P1 makes "S -> P1 -> D" an invalid path from D's point of view. Bi, et al. Expires June 15, 2012 [Page 6] =0C Internet-Draft RPF Problem (Inter-AS) December 2011 2.4. Loose Reverse Path Forwarding Loose RPF is algorithmically similar to strict RPF, but differs in that it checks only for the existence of a route. The obvious drawback is that Loose RPF could be very inefficient. In the current Internet, more than 50% of the address span is routable [BGP-Table], which means even randomly selected source addresses have the probability higher than 50% to pass Loose RPF (false negative). If default route presents in the FIB, the false negative can be even higher. In a more rigorous case, a slightly smarter attacker can use only routable source addresses, which nullifies the effect of Loose RPF completely. Compared with other modes of RPF, Loose RPF has lower false positive. However, in the figure below, we reveal the scenario where Loose RPF causes false positive. In this figure, AS D is an edge AS, who has two providers P1 and P2. In this case, AS D uses a static routing table including a default route. The FIB of D is shown in the table below. According to the FIB of D, Loose RPF will filter any packet whose source address does not belong to 1.0.0.0/8 from P2. If AS S, whose source address prefix is 2.0.0.0/8, sends packets to D via P2 because of a shorter AS path, all these valid packets will be denied by D. Basically, if static routing is used by an AS (typically in the non-Default Free Zone), Loose RPF may cause false positive. ~~~~S (2.0.0.0/8) / \ P1 P2 \ / \ / D +-----------+----------+ | Prefix | Next Hop | +-----------+----------+ | 0.0.0.0/0 | P1 | | 1.0.0.0/8 | P2 | +-----------+----------+ 2.5. Loose Reverse Path Forwarding Ignoring Default Routes The false positive and false negative of Loose RPF also holds with Loose RPF Ignoring Default Routes. The only difference is that false negative stays the same if default route exists. Bi, et al. Expires June 15, 2012 [Page 7] =0C Internet-Draft RPF Problem (Inter-AS) December 2011 3. Deployment Incentive In the last section, we discuss the technical problems of ingress filtering. However, an inter-AS source address validation method (SAVM) is deployable only if it provides reasonable deployment incentive to ISPs. In this section, we define deployment incentive is and discuss how to achieve high deployment incentive. First, we define the "benefit" of an AS as the reduction of its received spoofing packets. For instance, assume that the amount of global spoofing packets targeting AS T is t, and a portion of the spoofing packets is filtered because some ASes have deployed some inter-AS SAVM (e.g. RPF), then the amount of T's received spoofing packets is r. We define the benefit of T as (t-r)/t, i.e. the reduction of T's received spoofing packets. Then we define "incentive" of T as the additional benefit if T also deploys the inter-AS SAVM. To be more precise, denoting T's benefit before T deploys the inter-AS SAVM as ben(T, D), where D is the set of ASes who have already deployed the SAVM, and T's benefit after T's deployment as ben(T, D+T), then T's incentive is denoted as inc(T, D) =3D ben(T, D+T) - ben(T, D). This definition of incentive emphasizes two properties. First, an inter-AS SAVM should protect the deployers, in term of reducing the deployers' received spoofing packets. Second, the SAVM should motivate the late deployers, i.e. the late deployers should gain enough additional benefit otherwise they won't deploy it. We observe that the ISPs always want to maximize their own profits, not the public welfare. If an ISP already benefits a lot from other ISPs' deployment, and it can only get very trivial additional benefit by its own deployment, then perhaps this ISP won't deploy it. Take RPF for example. All ASes who deploy RPF try to filter out all the spoofing packets they can detect, not only those spoofing packets targeting themselves. RPF, instead of maximizing the deployers' benefit, tries to maximize the public welfare. The drawback of it is that if a portion of ASes have deployed RPF, other ASes may not want to deploy because the additional benefit is low. Research [Spoofer] shows that the deployment progress of RPF is slower than the growth of the Internet, and lack of deployment incentive may be the essential reason. However maximizing deployment incentive does not necessarily mean sacrificing the public welfare. Research [DIA] shows that high incentive can motivates more ASes to deploy, and with more deployment the public welfare gets higher. So we claim that maximizing deployment incentive is a key issue in the design of inter-AS SAVMs. Bi, et al. Expires June 15, 2012 [Page 8] =0C Internet-Draft RPF Problem (Inter-AS) December 2011 4. Possible Solutions Besides maximizing the deployment incentive of an inter-AS SAVM, there are also some other issues to be addressed. o First, an inter-AS SAVM should minimize its false positive. Filtering valid packets (false positive) is typically much worse than missing spoofing packets (false negative), because it is one form of Denial of Service (DoS). o Second, an inter-AS SAVM should benefit the early deployers. Otherwise no one would like to be the first one to deploy. o Third, an inter-AS SAVM should support incremental deployment, so that the ISPs can upgrade or configure their network devices incrementally. o Last but not least, low cost. If the fixed cost (purchasing new devices, initial deployment, etc.) is not avoidable, marginal cost (power consumption, administrative cost, ect.) should be minimized. 5. Acknowledgment This document was generated using the xml2rfc tool. 6. IANA Considerations This memo asks the IANA for no new parameters. Note to RFC Editor: This section will have served its purpose if it correctly tells IANA that no new assignments or registries are required, or if those assignments or registries are created during the RFC publication process. From the authors' perspective, it may therefore be removed upon publication as an RFC at the RFC Editor's discretion. 7. Security Considerations 8. Informative References [ARBOR] McPherson, D., Dobbins, R., Hollyman, M., Labovitz, C., and J. Nazario, "Network Infrastructure Security Report", February 2009. Bi, et al. Expires June 15, 2012 [Page 9] =0C Internet-Draft RPF Problem (Inter-AS) December 2011 [BCP38] Paul, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2827, BCP 38, May 2000. [BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", RFC 3704, BCP 84, March 2004. [BGP-Table] Huston, G., "AS6447 BGP Routing Table Analysis Report", November 2011. [DIA] Liu, B., Bi, J., and Y. Zhu, "A Deployable Approach for Inter-AS Anti-spoofing", October 2011. [Spoofer] Beverly, R., Berger, A., Hyun, Y., and k. claffy, "Understanding the Efficacy of Deployed Internet Source Address Validation Filtering", August 2009. Authors' Addresses Jun Bi Tsinghua University Network Research Center, Tsinghua University Beijing 100084 China Email: junbi@tsinghua.edu.cn Bingyang Liu Tsinghua University Computer Science, Tsinghua University Beijing 100084 China Email: liuby@netarchlab.tsinghua.edu.cn Bi, et al. Expires June 15, 2012 [Page 10] =0C ------=_NextPart_000_028F_01CCBC32.687A3D50-- From pthubert@cisco.com Fri Dec 16 04:48:48 2011 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63FE321F851F for ; Fri, 16 Dec 2011 04:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.244 X-Spam-Level: X-Spam-Status: No, score=-10.244 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXpKrogyMRp2 for ; Fri, 16 Dec 2011 04:48:47 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD2F21F849D for ; Fri, 16 Dec 2011 04:48:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=3026; q=dns/txt; s=iport; t=1324039727; x=1325249327; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=vFS0HjQajZZt4zP5xHwVw4Mdb1SAMTSSD+wYsdRzmZ0=; b=F9iVf71yqIfppK7vYjzfIVfdx9fUKuifrCEa1+ijadDYvFAEAMUFgD1B MSHu2kwax5EXXRKWs3fW2HkhHZtzGkocEyR1LczteWCwDE7wccVNREt6f 28SGowqkZllzjjmqOcbAwdlIzpqZFnZ64/SKujlqbUbQncn/Qof1zSUUF c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIAAEw9606Q/khR/2dsb2JhbABEDoR+lX2PKoEfgQWBcgEBAQQBAQEPARANBDoXBAIBBgIRBAEBAwIGBhcBAgICAQElHwkIAQEEARIIGodgmioBjFuRYgSBL4k/M2MEpms4 X-IronPort-AV: E=Sophos;i="4.71,363,1320624000"; d="scan'208";a="123951405" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 16 Dec 2011 12:48:46 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pBGCmkik023338; Fri, 16 Dec 2011 12:48:46 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Dec 2011 13:48:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 16 Dec 2011 13:47:46 +0100 Message-ID: In-Reply-To: <6AAE1DE7608446428A2B8E47040A1175@junbiVAIOz138> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [savi] Problem statement drafts of SAVI in intra-AS and inter-AS Thread-Index: Acy772D0odSfWgE7QIWwaHbQmPw0kwAASDZw References: <6AAE1DE7608446428A2B8E47040A1175@junbiVAIOz138> From: "Pascal Thubert (pthubert)" To: "Jun Bi" , "Jean-Michel Combes" , "SAVI Mailing List" , "Bjorn Liu" X-OriginalArrivalTime: 16 Dec 2011 12:48:46.0249 (UTC) FILETIME=[0CC28990:01CCBBF1] Subject: Re: [savi] Problem statement drafts of SAVI in intra-AS and inter-AS X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 12:48:48 -0000 SmVhbi1NaWNoZWw6DQoNCkkgYWdyZWUgd2l0aCBKdW4gQmkgdGhhdCB3ZSBzaG91bGQgaGF2ZSBh IHNlc3Npb24gaW4gUGFyaXMuDQoNCiBJJ2Qgd2lzaCB0byBkaXNjdXNzIG11bHRpY2FzdCBzdXBw cmVzc2lvbiBhdCB0aGUgKHdpcmVsZXNzKSBmaXJzdCBvciBsYXN0IGhvcCBhcyB3ZWxsLCBhdCBs ZWFzdCBmb3IgTkRQIG1lc3NhZ2VzLCBhcyBhbHJlYWR5IGRpc2N1c3NlZCBpbiB0aGUgUkEgdGhy b3R0bGVyIGRyYWZ0IHRoYXQgd2FzIGp1c3QgcHVibGlzaGVkLCBhbmQgaG9wZWZ1bGx5IGluIG1v cmUgd29yayB0byBjb21lIG9uIE5TL05BIGZsb3dzLg0KDQpDaGVlcnMsDQoNClBhc2NhbA0KDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzYXZpLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpzYXZpLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdW4gQmkNClNlbnQ6 IHZlbmRyZWRpIDE2IGTDqWNlbWJyZSAyMDExIDEzOjM3DQpUbzogSmVhbi1NaWNoZWwgQ29tYmVz OyBTQVZJIE1haWxpbmcgTGlzdDsgQmpvcm4gTGl1DQpTdWJqZWN0OiBbc2F2aV0gUHJvYmxlbSBz dGF0ZW1lbnQgZHJhZnRzIG9mIFNBVkkgaW4gaW50cmEtQVMgYW5kIGludGVyLUFTDQoNCkRlYXIg V0cgQ2hhaXIsDQoNCkxhc3QgU0FWSSBtZWV0aW5nIGF0IElFVEY4Miwgd2UgaGFkIGdvb2QgZGlz Y3Vzc2lvbiBvbiBwcm9ibGVtIG9mIFNBVkkgYmV5b25kIHRoZSBmaXJzdCBob3AuDQpTb21lIGdv b2QgcG9pbnRzIHN1Y2ggYXMgZmFzdCByZXJvdXRlIHdhcyByYWlzZWQgYXQgV0cgbWVldGluZywg YW5kIEkgd2FzIGFza2VkIHRvIG1ha2UgZHJhZnQgcyBvZiB0aGUgcHJvYmxlbS4NClRoZSBhdHRh Y2hlZCBmaWxlcyBhcmUgcHJlbGltaW5hcnkgdmVyc2lvbnMgb2YgdHdvIGRyYWZ0cywgb25lIGlz IGZvciBpbnNpZGUgYSBBUywgYW5vdGhlciBpcyBmb3IgaW50ZXItQVMgc2NlbmFyaW8uDQpTaW5j ZSB3ZSBhbHJlYWR5IGhhZCBnb29kIHBhcnRpY2lwYW50cyBpbiBJRVRGIDgyIGFuZCBtYW55IHBl b3BsZSBnbyB0byB0aGUgbWljIHRvIGNvbW1lbnQsIEkgdGhpbmsgdGhpcyBpc3N1ZSBuZWVkcyB0 byBiZSBmdXJ0aGVyIGFkZHJlc3NlZC4NClRoZXJlZm9yZSwgcGxlYXNlIHJlcXVlc3QgYSBTQVZJ IFdHIG1lZXRpbmcgc2Vzc2lvbiBhdCBJRVRGODMsIHNvIHRoYXQgd2UgY2FuIGNvbnRpbnVlIHRo ZSBkaXNjdXNzaW9uLg0KDQp0aGFua3MsDQpKdW4gQmkNCg0KLS0tLS3ljp/lp4vpgq7ku7YtLS0t LQ0KRnJvbTogSmVhbi1NaWNoZWwgQ29tYmVzDQpTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDA3 LCAyMDExIDg6MjAgQU0NClRvOiBTQVZJIE1haWxpbmcgTGlzdA0KU3ViamVjdDogW3NhdmldIFtJ RVRGODNdIEltcG9ydGFudCBkYXRlcw0KDQpIaSwNCg0KanVzdCBhIGZyaWVuZGx5IHJlbWluZGVy IChkdWUgdG8gQ2hyaXN0bWFzIGhvbGlkYXlzLCBkZWFkbGluZXMgd2lsbCBhcnJpdmUgcXVpY2ts eSk6DQoyMDExLTEyLTE5IChNb25kYXkpOiBXb3JraW5nIEdyb3VwIGFuZCBCT0Ygc2NoZWR1bGlu ZyBiZWdpbnMuIFRvIHJlcXVlc3QgYSBXb3JraW5nIEdyb3VwIHNlc3Npb24sIHVzZSB0aGUgSUVU RiBNZWV0aW5nIFNlc3Npb24gUmVxdWVzdCBUb29sLg0KMjAxMi0wMS0zMCAoTW9uZGF5KTogQ3V0 b2ZmIGRhdGUgZm9yIHJlcXVlc3RzIHRvIHNjaGVkdWxlIFdvcmtpbmcgR3JvdXAgbWVldGluZ3Mg YXQgMTc6MDAgUFQgKFVUQyAtOCkuIFRvIHJlcXVlc3QgYSBXb3JraW5nIEdyb3VwIHNlc3Npb24s IHVzZSB0aGUgSUVURiBNZWV0aW5nIFNlc3Npb24gUmVxdWVzdCBUb29sLg0KDQpBcyBzYWlkIGR1 cmluZyB0aGUgbGFzdCBTQVZJIG1lZXRpbmcsIGlmIG5vIHJlYWwgaW50ZXJlc3QgcmVnYXJkaW5n IHRvcGljcyBmb3IgYSBwb3RlbnRpYWwgcmVjaGFydGVyaW5nIG9uIHRoZSBNTCwgbm8gbWVldGlu ZyBkdXJpbmcgdGhlIG5leHQgSUVURiBtZWV0aW5nIGFuZCB0aGUgV0cgd2lsbCBjbG9zZSBhcyBz b29uIGFzIGN1cnJlbnQgV0cgZG9jcyB3aWxsIGJlIGZpbmFsaXplZC4NCg0KSG9wZSB0aGF0IGhl bHBzLg0KDQpCZXN0IHJlZ2FyZHMuDQoNCkpNQy4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpzYXZpIG1haWxpbmcgbGlzdA0Kc2F2aUBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYXZpIA0K From junbi@cernet.edu.cn Fri Dec 16 06:02:09 2011 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D3621F8B7D for ; Fri, 16 Dec 2011 06:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.739 X-Spam-Level: X-Spam-Status: No, score=-100.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVLLWKZsC2vm for ; Fri, 16 Dec 2011 06:02:09 -0800 (PST) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0419B21F8B8A for ; Fri, 16 Dec 2011 06:02:07 -0800 (PST) Received: from junbiVAIOz138 (unknown [59.66.24.157]) by centos (Coremail) with SMTP id AQAAf3BLiwLoTutODAoJAA--.24153S2; Fri, 16 Dec 2011 22:00:08 +0800 (CST) Message-ID: <34A5CFE483D047A094DA38CB83D44516@junbiVAIOz138> From: "Jun Bi" To: "Pascal Thubert \(pthubert\)" , "Jean-Michel Combes" , "SAVI Mailing List" , "Bjorn Liu" References: <6AAE1DE7608446428A2B8E47040A1175@junbiVAIOz138> In-Reply-To: Date: Fri, 16 Dec 2011 22:01:44 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 X-CM-TRANSID: AQAAf3BLiwLoTutODAoJAA--.24153S2 X-Coremail-Antispam: 1UD129KBjvJXoWxArWruF1DAw48Gryfury3Jwb_yoW5Gw4xpa ySqrs8GF4DJwn7Gw1kJ3W2qw40vrWfA397Gr15tr48tFZ8JFyktry0y345Z345Cr13JF12 qr10g3Wfuw45trJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUH0b7IF0VCFI7km07C26c804VAKzcIF0wAYjxAI6xZILanIXVAF wwAYjxAI6IIYrVAFwwAYjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I6I 8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l84ACjcxK6xIIjxv20xvE 14v26r1j6r1xM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4j6F4UM28EF7xvwVC2z280aV AFwI0_Cr1j6rxdM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAawVACjsI_Ar4v6c8G OVW06r1DJrWUAwAawVCFI7vE04vSzxk24VAqrcv_Gr1UXr18M2kK6IIYrVAqxI0j4VAqrc v_Jw1UGr1DM2vj6xkI62vS6c8GOVWUtr1rJFyle2I262IYc4CY6c8Ij28IcVAaY2xG8wAq jxCE34x0Y48IcwAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr 4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxG rwCY02Avz4vE14v_Xryl42xK82IYc2Ij64vIr41l4IxY624lx2IqxVAqx4xG67AKxVWUJV WUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAK I48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r 4UMIIF0xvE42xK8VAvwI8IcIk0rVW3JVWrJr1lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAI cVC2z280aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa7IU09jjPUUUUU== X-CM-SenderInfo: xmxquxg6fh20lhwovvfxof0/ Subject: Re: [savi] Problem statement drafts of SAVI in intra-AS and inter-AS X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 14:02:10 -0000 I am also interested to lisen Pascal's presentation on this topic in SAVI WG meeting. thanks, Jun Bi -----鍘熷閭欢----- From: Pascal Thubert (pthubert) Sent: Friday, December 16, 2011 8:47 PM To: Jun Bi ; Jean-Michel Combes ; SAVI Mailing List ; Bjorn Liu Subject: Re: [savi] Problem statement drafts of SAVI in intra-AS and inter-AS Jean-Michel: I agree with Jun Bi that we should have a session in Paris. I'd wish to discuss multicast suppression at the (wireless) first or last hop as well, at least for NDP messages, as already discussed in the RA throttler draft that was just published, and hopefully in more work to come on NS/NA flows. Cheers, Pascal -----Original Message----- From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Jun Bi Sent: vendredi 16 d茅cembre 2011 13:37 To: Jean-Michel Combes; SAVI Mailing List; Bjorn Liu Subject: [savi] Problem statement drafts of SAVI in intra-AS and inter-AS Dear WG Chair, Last SAVI meeting at IETF82, we had good discussion on problem of SAVI beyond the first hop. Some good points such as fast reroute was raised at WG meeting, and I was asked to make draft s of the problem. The attached files are preliminary versions of two drafts, one is for inside a AS, another is for inter-AS scenario. Since we already had good participants in IETF 82 and many people go to the mic to comment, I think this issue needs to be further addressed. Therefore, please request a SAVI WG meeting session at IETF83, so that we can continue the discussion. thanks, Jun Bi -----鍘熷閭欢----- From: Jean-Michel Combes Sent: Wednesday, December 07, 2011 8:20 AM To: SAVI Mailing List Subject: [savi] [IETF83] Important dates Hi, just a friendly reminder (due to Christmas holidays, deadlines will arrive quickly): 2011-12-19 (Monday): Working Group and BOF scheduling begins. To request a Working Group session, use the IETF Meeting Session Request Tool. 2012-01-30 (Monday): Cutoff date for requests to schedule Working Group meetings at 17:00 PT (UTC -8). To request a Working Group session, use the IETF Meeting Session Request Tool. As said during the last SAVI meeting, if no real interest regarding topics for a potential rechartering on the ML, no meeting during the next IETF meeting and the WG will close as soon as current WG docs will be finalized. Hope that helps. Best regards. JMC. _______________________________________________ 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 internet-drafts@ietf.org Tue Dec 27 18:44:50 2011 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFDA021F891D; Tue, 27 Dec 2011 18:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3+5E533PnWD; Tue, 27 Dec 2011 18:44:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B6721F8569; Tue, 27 Dec 2011 18:44:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20111228024449.16406.6230.idtracker@ietfa.amsl.com> Date: Tue, 27 Dec 2011 18:44:49 -0800 Cc: savi@ietf.org Subject: [savi] I-D Action: draft-ietf-savi-dhcp-11.txt X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 02:44:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Source Address Validation Improvement= s Working Group of the IETF. Title : SAVI Solution for DHCP Author(s) : Jun Bi Jianping Wu Guang Yao Fred Baker Filename : draft-ietf-savi-dhcp-11.txt Pages : 26 Date : 2011-12-27 This document specifies the procedure for creating bindings between a DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and a binding anchor [I-D.ietf-savi-framework] on SAVI (Source Address Validation Improvements) device. The bindings can be used to filter packets generated on the local link with forged source IP address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-savi-dhcp-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-savi-dhcp-11.txt