From jeanmichel.combes@gmail.com Mon Sep 5 10:07:58 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 C2BE721F8B8F for ; Mon, 5 Sep 2011 10:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.012 X-Spam-Level: X-Spam-Status: No, score=-103.012 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, 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 jQdQUMIUfsxf for ; Mon, 5 Sep 2011 10:07:57 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id AB7A321F8B85 for ; Mon, 5 Sep 2011 10:07:57 -0700 (PDT) Received: by gxk19 with SMTP id 19so4089858gxk.31 for ; Mon, 05 Sep 2011 10:09:41 -0700 (PDT) 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=dpyOT6Z570YtI65ZoA2V5CoPFKKEmQPyPKrxD0BN51o=; b=gLg4XEl+DTKHtU4t9OoxAnEwer8WTYpbsoXf2POVk4OTlZgtjQJeA1dvcpCyzOJgcM FPmg91DRDKsiV0ESmmZls099t2NQfbUDE6NMFvbi4PPtXtBJc+qDYYYvE3qK2Uq1Fm3z ft0Lv/QMhQSwGK9FvCSRyuKOkhQEBBHVBIsZU= MIME-Version: 1.0 Received: by 10.236.200.195 with SMTP id z43mr18733559yhn.127.1315242580976; Mon, 05 Sep 2011 10:09:40 -0700 (PDT) Received: by 10.146.83.11 with HTTP; Mon, 5 Sep 2011 10:09:40 -0700 (PDT) In-Reply-To: <4E548BD0.20907@joelhalpern.com> References: <4E01F2FF.7030108@acm.org> <4E0A11D8.5010300@joelhalpern.com> <4E548BD0.20907@joelhalpern.com> Date: Mon, 5 Sep 2011 19:09:40 +0200 Message-ID: From: Jean-Michel Combes To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Guang Yao , SAVI Mailing List Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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, 05 Sep 2011 17:07:58 -0000 2011/8/24 Joel M. Halpern : > Without arguing about what document things belong in, the proposed text i= s > just a paraphrase of one half of what "trusted port for dhcp" meands. > the other half, "untrusted port for dhcp" means that if the Next Header > value is detectably DHCP, but the port is not trusted for DHCP, it should= be > dropped. > Those are, I believe already in the document. > > The issue we are discussing is what more should be said about the cases > where the Next Header value can not be found. =A0This arises either when > either fragmentation moves the next header to the next message, or extra > headers move it outside of the parse capabilities of the device. Yes, this is the issue. > > It is probably sufficient to simply note that the trusted port enforcemen= t > does not handle those cases. > > The reason for putting it in the MIX document is that there is a very > similar issue for NS detection. Yes. BTW, maybe, MIX deployment may complicate the situation too because this includes many SAVI solutions (and so their consequent drawbacks). Best regards. JMC. > > Yours, > Joel > > On 8/23/2011 10:55 PM, Jun Bi wrote: >> >> I agree with Guang Yao. >> thanks, >> Jun Bi >> *From:* Guang Yao >> *Sent:* Monday, August 22, 2011 5:19 PM >> *To:* Jean-Michel Combes >> *Cc:* SAVI Mailing List >> *Subject:* Re: [savi] Potential issue for all SAVI mechanisms? >> Hi, >> I agree with the text. However, in DHCP case, only DHCP message from >> dhcp-trust and savi-validation port is processed by the SAVI device. So >> I add the condition as follows. >> -If the Next Header value inside the Fragment header is DHCP, / and if >> the packet is from dhcp-trust port or SAVI-validation port/, the packet >> is processed by the SAVI device, >> If this condition can be implied from existing text, just remove it. >> Besides, I wonder whether it is necessary to include this in the MIX >> document, as MIX document doesn't specify the details of packet process. >> If FCFS/DHCP/SEND can each handle this problem separately, MIX can also >> handle this problem. >> >> Best regards, >> Guang >> >> 2011/8/19 Jean-Michel Combes > > >> >> =A0 =A0Hi, >> >> =A0 =A0I would like to come back on this point and find a consensus. >> =A0 =A0Here is the text I propose to be added in the Security Considerat= ions >> =A0 =A0section of any SAVI solution document (i.e., FCFS, DHCP, SEND and= MIX >> =A0 =A0documents) as residential threats: >> >> =A0 =A0> =A0 =A0DHCP SAVI> >> =A0 =A0o SAVI limitations >> =A0 =A0In some cases, the SAVI device could not be able to process IP pa= ckets >> =A0 =A0and so to update correctly the Binding Table. For example, this c= ould >> =A0 =A0be the case for encrypted packets (i.e., with IPsec/ESP) or fragm= ented >> =A0 =A0packets. To mitigate this last case, the SAVI device SHOULD proce= ed as >> =A0 =A0follows: >> =A0 =A0- If the Next Header value inside the Fragment header is ND/UDP(D= HCP), >> =A0 =A0the packet is processed by the SAVI device, >> =A0 =A0- If the Next Header value inside the Fragment header is not >> =A0 =A0ND/UDP(DHCP) but there is a binding, the packet is processed by t= he >> =A0 =A0SAVI device, >> =A0 =A0- Else the packet is dropped and the incident is logged. >> =A0 =A0 >> >> =A0 =A0Comments/alternative text (deadline: 8-september-2011) are welcom= e! >> >> =A0 =A0Thanks in advance. >> >> =A0 =A0Best regards. >> >> =A0 =A0JMC. >> >> =A0 =A02011/6/28 Jean-Michel Combes > =A0 =A0>: >> =A0 =A0 > Hi Joel, >> =A0 =A0 > >> =A0 =A0 > 2011/6/28 Joel M. Halpern > =A0 =A0>: >> =A0 =A0 >> I don't think this works. >> =A0 =A0 >> The question is not how often ND packets have that structure, >> =A0 =A0but whether >> =A0 =A0 >> 1) Hosts will accept ND packets with that structure >> =A0 =A0 >> and >> =A0 =A0 >> 2) Other protocols will use that structure. >> =A0 =A0 >> >> =A0 =A0 >> If both of those are true, which they currently are, then a S= AVI >> =A0 =A0device >> =A0 =A0 >> can not detect an ND packet which is fragmented and hiding be= hind >> =A0 =A0 >> destination options. >> =A0 =A0 >> But, contrary to your resolution below, since other protocols >> =A0 =A0use that >> =A0 =A0 >> construct, SAVI devices can not simply drop all packets that = are >> =A0 =A0 >> fragmented and where the only visible next header is destinat= ion >> =A0 =A0options >> =A0 =A0 >> (or AH, or ESP.) they would be dropping legitimate data packe= ts. >> =A0 =A0 > >> =A0 =A0 > Yep, I missed this ... So, a new proposal: >> =A0 =A0 > - if the Next Header value inside the Fragment header is >> =A0 =A0ND/UDP(DHCP), >> =A0 =A0 > the packet is processed by the SAVI device >> =A0 =A0 > - if the Next Header value inside the Fragment header is not >> =A0 =A0 > ND/UDP(DHCP) and there is a binding, the packet is processed b= y the >> =A0 =A0 > SAVI device >> =A0 =A0 > - else the packet is dropped and the incident is logged >> =A0 =A0 > >> =A0 =A0 >> >> =A0 =A0 >> It does not matter whether any legitimate sender of ND messag= es >> =A0 =A0would >> =A0 =A0 >> ever use that construct. >> =A0 =A0 >> >> =A0 =A0 >> As far as I can tell, the only path to sanity here is for the >> =A0 =A0hosts not >> =A0 =A0 >> to accept such packets. >> =A0 =A0 >> And that is a matter for 6man, not for SAVI. We should simply >> =A0 =A0document >> =A0 =A0 >> this as a residual threat. >> =A0 =A0 > >> =A0 =A0 > IMHO, this is a matter for SAVI too, because, if the SAVI devi= ce is >> =A0 =A0 > not able to process fragmented ND/DHCP packets from a node to >> =A0 =A0 > correctly update the Binding Table, by default, any packet fro= m this >> =A0 =A0 > node will be dropped by the SAVI device even if hosts accept s= uch >> =A0 =A0 > packets. >> =A0 =A0 > >> =A0 =A0 > Cheers. >> =A0 =A0 > >> =A0 =A0 > JMC. >> =A0 =A0 > >> =A0 =A0 >> >> =A0 =A0 >> Yours, >> =A0 =A0 >> Joel >> =A0 =A0 >> >> =A0 =A0 >> >> =A0 =A0 >> On 6/28/2011 1:26 PM, Jean-Michel Combes wrote: >> =A0 =A0 >>> Based on RFC 2460: >> =A0 =A0 >>> (1) the Next Header value inside the Fragment header identif= ies >> the >> =A0 =A0 >>> first header of the Fragmentable Part of the original packet >> =A0 =A0 >>> (2) The Unfragmentable Part consists of the IPv6 header plus= any >> =A0 =A0 >>> extension headers that must be processed by nodes en route t= o the >> =A0 =A0 >>> destination, that is, all headers up to and including the Ro= uting >> =A0 =A0 >>> header if present, else the Hop-by-Hop Options header if >> =A0 =A0present, else >> =A0 =A0 >>> no extension headers. >> =A0 =A0 >>> (3) Extension header order is: IPv6 header, Hop-by-Hop Optio= ns >> =A0 =A0header, >> =A0 =A0 >>> Destination Options header, Routing header, Fragment header, >> =A0 =A0 >>> Authentication header, Encapsulating Security Payload header= , >> =A0 =A0 >>> Destination Options header, upper-layer header >> =A0 =A0 >>> >> =A0 =A0 >>> So, as far as I can see, there are only 3 scenarios where th= e Next >> =A0 =A0 >>> Header value inside the Fragment header is not ND(including >> =A0 =A0SEND, as >> =A0 =A0 >>> this is just ND options)/DHCP: >> =A0 =A0 >>> (a) AH >> =A0 =A0 >>> (b) ESP >> =A0 =A0 >>> (c) Destination Option >> =A0 =A0 >>> >> =A0 =A0 >>> IMHO, ND/DHCP messages with such extension headers are not >> =A0 =A0common ... >> =A0 =A0 >>> >> =A0 =A0 >>> >> =A0 =A0 >>>> > >> =A0 =A0 >>>> > Then the SAVI devices can assume and require that the kno= wn >> =A0 =A0ULP is >> =A0 =A0 >>>> > contained in the first fragment, thus they can determine >> =A0 =A0whether a >> =A0 =A0 >>>> > packet is ND/DHCP/SEND, and reject any such packets that >> =A0 =A0include a >> =A0 =A0 >>>> > fragment header. >> =A0 =A0 >>> Indeed, we could assume for each SAVI mechanism that: >> =A0 =A0 >>> - if the Next Header value inside the Fragment header is >> =A0 =A0ND/UDP(DHCP), >> =A0 =A0 >>> the packet is processed >> =A0 =A0 >>> - else the packet is dropped and the incident is logged >> =A0 =A0 >>> >> =A0 =A0 >>> As SAVI has a site/link scope, with the logs, IMHO, it shoul= d be >> =A0 =A0 >>> easier for the SAVI admin to understand/solve the issue. >> =A0 =A0 >>> >> =A0 =A0 >>> Best regards. >> =A0 =A0 >>> >> =A0 =A0 >>> JMC. >> =A0 =A0 >>> >> =A0 =A0 >>> >> =A0 =A0 >>> >> =A0 =A0 >> >> =A0 =A0 > >> =A0 =A0_______________________________________________ >> =A0 =A0savi mailing list >> =A0 =A0savi@ietf.org >> =A0 =A0https://www.ietf.org/mailman/listinfo/savi >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi > From jeanmichel.combes@gmail.com Mon Sep 5 10:09:12 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 AC07C21F883A for ; Mon, 5 Sep 2011 10:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.011 X-Spam-Level: X-Spam-Status: No, score=-103.011 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, 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 3MZRhkv27hoR for ; Mon, 5 Sep 2011 10:09:12 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA18021F861A for ; Mon, 5 Sep 2011 10:09:11 -0700 (PDT) Received: by yxj17 with SMTP id 17so2869770yxj.31 for ; Mon, 05 Sep 2011 10:10:56 -0700 (PDT) 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 :content-type:content-transfer-encoding; bh=3xyImY6KVw5V1zF9VUF98FcwavMo0lxJe80/8DLXm/U=; b=tXmBrWSzoxk7kSkWMSo9H2gnJ0IWpcWmQtMOcDAmEjL60KJPUR+pMgQy0/ByKfP9lv MzIpRKjAOsyyk1IOQlf+o9c91axdWjEhng71+Gf4u3Afy170ehenOXo+lRzwOmlj2Ic/ 16j0xkWoLuEJCIoZuoid/ooPbt1vqWQlNxw3Q= MIME-Version: 1.0 Received: by 10.236.200.195 with SMTP id z43mr18739292yhn.127.1315242656208; Mon, 05 Sep 2011 10:10:56 -0700 (PDT) Received: by 10.146.83.11 with HTTP; Mon, 5 Sep 2011 10:10:56 -0700 (PDT) In-Reply-To: References: <4E01F2FF.7030108@acm.org> <4E0A11D8.5010300@joelhalpern.com> Date: Mon, 5 Sep 2011 19:10:56 +0200 Message-ID: From: Jean-Michel Combes To: SAVI Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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, 05 Sep 2011 17:09:12 -0000 A friendly reminder: > Comments/alternative text (deadline: 8-september-2011) are welcome! Thanks! Best regards. JMC. 2011/8/18 Jean-Michel Combes : > Hi, > > I would like to come back on this point and find a consensus. > Here is the text I propose to be added in the Security Considerations > section of any SAVI solution document (i.e., FCFS, DHCP, SEND and MIX > documents) as residential threats: > > > o SAVI limitations > In some cases, the SAVI device could not be able to process IP packets > and so to update correctly the Binding Table. For example, this could > be the case for encrypted packets (i.e., with IPsec/ESP) or fragmented > packets. To mitigate this last case, the SAVI device SHOULD proceed as > follows: > - If the Next Header value inside the Fragment header is ND/UDP(DHCP), > the packet is processed by the SAVI device, > - If the Next Header value inside the Fragment header is not > ND/UDP(DHCP) but there is a binding, the packet is processed by the > SAVI device, > - Else the packet is dropped and the incident is logged. > > > Comments/alternative text (deadline: 8-september-2011) are welcome! > > Thanks in advance. > > Best regards. > > JMC. > > 2011/6/28 Jean-Michel Combes : >> Hi Joel, >> >> 2011/6/28 Joel M. Halpern : >>> I don't think this works. >>> The question is not how often ND packets have that structure, but wheth= er >>> 1) Hosts will accept ND packets with that structure >>> and >>> 2) Other protocols will use that structure. >>> >>> If both of those are true, which they currently are, then a SAVI device >>> can not detect an ND packet which is fragmented and hiding behind >>> destination options. >>> But, contrary to your resolution below, since other protocols use that >>> construct, SAVI devices can not simply drop all packets that are >>> fragmented and where the only visible next header is destination option= s >>> (or AH, or ESP.) =A0they would be dropping legitimate data packets. >> >> Yep, I missed this ... So, a new proposal: >> - if the Next Header value inside the Fragment header is ND/UDP(DHCP), >> the packet is processed by the SAVI device >> - if the Next Header value inside the Fragment header is not >> ND/UDP(DHCP) and there is a binding, the packet is processed by the >> SAVI device >> - else the packet is dropped and the incident is logged >> >>> >>> It does not matter whether any legitimate sender of ND messages would >>> ever use that construct. >>> >>> As far as I can tell, the only path to sanity here is for the hosts not >>> to accept such packets. >>> And that is a matter for 6man, not for SAVI. =A0We should simply docume= nt >>> this as a residual threat. >> >> IMHO, this is a matter for SAVI too, because, if the SAVI device is >> not able to process fragmented ND/DHCP packets from a node to >> correctly update the Binding Table, by default, any packet from this >> node will be dropped by the SAVI device even if hosts accept such >> packets. >> >> Cheers. >> >> JMC. >> >>> >>> Yours, >>> Joel >>> >>> >>> On 6/28/2011 1:26 PM, Jean-Michel Combes wrote: >>>> Based on RFC 2460: >>>> (1) the Next Header value inside the Fragment header identifies the >>>> first header of the Fragmentable Part of the original packet >>>> (2) The Unfragmentable Part consists of the IPv6 header plus any >>>> extension headers that must be processed by nodes en route to the >>>> destination, that is, all headers up to and including the Routing >>>> header if present, else the Hop-by-Hop Options header if present, else >>>> no extension headers. >>>> (3) Extension header order is: IPv6 header, Hop-by-Hop Options header, >>>> Destination Options header, Routing header, Fragment header, >>>> Authentication header, Encapsulating Security Payload header, >>>> Destination Options header, upper-layer header >>>> >>>> So, as far as I can see, there are only 3 scenarios where the Next >>>> Header value inside the Fragment header is not ND(including SEND, as >>>> this is just ND options)/DHCP: >>>> (a) AH >>>> (b) ESP >>>> (c) Destination Option >>>> >>>> IMHO, ND/DHCP messages with such extension headers are not common ... >>>> >>>> >>>>> > >>>>> > =A0Then the SAVI devices can assume and require that the known ULP = is >>>>> > =A0contained in the first fragment, thus they can determine whether= a >>>>> > =A0packet is ND/DHCP/SEND, and reject any such packets that include= a >>>>> > =A0fragment header. >>>> Indeed, we could assume for each SAVI mechanism that: >>>> - if the Next Header value inside the Fragment header is ND/UDP(DHCP), >>>> the packet is processed >>>> - else the packet is dropped and the incident is logged >>>> >>>> As SAVI has a site/link scope, with the logs, IMHO, it should be >>>> easier for the SAVI admin to understand/solve the issue. >>>> >>>> Best regards. >>>> >>>> JMC. >>>> >>>> >>>> >>> >> > From alberto@it.uc3m.es Tue Sep 6 04:44:34 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 7AAF521F86A4 for ; Tue, 6 Sep 2011 04:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_29=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 3nSTV1hZuBnJ for ; Tue, 6 Sep 2011 04:44:33 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id E90DE21F86A2 for ; Tue, 6 Sep 2011 04:44:30 -0700 (PDT) X-uc3m-safe: yes Received: from BOMBO (unknown [163.117.139.71]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 3345D7F4539; Tue, 6 Sep 2011 13:46:14 +0200 (CEST) From: =?iso-8859-1?Q?Alberto_Garc=EDa?= To: "'Jean-Michel Combes'" , "'SAVI Mailing List'" References: <4E01F2FF.7030108@acm.org> <4E0A11D8.5010300@joelhalpern.com> In-Reply-To: Date: Tue, 6 Sep 2011 13:46:40 +0200 Message-ID: <000001cc6c8a$a4857c80$ed907580$@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFTB4vJwakhVfIfNKzvlDJLZuN+EQINlRVdAbHq4KYA5WEYMgGuC5/rlfplIlA= Content-Language: es X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18368.003 Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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 Sep 2011 11:44:34 -0000 Hi, Caching up - still within the deadline :-) | -----Mensaje original----- | De: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] En nombre de | Jean-Michel Combes | Enviado el: jueves, 18 de agosto de 2011 19:51 | Para: SAVI Mailing List | Asunto: Re: [savi] Potential issue for all SAVI mechanisms? | =20 | Hi, | =20 | I would like to come back on this point and find a consensus. | Here is the text I propose to be added in the Security Considerations I agree that the issue must be considered, although I think that the corresponding text should not appear in the Security Considerations, but = in the specification of the mechanism. In my opinion, it is not a security = side effect of the deployment of a SAVI mechanism, but part of the functional specification to address the fragmentation case (and the case in which = there are other headers before). In addition, I don't like very much to have 'behaviors' being specified in many different sections. The security considerations should just consider the case in which this fragmentation processing is used by a malicious user to perform a DoS attack. I have made the exercise of try to adapt this to SEND SAVI, and I ended = up with the text I include below (based on Jean-Michel initial text). The = main differences with Jean-Michel's text are - the approach is to address the general case in which IPv6 extension headers appear: I think we need to state what should it be done in this = case (for which fragmentation is a particular case). My opinion is that SAVI devices should jump over the possible headers looking for ND information (SEND is heavy in terms of processing, so just adding this processing = does not seem to be awkward - may other scenarios should be dealt with differently). However, for the fragmentation particular case, I adhere = to the idea of only processing if the next header to the fragmentation = header is ICMPv6 (because I think the cost of reassembling is heavier than just inspecting many headers of a packet).=20 - I have tried to clarify which does 'process the packets' (for the fragmented packet) mean in this context (whether the fragments should be forwarded or not, how/when...) - security considerations deals with DoS attacks exploiting this = behavior What do you think? ---- "4.4 Processing messages containing IPv6 extension headers It may occur that SEND messages relevant for SEND SAVI operation contain IPv6 extension headers located before the SEND information. To ensure = that these messages are processed, the SEND SAVI device SHOULD inspect any = packet containing IPv6 extension headers until it could determine whether it includes relevant SEND information for SEND SAVI operation or not.=20 A particular case of this inspection occurs if the SEND message is fragmented. In order to process fragmented SEND messages, the SEND SAVI device SHOULD proceed as follows: When a SEND SAVI device receives a fragmented packet, it SHOULD inspect = the Next Header value inside the Fragment header to check if it is an ICMPv6 message. If the Fragment header does not point to an ICMPv6 message, = then the packet MUST be treated as a data packet by the SEND SAVI device.=20 Fragment packets pointing to ICMPv6 messages SHOULD be reassembled by = the SEND SAVI device according to [RFC2460]. The fragments MUST NOT be = forwarded until the packet is reassembled and processed according to the SEND SAVI specification (the SEND SAVI specification will ultimately determine if = the message should be forwarded or not, and to which ports). When the SEND = SAVI specification indicates that the message should be forwarded, the SEND = SAVI device MAY forward the fragments as received originally, or it MAY = forward the message fragmented in a different way, or it MAY forward the = reassembled message in a single packet. Note that fragmented packets in which the fragment header does not point = to an ICMPv6 message are processed as data packets by the SEND SAVI device, i.e. they are forwarded if the state associated to the source address is VALID, TENTATIVE_DAD, TESTING_VP and TESTING_VP', and discarded = otherwise. These packets are not further processed by the SEND SAVI device to = update the SAVI state; this would be the case, for example, for a fragmented = packet containing a Destination option and then a ND message. The reason for = not reassembling such packets is to avoid incurring in the cost for = reassembling packets that are unlikely to contain SEND messages." ---- [Next paragraph to be added to Security considerations, in the '5.2. Protection Against Denial of Service Attacks' subsection] The inclusion of extension headers in any packet, or the fragmentation = of packets containing SEND messages, can be used to stress the SAVI device = by requiring large amount of resources to inspect packets and reassemble = the fragments. A SEND SAVI device MUST limit the amount of resources used to store and process these packets, for example by rate-limiting the = processing of packets containing extension headers (or fragmented packets pointing = to ICMPv6 message), in a per-port basis. Regards, Alberto | section of any SAVI solution document (i.e., FCFS, DHCP, SEND and MIX | documents) as residential threats: | =20 | o SAVI limitations In some cases, the SAVI device could not be = able to | process IP packets and so to update correctly the Binding Table. For | example, this could be the case for encrypted packets (i.e., with IPsec/ESP) | or fragmented packets. To mitigate this last case, the SAVI device = SHOULD | proceed as | follows: | - If the Next Header value inside the Fragment header is = ND/UDP(DHCP), the | packet is processed by the SAVI device, | - If the Next Header value inside the Fragment header is not | ND/UDP(DHCP) but there is a binding, the packet is processed by the = SAVI | device, | - Else the packet is dropped and the incident is logged. | | =20 | Comments/alternative text (deadline: 8-september-2011) are welcome! | =20 | Thanks in advance. | =20 | Best regards. | =20 | JMC. | =20 | 2011/6/28 Jean-Michel Combes : | > Hi Joel, | > | > 2011/6/28 Joel M. Halpern : | >> I don't think this works. | >> The question is not how often ND packets have that structure, but | >> whether | >> 1) Hosts will accept ND packets with that structure and | >> 2) Other protocols will use that structure. | >> | >> If both of those are true, which they currently are, then a SAVI | >> device can not detect an ND packet which is fragmented and hiding | >> behind destination options. | >> But, contrary to your resolution below, since other protocols use | >> that construct, SAVI devices can not simply drop all packets that = are | >> fragmented and where the only visible next header is destination | >> options (or AH, or ESP.) =A0they would be dropping legitimate data packets. | > | > Yep, I missed this ... So, a new proposal: | > - if the Next Header value inside the Fragment header is = ND/UDP(DHCP), | > the packet is processed by the SAVI device | > - if the Next Header value inside the Fragment header is not | > ND/UDP(DHCP) and there is a binding, the packet is processed by the | > SAVI device | > - else the packet is dropped and the incident is logged | > | >> | >> It does not matter whether any legitimate sender of ND messages = would | >> ever use that construct. | >> | >> As far as I can tell, the only path to sanity here is for the = hosts | >> not to accept such packets. | >> And that is a matter for 6man, not for SAVI. =A0We should simply | >> document this as a residual threat. | > | > IMHO, this is a matter for SAVI too, because, if the SAVI device is | > not able to process fragmented ND/DHCP packets from a node to | > correctly update the Binding Table, by default, any packet from = this | > node will be dropped by the SAVI device even if hosts accept such | > packets. | > | > Cheers. | > | > JMC. | > | >> | >> Yours, | >> Joel | >> | >> | >> On 6/28/2011 1:26 PM, Jean-Michel Combes wrote: | >>> Based on RFC 2460: | >>> (1) the Next Header value inside the Fragment header identifies = the | >>> first header of the Fragmentable Part of the original packet | >>> (2) The Unfragmentable Part consists of the IPv6 header plus any | >>> extension headers that must be processed by nodes en route to the | >>> destination, that is, all headers up to and including the Routing | >>> header if present, else the Hop-by-Hop Options header if present, | >>> else no extension headers. | >>> (3) Extension header order is: IPv6 header, Hop-by-Hop Options | >>> header, Destination Options header, Routing header, Fragment = header, | >>> Authentication header, Encapsulating Security Payload header, | >>> Destination Options header, upper-layer header | >>> | >>> So, as far as I can see, there are only 3 scenarios where the = Next | >>> Header value inside the Fragment header is not ND(including SEND, = as | >>> this is just ND options)/DHCP: | >>> (a) AH | >>> (b) ESP | >>> (c) Destination Option | >>> | >>> IMHO, ND/DHCP messages with such extension headers are not | common ... | >>> | >>> | >>>> > | >>>> > =A0Then the SAVI devices can assume and require that the known = ULP | >>>> > is | >>>> > =A0contained in the first fragment, thus they can determine = whether | >>>> > a | >>>> > =A0packet is ND/DHCP/SEND, and reject any such packets that = include | >>>> > a | >>>> > =A0fragment header. | >>> Indeed, we could assume for each SAVI mechanism that: | >>> - if the Next Header value inside the Fragment header is | >>> ND/UDP(DHCP), the packet is processed | >>> - else the packet is dropped and the incident is logged | >>> | >>> As SAVI has a site/link scope, with the logs, IMHO, it should be | >>> easier for the SAVI admin to understand/solve the issue. | >>> | >>> Best regards. | >>> | >>> JMC. | >>> | >>> | >>> | >> | > | _______________________________________________ | savi mailing list | savi@ietf.org | https://www.ietf.org/mailman/listinfo/savi From jmh@joelhalpern.com Tue Sep 6 07:21:24 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 038DD21F84AA for ; Tue, 6 Sep 2011 07:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.087 X-Spam-Level: X-Spam-Status: No, score=-102.087 tagged_above=-999 required=5 tests=[AWL=-0.388, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, MIME_8BIT_HEADER=0.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 Z34pJ+mn+iGy for ; Tue, 6 Sep 2011 07:21:23 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:16]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9E021F8472 for ; Tue, 6 Sep 2011 07:21:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B2C724300FA; Tue, 6 Sep 2011 07:23:09 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.104] (pool-71-161-52-215.clppva.btas.verizon.net [71.161.52.215]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 67B12430104; Tue, 6 Sep 2011 07:23:08 -0700 (PDT) Message-ID: <4E662CAF.1010905@joelhalpern.com> Date: Tue, 06 Sep 2011 10:22:39 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Alberto_Garc=EDa?= , SAVI Mailing List References: <4E01F2FF.7030108@acm.org> <4E0A11D8.5010300@joelhalpern.com> <000001cc6c8a$a4857c80$ed907580$@it.uc3m.es> In-Reply-To: <000001cc6c8a$a4857c80$ed907580$@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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 Sep 2011 14:21:24 -0000 There seems to be an assumption in the fragment processing text that the next header that points to the ICMP will be in the first packet. The reason there is a security threat is that an attacker can carefully compose a packet such that the ICMP header is not in the first packet, and even the next-hezader type pointing to the ICMP is not in the first fragment. That needs to be identified. That is what needs to be identified in the security considerations section. As a separate matter, given the complexity of SEND it may be reasonable for SAVI SEND to require parsing all the headers in the first fragment, where other SAVI cases probably can not do so. That is up to the WG. Yours, Joel On 9/6/2011 7:46 AM, Alberto García wrote: > Hi, > Caching up - still within the deadline :-) > > | -----Mensaje original----- > | De: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] En nombre de > | Jean-Michel Combes > | Enviado el: jueves, 18 de agosto de 2011 19:51 > | Para: SAVI Mailing List > | Asunto: Re: [savi] Potential issue for all SAVI mechanisms? > | > | Hi, > | > | I would like to come back on this point and find a consensus. > | Here is the text I propose to be added in the Security Considerations > > I agree that the issue must be considered, although I think that the > corresponding text should not appear in the Security Considerations, but in > the specification of the mechanism. In my opinion, it is not a security side > effect of the deployment of a SAVI mechanism, but part of the functional > specification to address the fragmentation case (and the case in which there > are other headers before). In addition, I don't like very much to have > 'behaviors' being specified in many different sections. The security > considerations should just consider the case in which this fragmentation > processing is used by a malicious user to perform a DoS attack. > > I have made the exercise of try to adapt this to SEND SAVI, and I ended up > with the text I include below (based on Jean-Michel initial text). The main > differences with Jean-Michel's text are > - the approach is to address the general case in which IPv6 extension > headers appear: I think we need to state what should it be done in this case > (for which fragmentation is a particular case). My opinion is that SAVI > devices should jump over the possible headers looking for ND information > (SEND is heavy in terms of processing, so just adding this processing does > not seem to be awkward - may other scenarios should be dealt with > differently). However, for the fragmentation particular case, I adhere to > the idea of only processing if the next header to the fragmentation header > is ICMPv6 (because I think the cost of reassembling is heavier than just > inspecting many headers of a packet). > - I have tried to clarify which does 'process the packets' (for the > fragmented packet) mean in this context (whether the fragments should be > forwarded or not, how/when...) > - security considerations deals with DoS attacks exploiting this behavior > > What do you think? > > ---- > > "4.4 Processing messages containing IPv6 extension headers > It may occur that SEND messages relevant for SEND SAVI operation contain > IPv6 extension headers located before the SEND information. To ensure that > these messages are processed, the SEND SAVI device SHOULD inspect any packet > containing IPv6 extension headers until it could determine whether it > includes relevant SEND information for SEND SAVI operation or not. > > A particular case of this inspection occurs if the SEND message is > fragmented. In order to process fragmented SEND messages, the SEND SAVI > device SHOULD proceed as follows: > When a SEND SAVI device receives a fragmented packet, it SHOULD inspect the > Next Header value inside the Fragment header to check if it is an ICMPv6 > message. If the Fragment header does not point to an ICMPv6 message, then > the packet MUST be treated as a data packet by the SEND SAVI device. > Fragment packets pointing to ICMPv6 messages SHOULD be reassembled by the > SEND SAVI device according to [RFC2460]. The fragments MUST NOT be forwarded > until the packet is reassembled and processed according to the SEND SAVI > specification (the SEND SAVI specification will ultimately determine if the > message should be forwarded or not, and to which ports). When the SEND SAVI > specification indicates that the message should be forwarded, the SEND SAVI > device MAY forward the fragments as received originally, or it MAY forward > the message fragmented in a different way, or it MAY forward the reassembled > message in a single packet. > > Note that fragmented packets in which the fragment header does not point to > an ICMPv6 message are processed as data packets by the SEND SAVI device, > i.e. they are forwarded if the state associated to the source address is > VALID, TENTATIVE_DAD, TESTING_VP and TESTING_VP', and discarded otherwise. > These packets are not further processed by the SEND SAVI device to update > the SAVI state; this would be the case, for example, for a fragmented packet > containing a Destination option and then a ND message. The reason for not > reassembling such packets is to avoid incurring in the cost for reassembling > packets that are unlikely to contain SEND messages." > ---- > [Next paragraph to be added to Security considerations, in the '5.2. > Protection Against Denial of Service Attacks' subsection] > The inclusion of extension headers in any packet, or the fragmentation of > packets containing SEND messages, can be used to stress the SAVI device by > requiring large amount of resources to inspect packets and reassemble the > fragments. A SEND SAVI device MUST limit the amount of resources used to > store and process these packets, for example by rate-limiting the processing > of packets containing extension headers (or fragmented packets pointing to > ICMPv6 message), in a per-port basis. > > > Regards, > Alberto > > > | section of any SAVI solution document (i.e., FCFS, DHCP, SEND and MIX > | documents) as residential threats: > | > | | SAVI> o SAVI limitations In some cases, the SAVI device could not be able > to > | process IP packets and so to update correctly the Binding Table. For > | example, this could be the case for encrypted packets (i.e., with > IPsec/ESP) > | or fragmented packets. To mitigate this last case, the SAVI device SHOULD > | proceed as > | follows: > | - If the Next Header value inside the Fragment header is ND/UDP(DHCP), > the > | packet is processed by the SAVI device, > | - If the Next Header value inside the Fragment header is not > | ND/UDP(DHCP) but there is a binding, the packet is processed by the SAVI > | device, > | - Else the packet is dropped and the incident is logged. > | > | > | Comments/alternative text (deadline: 8-september-2011) are welcome! > | > | Thanks in advance. > | > | Best regards. > | > | JMC. > | > | 2011/6/28 Jean-Michel Combes: > |> Hi Joel, > |> > |> 2011/6/28 Joel M. Halpern: > |>> I don't think this works. > |>> The question is not how often ND packets have that structure, but > |>> whether > |>> 1) Hosts will accept ND packets with that structure and > |>> 2) Other protocols will use that structure. > |>> > |>> If both of those are true, which they currently are, then a SAVI > |>> device can not detect an ND packet which is fragmented and hiding > |>> behind destination options. > |>> But, contrary to your resolution below, since other protocols use > |>> that construct, SAVI devices can not simply drop all packets that are > |>> fragmented and where the only visible next header is destination > |>> options (or AH, or ESP.) they would be dropping legitimate data > packets. > |> > |> Yep, I missed this ... So, a new proposal: > |> - if the Next Header value inside the Fragment header is ND/UDP(DHCP), > |> the packet is processed by the SAVI device > |> - if the Next Header value inside the Fragment header is not > |> ND/UDP(DHCP) and there is a binding, the packet is processed by the > |> SAVI device > |> - else the packet is dropped and the incident is logged > |> > |>> > |>> It does not matter whether any legitimate sender of ND messages would > |>> ever use that construct. > |>> > |>> As far as I can tell, the only path to sanity here is for the hosts > |>> not to accept such packets. > |>> And that is a matter for 6man, not for SAVI. We should simply > |>> document this as a residual threat. > |> > |> IMHO, this is a matter for SAVI too, because, if the SAVI device is > |> not able to process fragmented ND/DHCP packets from a node to > |> correctly update the Binding Table, by default, any packet from this > |> node will be dropped by the SAVI device even if hosts accept such > |> packets. > |> > |> Cheers. > |> > |> JMC. > |> > |>> > |>> Yours, > |>> Joel > |>> > |>> > |>> On 6/28/2011 1:26 PM, Jean-Michel Combes wrote: > |>>> Based on RFC 2460: > |>>> (1) the Next Header value inside the Fragment header identifies the > |>>> first header of the Fragmentable Part of the original packet > |>>> (2) The Unfragmentable Part consists of the IPv6 header plus any > |>>> extension headers that must be processed by nodes en route to the > |>>> destination, that is, all headers up to and including the Routing > |>>> header if present, else the Hop-by-Hop Options header if present, > |>>> else no extension headers. > |>>> (3) Extension header order is: IPv6 header, Hop-by-Hop Options > |>>> header, Destination Options header, Routing header, Fragment header, > |>>> Authentication header, Encapsulating Security Payload header, > |>>> Destination Options header, upper-layer header > |>>> > |>>> So, as far as I can see, there are only 3 scenarios where the Next > |>>> Header value inside the Fragment header is not ND(including SEND, as > |>>> this is just ND options)/DHCP: > |>>> (a) AH > |>>> (b) ESP > |>>> (c) Destination Option > |>>> > |>>> IMHO, ND/DHCP messages with such extension headers are not > | common ... > |>>> > |>>> > |>>>> > > |>>>> > Then the SAVI devices can assume and require that the known ULP > |>>>> > is > |>>>> > contained in the first fragment, thus they can determine whether > |>>>> > a > |>>>> > packet is ND/DHCP/SEND, and reject any such packets that include > |>>>> > a > |>>>> > fragment header. > |>>> Indeed, we could assume for each SAVI mechanism that: > |>>> - if the Next Header value inside the Fragment header is > |>>> ND/UDP(DHCP), the packet is processed > |>>> - else the packet is dropped and the incident is logged > |>>> > |>>> As SAVI has a site/link scope, with the logs, IMHO, it should be > |>>> easier for the SAVI admin to understand/solve the issue. > |>>> > |>>> 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 alberto@it.uc3m.es Tue Sep 6 10:03:01 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 A9F0D21F8BAC for ; Tue, 6 Sep 2011 10:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_29=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 xGPuYS1MmIu1 for ; Tue, 6 Sep 2011 10:03:00 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id E5D0421F8BA7 for ; Tue, 6 Sep 2011 10:02:59 -0700 (PDT) X-uc3m-safe: yes Received: from BOMBO (unknown [163.117.139.71]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 9210375A22B; Tue, 6 Sep 2011 19:04:45 +0200 (CEST) From: =?iso-8859-1?Q?Alberto_Garc=EDa?= To: "'Joel M. Halpern'" , "'SAVI Mailing List'" References: <4E01F2FF.7030108@acm.org> <4E0A11D8.5010300@joelhalpern.com> <000001cc6c8a$a4857c80$ed907580$@it.uc3m.es> <4E662CAF.1010905@joelhalpern.com> In-Reply-To: <4E662CAF.1010905@joelhalpern.com> Date: Tue, 6 Sep 2011 19:05:11 +0200 Message-ID: <003c01cc6cb7$238670d0$6a935270$@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFTB4vJwakhVfIfNKzvlDJLZuN+EQINlRVdAbHq4KYA5WEYMgGuC5/rAcdsZG8C+kqQyJXak6tQ Content-Language: es X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18370.000 Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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 Sep 2011 17:03:01 -0000 Hi Joel, | -----Mensaje original----- | De: Joel M. Halpern [mailto:jmh@joelhalpern.com] | Enviado el: martes, 06 de septiembre de 2011 16:23 | Para: Alberto Garc=EDa; SAVI Mailing List | Asunto: Re: [savi] Potential issue for all SAVI mechanisms? | =20 | There seems to be an assumption in the fragment processing text that = the | next header that points to the ICMP will be in the first packet. I think the assumption is that the first header after the Fragmentation header is ICMP.=20 Every fragment has its fragmentation header, and as I have understood = from RFC 2460, on each of these fragments, the Next header of the = Fragmentation header will very likely contain the value of the first header after the fragmentation one, i.e. ICMP. That is, it is not relevant if the = fragments are received in order or not, because all will probably have the ICMP = 'next header' value, being this an indication that they have to be = reassembled. So being the first packet does not seem to be relevant.=20 Although I think it is very unlikely to expect so, it may be a problem = if the fragments arrive disordered to the SAVI device and the ICMP header = is not the first, because the first received fragment (but not the first fragment in the fragmentation sequence) would not be identified as containing ICMP information. So it is not enough to have the header in = the first packet, but to have the ICMP header immediately after the Fragmentation header. Does this make sense? Do you think that we should process also packets containing ICMP = messages which are not immediately after the Fragmentation header?=20 If so, I think that every fragmented packet should be reassembled, and = then checked, which would be overkill for the SAVI device.=20 | =20 | The reason there is a security threat is that an attacker can = carefully | compose a packet such that the ICMP header is not in the first = packet, and | even the next-hezader type pointing to the ICMP is not in the first | fragment. If I understand properly, the problem you are stating is that the SAVI devices could forward the packet as 'data', with a source address that = is valid for the sender at the port at which it is validated, but the = message can convey 'false' ND information (I assume that for a different = [source] address of that used to send the packet) which may influence in the ND caches of the destination nodes, isn=92t it?=20 If this is the case, I still don't figure out which is the security = problem, at least for SEND and ND. First, it seems that it does not affect to the Source Address Validation function, which is the main reason for SAVI, = since the packet sent is valid from this point of view (the sender should have been able to prove its address ownership before sending this data). SAVI = is now not intended to validate other information, such as the validity of = the contents of ND information. Besides, for SEND deployments, the = destination is going to check that the message received has been signed with the key associated to the address for which the message declares something, according to the SEND specification.=20 However, I have the feeling that there is something I have not = understood, sorry. | =20 | That needs to be identified. That is what needs to be identified in = the | security considerations section. | =20 | As a separate matter, given the complexity of SEND it may be = reasonable | for SAVI SEND to require parsing all the headers in the first = fragment, where | other SAVI cases probably can not do so. That is up to the WG. The problem with this is that the first fragment may not arrive in the = first place (as I said before), and other fragments arriving before may not be available for reassembling.=20 Regards, Alberto | =20 | Yours, | Joel | =20 | On 9/6/2011 7:46 AM, Alberto Garc=EDa wrote: | > Hi, | > Caching up - still within the deadline :-) | > | > | -----Mensaje original----- | > | De: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] En = nombre | > | de Jean-Michel Combes Enviado el: jueves, 18 de agosto de 2011 | > | 19:51 | > | Para: SAVI Mailing List | > | Asunto: Re: [savi] Potential issue for all SAVI mechanisms? | > | | > | Hi, | > | | > | I would like to come back on this point and find a consensus. | > | Here is the text I propose to be added in the Security | > | Considerations | > | > I agree that the issue must be considered, although I think that = the | > corresponding text should not appear in the Security = Considerations, | > but in the specification of the mechanism. In my opinion, it is not = a | > security side effect of the deployment of a SAVI mechanism, but = part | > of the functional specification to address the fragmentation case = (and | > the case in which there are other headers before). In addition, I | > don't like very much to have 'behaviors' being specified in many | > different sections. The security considerations should just = consider | > the case in which this fragmentation processing is used by a = malicious | user to perform a DoS attack. | > | > I have made the exercise of try to adapt this to SEND SAVI, and I | > ended up with the text I include below (based on Jean-Michel = initial | > text). The main differences with Jean-Michel's text are | > - the approach is to address the general case in which IPv6 = extension | > headers appear: I think we need to state what should it be done in | > this case (for which fragmentation is a particular case). My = opinion | > is that SAVI devices should jump over the possible headers looking = for | > ND information (SEND is heavy in terms of processing, so just = adding | > this processing does not seem to be awkward - may other scenarios | > should be dealt with differently). However, for the fragmentation | > particular case, I adhere to the idea of only processing if the = next | > header to the fragmentation header is ICMPv6 (because I think the = cost | > of reassembling is heavier than just inspecting many headers of a packet). | > - I have tried to clarify which does 'process the packets' (for the | > fragmented packet) mean in this context (whether the fragments = should | > be forwarded or not, how/when...) | > - security considerations deals with DoS attacks exploiting this | > behavior | > | > What do you think? | > | > ---- | > DHCP> | > "4.4 Processing messages containing IPv6 extension headers It may | > occur that SEND messages relevant for SEND SAVI operation contain | > IPv6 extension headers located before the SEND information. To = ensure | > that these messages are processed, the SEND SAVI device SHOULD = inspect | > any packet containing IPv6 extension headers until it could = determine | > whether it includes relevant SEND information for SEND SAVI = operation or | not. | > | > A particular case of this inspection occurs if the SEND message is | > fragmented. In order to process fragmented SEND messages, the SEND | > SAVI device SHOULD proceed as follows: | > When a SEND SAVI device receives a fragmented packet, it SHOULD | > inspect the Next Header value inside the Fragment header to check = if | > it is an ICMPv6 message. If the Fragment header does not point to = an | > ICMPv6 message, then the packet MUST be treated as a data packet by | the SEND SAVI device. | > Fragment packets pointing to ICMPv6 messages SHOULD be reassembled | by | > the SEND SAVI device according to [RFC2460]. The fragments MUST NOT | be | > forwarded until the packet is reassembled and processed according = to | > the SEND SAVI specification (the SEND SAVI specification will | > ultimately determine if the message should be forwarded or not, and = to | > which ports). When the SEND SAVI specification indicates that the | > message should be forwarded, the SEND SAVI device MAY forward the | > fragments as received originally, or it MAY forward the message | > fragmented in a different way, or it MAY forward the reassembled | message in a single packet. | > | > Note that fragmented packets in which the fragment header does not | > point to an ICMPv6 message are processed as data packets by the = SEND | > SAVI device, i.e. they are forwarded if the state associated to the | > source address is VALID, TENTATIVE_DAD, TESTING_VP and = TESTING_VP', | and discarded otherwise. | > These packets are not further processed by the SEND SAVI device to | > update the SAVI state; this would be the case, for example, for a | > fragmented packet containing a Destination option and then a ND | > message. The reason for not reassembling such packets is to avoid | > incurring in the cost for reassembling packets that are unlikely to contain | SEND messages." | > ---- | > [Next paragraph to be added to Security considerations, in the = '5.2. | > Protection Against Denial of Service Attacks' subsection] The | > inclusion of extension headers in any packet, or the fragmentation = of | > packets containing SEND messages, can be used to stress the SAVI | > device by requiring large amount of resources to inspect packets = and | > reassemble the fragments. A SEND SAVI device MUST limit the amount = of | > resources used to store and process these packets, for example by | > rate-limiting the processing of packets containing extension = headers | > (or fragmented packets pointing to | > ICMPv6 message), in a per-port basis. | > | > | > Regards, | > Alberto | > | > | > | section of any SAVI solution document (i.e., FCFS, DHCP, SEND = and | > | MIX | > | documents) as residential threats: | > | | > | |DHCP | > | SAVI> o SAVI limitations In some cases, the SAVI device could = not | > |be able | > to | > | process IP packets and so to update correctly the Binding Table. | > | For example, this could be the case for encrypted packets (i.e., | > | with | > IPsec/ESP) | > | or fragmented packets. To mitigate this last case, the SAVI = device | > | SHOULD proceed as | > | follows: | > | - If the Next Header value inside the Fragment header is | > | ND/UDP(DHCP), | > the | > | packet is processed by the SAVI device, | > | - If the Next Header value inside the Fragment header is not | > | ND/UDP(DHCP) but there is a binding, the packet is processed by = the | > |SAVI | > | device, | > | - Else the packet is dropped and the incident is logged. | > | | > | | > | Comments/alternative text (deadline: 8-september-2011) are = welcome! | > | | > | Thanks in advance. | > | | > | Best regards. | > | | > | JMC. | > | | > | 2011/6/28 Jean-Michel Combes: | > |> Hi Joel, | > |> | > |> 2011/6/28 Joel M. Halpern: | > |>> I don't think this works. | > |>> The question is not how often ND packets have that structure, = but | > |>> whether | > |>> 1) Hosts will accept ND packets with that structure and | > |>> 2) Other protocols will use that structure. | > |>> | > |>> If both of those are true, which they currently are, then a = SAVI | > |>> device can not detect an ND packet which is fragmented and = hiding | > |>> behind destination options. | > |>> But, contrary to your resolution below, since other protocols = use | > |>> that construct, SAVI devices can not simply drop all packets = that | > |>> are fragmented and where the only visible next header is | > |>> destination options (or AH, or ESP.) they would be dropping | > |>> legitimate data | > packets. | > |> | > |> Yep, I missed this ... So, a new proposal: | > |> - if the Next Header value inside the Fragment header is | > |> ND/UDP(DHCP), the packet is processed by the SAVI device | > |> - if the Next Header value inside the Fragment header is not | > |> ND/UDP(DHCP) and there is a binding, the packet is processed by | > |> the SAVI device | > |> - else the packet is dropped and the incident is logged | > |> | > |>> | > |>> It does not matter whether any legitimate sender of ND = messages | > |>> would ever use that construct. | > |>> | > |>> As far as I can tell, the only path to sanity here is for the | > |>> hosts not to accept such packets. | > |>> And that is a matter for 6man, not for SAVI. We should simply | > |>> document this as a residual threat. | > |> | > |> IMHO, this is a matter for SAVI too, because, if the SAVI = device | > |> is not able to process fragmented ND/DHCP packets from a node = to | > |> correctly update the Binding Table, by default, any packet from | > |> this node will be dropped by the SAVI device even if hosts = accept | > |> such packets. | > |> | > |> Cheers. | > |> | > |> JMC. | > |> | > |>> | > |>> Yours, | > |>> Joel | > |>> | > |>> | > |>> On 6/28/2011 1:26 PM, Jean-Michel Combes wrote: | > |>>> Based on RFC 2460: | > |>>> (1) the Next Header value inside the Fragment header = identifies | > |>>> the first header of the Fragmentable Part of the original = packet | > |>>> (2) The Unfragmentable Part consists of the IPv6 header plus = any | > |>>> extension headers that must be processed by nodes en route to = the | > |>>> destination, that is, all headers up to and including the = Routing | > |>>> header if present, else the Hop-by-Hop Options header if = present, | > |>>> else no extension headers. | > |>>> (3) Extension header order is: IPv6 header, Hop-by-Hop = Options | > |>>> header, Destination Options header, Routing header, Fragment | > |>>> header, Authentication header, Encapsulating Security Payload | > |>>> header, Destination Options header, upper-layer header | > |>>> | > |>>> So, as far as I can see, there are only 3 scenarios where the | > |>>> Next Header value inside the Fragment header is not = ND(including | > |>>> SEND, as this is just ND options)/DHCP: | > |>>> (a) AH | > |>>> (b) ESP | > |>>> (c) Destination Option | > |>>> | > |>>> IMHO, ND/DHCP messages with such extension headers are not | > | common ... | > |>>> | > |>>> | > |>>>> > | > |>>>> > Then the SAVI devices can assume and require that the = known | ULP | > |>>>> > is | > |>>>> > contained in the first fragment, thus they can = determine | whether | > |>>>> > a | > |>>>> > packet is ND/DHCP/SEND, and reject any such packets = that | include | > |>>>> > a | > |>>>> > fragment header. | > |>>> Indeed, we could assume for each SAVI mechanism that: | > |>>> - if the Next Header value inside the Fragment header is | > |>>> ND/UDP(DHCP), the packet is processed | > |>>> - else the packet is dropped and the incident is logged | > |>>> | > |>>> As SAVI has a site/link scope, with the logs, IMHO, it should = be | > |>>> easier for the SAVI admin to understand/solve the issue. | > |>>> | > |>>> 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 jmh@joelhalpern.com Tue Sep 6 10:36:04 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 C349121F8B06 for ; Tue, 6 Sep 2011 10:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.083 X-Spam-Level: X-Spam-Status: No, score=-102.083 tagged_above=-999 required=5 tests=[AWL=-0.384, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, MIME_8BIT_HEADER=0.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 SrV-sEkYH5iT for ; Tue, 6 Sep 2011 10:36:03 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:16]) by ietfa.amsl.com (Postfix) with ESMTP id 9761421F8BAD for ; Tue, 6 Sep 2011 10:36:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 992E94300F1; Tue, 6 Sep 2011 10:37:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.104] (pool-71-161-52-215.clppva.btas.verizon.net [71.161.52.215]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id F079C4300EC; Tue, 6 Sep 2011 10:37:48 -0700 (PDT) Message-ID: <4E665A4F.9080608@joelhalpern.com> Date: Tue, 06 Sep 2011 13:37:19 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: =?windows-1252?Q?Alberto_Garc=EDa?= References: <4E01F2FF.7030108@acm.org> <4E0A11D8.5010300@joelhalpern.com> <000001cc6c8a$a4857c80$ed907580$@it.uc3m.es> <4E662CAF.1010905@joelhalpern.com> <003c01cc6cb7$238670d0$6a935270$@it.uc3m.es> In-Reply-To: <003c01cc6cb7$238670d0$6a935270$@it.uc3m.es> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 'SAVI Mailing List' Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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 Sep 2011 17:36:04 -0000 Your reading and mine of the fragment spec do not match. Start with an ICMP packet. Add a number of next headers before the ICMP header. Now the packet is too long. (Make it MUCH too long.) So it has to be fragmented. The next header field in the fragmentation header will point to the header which is next in the reassembled packet. Note that in fragments after the first, the bytes following the fragment header are not even the start of a header. They are whatever bytes come next in the packet. So, if the ICMP does not fit in the first packet, the only way to find it is to reassemble the whole packet. Asking every SAVI device to reassemble every packet which does not have TCP or UDP has the next header in the first fragment seems a major imposition. But that is what it would take to find the ICMP header. It seems to me much better to note this vulnerability in SAVI, and leave it there. If we want it fixed, 6man should simply instruct hosts not to accept RAs or DHCPs in fragmented packets. Yours, Joel On 9/6/2011 1:05 PM, Alberto García wrote: > Hi Joel, > > | -----Mensaje original----- > | De: Joel M. Halpern [mailto:jmh@joelhalpern.com] > | Enviado el: martes, 06 de septiembre de 2011 16:23 > | Para: Alberto García; SAVI Mailing List > | Asunto: Re: [savi] Potential issue for all SAVI mechanisms? > | > | There seems to be an assumption in the fragment processing text that the > | next header that points to the ICMP will be in the first packet. > > I think the assumption is that the first header after the Fragmentation > header is ICMP. > Every fragment has its fragmentation header, and as I have understood from > RFC 2460, on each of these fragments, the Next header of the Fragmentation > header will very likely contain the value of the first header after the > fragmentation one, i.e. ICMP. That is, it is not relevant if the fragments > are received in order or not, because all will probably have the ICMP 'next > header' value, being this an indication that they have to be reassembled. So > being the first packet does not seem to be relevant. > Although I think it is very unlikely to expect so, it may be a problem if > the fragments arrive disordered to the SAVI device and the ICMP header is > not the first, because the first received fragment (but not the first > fragment in the fragmentation sequence) would not be identified as > containing ICMP information. So it is not enough to have the header in the > first packet, but to have the ICMP header immediately after the > Fragmentation header. > Does this make sense? > > Do you think that we should process also packets containing ICMP messages > which are not immediately after the Fragmentation header? > If so, I think that every fragmented packet should be reassembled, and then > checked, which would be overkill for the SAVI device. > > | > | The reason there is a security threat is that an attacker can carefully > | compose a packet such that the ICMP header is not in the first packet, > and > | even the next-hezader type pointing to the ICMP is not in the first > | fragment. > > If I understand properly, the problem you are stating is that the SAVI > devices could forward the packet as 'data', with a source address that is > valid for the sender at the port at which it is validated, but the message > can convey 'false' ND information (I assume that for a different [source] > address of that used to send the packet) which may influence in the ND > caches of the destination nodes, isn’t it? > > If this is the case, I still don't figure out which is the security problem, > at least for SEND and ND. First, it seems that it does not affect to the > Source Address Validation function, which is the main reason for SAVI, since > the packet sent is valid from this point of view (the sender should have > been able to prove its address ownership before sending this data). SAVI is > now not intended to validate other information, such as the validity of the > contents of ND information. Besides, for SEND deployments, the destination > is going to check that the message received has been signed with the key > associated to the address for which the message declares something, > according to the SEND specification. > However, I have the feeling that there is something I have not understood, > sorry. > > | > | That needs to be identified. That is what needs to be identified in the > | security considerations section. > | > | As a separate matter, given the complexity of SEND it may be reasonable > | for SAVI SEND to require parsing all the headers in the first fragment, > where > | other SAVI cases probably can not do so. That is up to the WG. > > The problem with this is that the first fragment may not arrive in the first > place (as I said before), and other fragments arriving before may not be > available for reassembling. > > Regards, > Alberto > > | > | Yours, > | Joel > | > | On 9/6/2011 7:46 AM, Alberto García wrote: > |> Hi, > |> Caching up - still within the deadline :-) > |> > |> | -----Mensaje original----- > |> | De: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] En nombre > |> | de Jean-Michel Combes Enviado el: jueves, 18 de agosto de 2011 > |> | 19:51 > |> | Para: SAVI Mailing List > |> | Asunto: Re: [savi] Potential issue for all SAVI mechanisms? > |> | > |> | Hi, > |> | > |> | I would like to come back on this point and find a consensus. > |> | Here is the text I propose to be added in the Security > |> | Considerations > |> > |> I agree that the issue must be considered, although I think that the > |> corresponding text should not appear in the Security Considerations, > |> but in the specification of the mechanism. In my opinion, it is not a > |> security side effect of the deployment of a SAVI mechanism, but part > |> of the functional specification to address the fragmentation case (and > |> the case in which there are other headers before). In addition, I > |> don't like very much to have 'behaviors' being specified in many > |> different sections. The security considerations should just consider > |> the case in which this fragmentation processing is used by a malicious > | user to perform a DoS attack. > |> > |> I have made the exercise of try to adapt this to SEND SAVI, and I > |> ended up with the text I include below (based on Jean-Michel initial > |> text). The main differences with Jean-Michel's text are > |> - the approach is to address the general case in which IPv6 extension > |> headers appear: I think we need to state what should it be done in > |> this case (for which fragmentation is a particular case). My opinion > |> is that SAVI devices should jump over the possible headers looking for > |> ND information (SEND is heavy in terms of processing, so just adding > |> this processing does not seem to be awkward - may other scenarios > |> should be dealt with differently). However, for the fragmentation > |> particular case, I adhere to the idea of only processing if the next > |> header to the fragmentation header is ICMPv6 (because I think the cost > |> of reassembling is heavier than just inspecting many headers of a > packet). > |> - I have tried to clarify which does 'process the packets' (for the > |> fragmented packet) mean in this context (whether the fragments should > |> be forwarded or not, how/when...) > |> - security considerations deals with DoS attacks exploiting this > |> behavior > |> > |> What do you think? > |> > |> ---- > |> |> DHCP> > |> "4.4 Processing messages containing IPv6 extension headers It may > |> occur that SEND messages relevant for SEND SAVI operation contain > |> IPv6 extension headers located before the SEND information. To ensure > |> that these messages are processed, the SEND SAVI device SHOULD inspect > |> any packet containing IPv6 extension headers until it could determine > |> whether it includes relevant SEND information for SEND SAVI operation > or > | not. > |> > |> A particular case of this inspection occurs if the SEND message is > |> fragmented. In order to process fragmented SEND messages, the SEND > |> SAVI device SHOULD proceed as follows: > |> When a SEND SAVI device receives a fragmented packet, it SHOULD > |> inspect the Next Header value inside the Fragment header to check if > |> it is an ICMPv6 message. If the Fragment header does not point to an > |> ICMPv6 message, then the packet MUST be treated as a data packet by > | the SEND SAVI device. > |> Fragment packets pointing to ICMPv6 messages SHOULD be reassembled > | by > |> the SEND SAVI device according to [RFC2460]. The fragments MUST NOT > | be > |> forwarded until the packet is reassembled and processed according to > |> the SEND SAVI specification (the SEND SAVI specification will > |> ultimately determine if the message should be forwarded or not, and to > |> which ports). When the SEND SAVI specification indicates that the > |> message should be forwarded, the SEND SAVI device MAY forward the > |> fragments as received originally, or it MAY forward the message > |> fragmented in a different way, or it MAY forward the reassembled > | message in a single packet. > |> > |> Note that fragmented packets in which the fragment header does not > |> point to an ICMPv6 message are processed as data packets by the SEND > |> SAVI device, i.e. they are forwarded if the state associated to the > |> source address is VALID, TENTATIVE_DAD, TESTING_VP and TESTING_VP', > | and discarded otherwise. > |> These packets are not further processed by the SEND SAVI device to > |> update the SAVI state; this would be the case, for example, for a > |> fragmented packet containing a Destination option and then a ND > |> message. The reason for not reassembling such packets is to avoid > |> incurring in the cost for reassembling packets that are unlikely to > contain > | SEND messages." > |> ---- > |> [Next paragraph to be added to Security considerations, in the '5.2. > |> Protection Against Denial of Service Attacks' subsection] The > |> inclusion of extension headers in any packet, or the fragmentation of > |> packets containing SEND messages, can be used to stress the SAVI > |> device by requiring large amount of resources to inspect packets and > |> reassemble the fragments. A SEND SAVI device MUST limit the amount of > |> resources used to store and process these packets, for example by > |> rate-limiting the processing of packets containing extension headers > |> (or fragmented packets pointing to > |> ICMPv6 message), in a per-port basis. > |> > |> > |> Regards, > |> Alberto > |> > |> > |> | section of any SAVI solution document (i.e., FCFS, DHCP, SEND and > |> | MIX > |> | documents) as residential threats: > |> | > |> | |> |DHCP > |> | SAVI> o SAVI limitations In some cases, the SAVI device could not > |> |be able > |> to > |> | process IP packets and so to update correctly the Binding Table. > |> | For example, this could be the case for encrypted packets (i.e., > |> | with > |> IPsec/ESP) > |> | or fragmented packets. To mitigate this last case, the SAVI device > |> | SHOULD proceed as > |> | follows: > |> | - If the Next Header value inside the Fragment header is > |> | ND/UDP(DHCP), > |> the > |> | packet is processed by the SAVI device, > |> | - If the Next Header value inside the Fragment header is not > |> | ND/UDP(DHCP) but there is a binding, the packet is processed by the > |> |SAVI > |> | device, > |> | - Else the packet is dropped and the incident is logged. > |> | > |> | > |> | Comments/alternative text (deadline: 8-september-2011) are welcome! > |> | > |> | Thanks in advance. > |> | > |> | Best regards. > |> | > |> | JMC. > |> | > |> | 2011/6/28 Jean-Michel Combes: > |> |> Hi Joel, > |> |> > |> |> 2011/6/28 Joel M. Halpern: > |> |>> I don't think this works. > |> |>> The question is not how often ND packets have that structure, but > |> |>> whether > |> |>> 1) Hosts will accept ND packets with that structure and > |> |>> 2) Other protocols will use that structure. > |> |>> > |> |>> If both of those are true, which they currently are, then a SAVI > |> |>> device can not detect an ND packet which is fragmented and hiding > |> |>> behind destination options. > |> |>> But, contrary to your resolution below, since other protocols use > |> |>> that construct, SAVI devices can not simply drop all packets that > |> |>> are fragmented and where the only visible next header is > |> |>> destination options (or AH, or ESP.) they would be dropping > |> |>> legitimate data > |> packets. > |> |> > |> |> Yep, I missed this ... So, a new proposal: > |> |> - if the Next Header value inside the Fragment header is > |> |> ND/UDP(DHCP), the packet is processed by the SAVI device > |> |> - if the Next Header value inside the Fragment header is not > |> |> ND/UDP(DHCP) and there is a binding, the packet is processed by > |> |> the SAVI device > |> |> - else the packet is dropped and the incident is logged > |> |> > |> |>> > |> |>> It does not matter whether any legitimate sender of ND messages > |> |>> would ever use that construct. > |> |>> > |> |>> As far as I can tell, the only path to sanity here is for the > |> |>> hosts not to accept such packets. > |> |>> And that is a matter for 6man, not for SAVI. We should simply > |> |>> document this as a residual threat. > |> |> > |> |> IMHO, this is a matter for SAVI too, because, if the SAVI device > |> |> is not able to process fragmented ND/DHCP packets from a node to > |> |> correctly update the Binding Table, by default, any packet from > |> |> this node will be dropped by the SAVI device even if hosts accept > |> |> such packets. > |> |> > |> |> Cheers. > |> |> > |> |> JMC. > |> |> > |> |>> > |> |>> Yours, > |> |>> Joel > |> |>> > |> |>> > |> |>> On 6/28/2011 1:26 PM, Jean-Michel Combes wrote: > |> |>>> Based on RFC 2460: > |> |>>> (1) the Next Header value inside the Fragment header identifies > |> |>>> the first header of the Fragmentable Part of the original packet > |> |>>> (2) The Unfragmentable Part consists of the IPv6 header plus any > |> |>>> extension headers that must be processed by nodes en route to the > |> |>>> destination, that is, all headers up to and including the Routing > |> |>>> header if present, else the Hop-by-Hop Options header if present, > |> |>>> else no extension headers. > |> |>>> (3) Extension header order is: IPv6 header, Hop-by-Hop Options > |> |>>> header, Destination Options header, Routing header, Fragment > |> |>>> header, Authentication header, Encapsulating Security Payload > |> |>>> header, Destination Options header, upper-layer header > |> |>>> > |> |>>> So, as far as I can see, there are only 3 scenarios where the > |> |>>> Next Header value inside the Fragment header is not ND(including > |> |>>> SEND, as this is just ND options)/DHCP: > |> |>>> (a) AH > |> |>>> (b) ESP > |> |>>> (c) Destination Option > |> |>>> > |> |>>> IMHO, ND/DHCP messages with such extension headers are not > |> | common ... > |> |>>> > |> |>>> > |> |>>>> > > |> |>>>> > Then the SAVI devices can assume and require that the known > | ULP > |> |>>>> > is > |> |>>>> > contained in the first fragment, thus they can determine > | whether > |> |>>>> > a > |> |>>>> > packet is ND/DHCP/SEND, and reject any such packets that > | include > |> |>>>> > a > |> |>>>> > fragment header. > |> |>>> Indeed, we could assume for each SAVI mechanism that: > |> |>>> - if the Next Header value inside the Fragment header is > |> |>>> ND/UDP(DHCP), the packet is processed > |> |>>> - else the packet is dropped and the incident is logged > |> |>>> > |> |>>> As SAVI has a site/link scope, with the logs, IMHO, it should be > |> |>>> easier for the SAVI admin to understand/solve the issue. > |> |>>> > |> |>>> 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 fred@cisco.com Tue Sep 6 10:52:54 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 940E521F8CAA for ; Tue, 6 Sep 2011 10:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.801 X-Spam-Level: X-Spam-Status: No, score=-102.801 tagged_above=-999 required=5 tests=[AWL=-0.202, 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 bKe44ZmzbIlv for ; Tue, 6 Sep 2011 10:52:54 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA4021F8CAF for ; Tue, 6 Sep 2011 10:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=403; q=dns/txt; s=iport; t=1315331681; x=1316541281; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=5M90FB1na/K7gm4ypaoA7YQvpug9E4XYscUt+7zxAHE=; b=F25gnzqo6BM156Z58QGImJFkPmGKGApf5YLbWjp5I2rv9M88TNSojqRz onX26srORsshu0Yn8IeYmtbdgGg80hzMtMWVW22aEAqNuTvlkVTMHX8hS XZnJaWvKQ8cn16oLxnsJc5vYVFoxxZNFbGxkcudBVl1ZYmHvWVBpwMqUR k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANldZk6rRDoG/2dsb2JhbABDp314gUYBAQEBAxIBJz8QCxguVwY1ojsBnyuGCmAEh2uLQ4UPjB4 X-IronPort-AV: E=Sophos;i="4.68,339,1312156800"; d="scan'208";a="471775" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 06 Sep 2011 17:54:41 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p86HsefS027906; Tue, 6 Sep 2011 17:54:40 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Tue, 06 Sep 2011 10:54:41 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Tue, 06 Sep 2011 10:54:41 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4E665A4F.9080608@joelhalpern.com> Date: Tue, 6 Sep 2011 10:54:31 -0700 Message-Id: References: <4E01F2FF.7030108@acm.org> <4E0A11D8.5010300@joelhalpern.com> <000001cc6c8a$a4857c80$ed907580$@it.uc3m.es> <4E662CAF.1010905@joelhalpern.com> <003c01cc6cb7$238670d0$6a935270$@it.uc3m.es> <4E665A4F.9080608@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: 'SAVI Mailing List' , =?iso-8859-1?Q?Alberto_Garc=EDa?= Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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 Sep 2011 17:52:54 -0000 On Sep 6, 2011, at 10:37 AM, Joel M. Halpern wrote: > It seems to me much better to note this vulnerability in SAVI, and = leave it there. > If we want it fixed, 6man should simply instruct hosts not to accept = RAs or DHCPs in fragmented packets. having 6man fix it makes sense to me. I'm not sure how we can fix it in = SAVI without asking the switch to reassemble fragmented messages.=20= From alberto@it.uc3m.es Wed Sep 7 01:28: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 C5BAA21F8C13 for ; Wed, 7 Sep 2011 01:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_29=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 gVw7HP32z2yT for ; Wed, 7 Sep 2011 01:28:49 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id A9CE921F8BCB for ; Wed, 7 Sep 2011 01:28:48 -0700 (PDT) X-uc3m-safe: yes Received: from BOMBO (unknown [163.117.139.71]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id D8C18B4A2DA; Wed, 7 Sep 2011 10:30:35 +0200 (CEST) From: =?iso-8859-1?Q?Alberto_Garc=EDa?= To: "'Joel M. Halpern'" References: <4E01F2FF.7030108@acm.org> <4E0A11D8.5010300@joelhalpern.com> <000001cc6c8a$a4857c80$ed907580$@it.uc3m.es> <4E662CAF.1010905@joelhalpern.com> <003c01cc6cb7$238670d0$6a935270$@it.uc3m.es> <4E665A4F.9080608@joelhalpern.com> In-Reply-To: <4E665A4F.9080608@joelhalpern.com> Date: Wed, 7 Sep 2011 10:31:02 +0200 Message-ID: <005301cc6d38$7a1403f0$6e3c0bd0$@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFTB4vJwakhVfIfNKzvlDJLZuN+EQINlRVdAbHq4KYA5WEYMgGuC5/rAcdsZG8C+kqQyAIxP+zVAPzbFJKVwkmb4A== Content-Language: es X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18370.003 Cc: 'SAVI Mailing List' Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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 Sep 2011 08:28:50 -0000 Hi Joel, | -----Mensaje original----- | De: Joel M. Halpern [mailto:jmh@joelhalpern.com] | Enviado el: martes, 06 de septiembre de 2011 19:37 | Para: Alberto Garc=EDa | CC: 'SAVI Mailing List' | Asunto: Re: [savi] Potential issue for all SAVI mechanisms? | =20 | Your reading and mine of the fragment spec do not match. | Start with an ICMP packet. | Add a number of next headers before the ICMP header. | Now the packet is too long. (Make it MUCH too long.) So it has to be | fragmented. | The next header field in the fragmentation header will point to the header | which is next in the reassembled packet. | =20 | Note that in fragments after the first, the bytes following the = fragment | header are not even the start of a header. They are whatever bytes = come | next in the packet. | =20 | So, if the ICMP does not fit in the first packet, the only way to = find it is to | reassemble the whole packet. | Asking every SAVI device to reassemble every packet which does not = have | TCP or UDP has the next header in the first fragment seems a major | imposition. | But that is what it would take to find the ICMP header. Completely agreed, so far we have the same understanding of the spec. | =20 | It seems to me much better to note this vulnerability in SAVI, and = leave it | there. My misunderstanding is why you call this a 'vulnerability'.=20 [RFC4949]: " $ vulnerability (I) A flaw or weakness in a system's design, implementation, or operation and management that could be exploited to violate the system's security policy. (See: harden.)" How can this be exploited to violate the system's security policy? From = my point of view, the issue we are discussing could prevent a legitimate = user to communicate, and we are discussing which would be the appropriate = SAVI behavior that works well for most cases without requiring too high cost = from SAVI devices. But I don't see how this relate to the security = considerations of the mechanism. Regards, Alberto | If we want it fixed, 6man should simply instruct hosts not to accept = RAs or | DHCPs in fragmented packets. | =20 | Yours, | Joel | =20 | On 9/6/2011 1:05 PM, Alberto Garc=EDa wrote: | > Hi Joel, | > | > | -----Mensaje original----- | > | De: Joel M. Halpern [mailto:jmh@joelhalpern.com] Enviado el: | > | martes, 06 de septiembre de 2011 16:23 | > | Para: Alberto Garc=EDa; SAVI Mailing List | > | Asunto: Re: [savi] Potential issue for all SAVI mechanisms? | > | | > | There seems to be an assumption in the fragment processing text | > | that the next header that points to the ICMP will be in the = first packet. | > | > I think the assumption is that the first header after the | > Fragmentation header is ICMP. | > Every fragment has its fragmentation header, and as I have = understood | > from RFC 2460, on each of these fragments, the Next header of the | > Fragmentation header will very likely contain the value of the = first | > header after the fragmentation one, i.e. ICMP. That is, it is not | > relevant if the fragments are received in order or not, because all | > will probably have the ICMP 'next header' value, being this an | > indication that they have to be reassembled. So being the first = packet | does not seem to be relevant. | > Although I think it is very unlikely to expect so, it may be a = problem | > if the fragments arrive disordered to the SAVI device and the ICMP | > header is not the first, because the first received fragment (but = not | > the first fragment in the fragmentation sequence) would not be | > identified as containing ICMP information. So it is not enough to = have | > the header in the first packet, but to have the ICMP header | > immediately after the Fragmentation header. | > Does this make sense? | > | > Do you think that we should process also packets containing ICMP | > messages which are not immediately after the Fragmentation header? | > If so, I think that every fragmented packet should be reassembled, = and | > then checked, which would be overkill for the SAVI device. | > | > | | > | The reason there is a security threat is that an attacker can | > | carefully compose a packet such that the ICMP header is not in = the | > | first packet, | > and | > | even the next-hezader type pointing to the ICMP is not in the = first | > | fragment. | > | > If I understand properly, the problem you are stating is that the = SAVI | > devices could forward the packet as 'data', with a source address = that | > is valid for the sender at the port at which it is validated, but = the | > message can convey 'false' ND information (I assume that for a | > different [source] address of that used to send the packet) which = may | > influence in the ND caches of the destination nodes, isn=92t it? | > | > If this is the case, I still don't figure out which is the security | > problem, at least for SEND and ND. First, it seems that it does not | > affect to the Source Address Validation function, which is the main | > reason for SAVI, since the packet sent is valid from this point of | > view (the sender should have been able to prove its address = ownership | > before sending this data). SAVI is now not intended to validate = other | > information, such as the validity of the contents of ND = information. | > Besides, for SEND deployments, the destination is going to check = that | > the message received has been signed with the key associated to the | > address for which the message declares something, according to the = SEND | specification. | > However, I have the feeling that there is something I have not | > understood, sorry. | > | > | | > | That needs to be identified. That is what needs to be = identified | > | in the security considerations section. | > | | > | As a separate matter, given the complexity of SEND it may be | > | reasonable for SAVI SEND to require parsing all the headers in = the | > | first fragment, | > where | > | other SAVI cases probably can not do so. That is up to the WG. | > | > The problem with this is that the first fragment may not arrive in = the | > first place (as I said before), and other fragments arriving before | > may not be available for reassembling. | > | > Regards, | > Alberto | > | > | | > | Yours, | > | Joel | > | | > | On 9/6/2011 7:46 AM, Alberto Garc=EDa wrote: | > |> Hi, | > |> Caching up - still within the deadline :-) | > |> | > |> | -----Mensaje original----- | > |> | De: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] En | > |> nombre | de Jean-Michel Combes Enviado el: jueves, 18 de = agosto | > |> de 2011 | 19:51 | Para: SAVI Mailing List | Asunto: Re: = [savi] | > |> Potential issue for all SAVI mechanisms? | > |> | | > |> | Hi, | > |> | | > |> | I would like to come back on this point and find a = consensus. | > |> | Here is the text I propose to be added in the Security | | > |> Considerations | > |> | > |> I agree that the issue must be considered, although I think = that | > |> the corresponding text should not appear in the Security | > |> Considerations, but in the specification of the mechanism. In = my | > |> opinion, it is not a security side effect of the deployment of = a | > |> SAVI mechanism, but part of the functional specification to | > |> address the fragmentation case (and the case in which there are | > |> other headers before). In addition, I don't like very much to = have | > |> 'behaviors' being specified in many different sections. The | > |> security considerations should just consider the case in which | > |> this fragmentation processing is used by a malicious | > | user to perform a DoS attack. | > |> | > |> I have made the exercise of try to adapt this to SEND SAVI, and = I | > |> ended up with the text I include below (based on Jean-Michel | > |> initial text). The main differences with Jean-Michel's text are | > |> - the approach is to address the general case in which IPv6 | > |> extension headers appear: I think we need to state what should = it | > |> be done in this case (for which fragmentation is a particular | > |> case). My opinion is that SAVI devices should jump over the | > |> possible headers looking for ND information (SEND is heavy in | > |> terms of processing, so just adding this processing does not = seem | > |> to be awkward - may other scenarios should be dealt with | > |> differently). However, for the fragmentation particular case, I | > |> adhere to the idea of only processing if the next header to the | > |> fragmentation header is ICMPv6 (because I think the cost of | > |> reassembling is heavier than just inspecting many headers of a | > packet). | > |> - I have tried to clarify which does 'process the packets' (for | > |> the fragmented packet) mean in this context (whether the = fragments | > |> should be forwarded or not, how/when...) | > |> - security considerations deals with DoS attacks exploiting = this | > |> behavior | > |> | > |> What do you think? | > |> | > |> ---- | > |> |> DHCP> | > |> "4.4 Processing messages containing IPv6 extension headers It = may | > |> occur that SEND messages relevant for SEND SAVI operation = contain | > |> IPv6 extension headers located before the SEND information. To | > |> ensure that these messages are processed, the SEND SAVI device | > |> SHOULD inspect any packet containing IPv6 extension headers = until | > |> it could determine whether it includes relevant SEND = information | > |> for SEND SAVI operation | > or | > | not. | > |> | > |> A particular case of this inspection occurs if the SEND message = is | > |> fragmented. In order to process fragmented SEND messages, the = SEND | > |> SAVI device SHOULD proceed as follows: | > |> When a SEND SAVI device receives a fragmented packet, it SHOULD | > |> inspect the Next Header value inside the Fragment header to = check | > |> if it is an ICMPv6 message. If the Fragment header does not = point | > |> to an | > |> ICMPv6 message, then the packet MUST be treated as a data = packet | > |> by | > | the SEND SAVI device. | > |> Fragment packets pointing to ICMPv6 messages SHOULD be | reassembled | > | by | > |> the SEND SAVI device according to [RFC2460]. The fragments MUST | > |> NOT | > | be | > |> forwarded until the packet is reassembled and processed = according | > |> to the SEND SAVI specification (the SEND SAVI specification = will | > |> ultimately determine if the message should be forwarded or not, = and | > |> to which ports). When the SEND SAVI specification indicates = that | > |> the message should be forwarded, the SEND SAVI device MAY = forward | > |> the fragments as received originally, or it MAY forward the | > |> message fragmented in a different way, or it MAY forward the | > |> reassembled | > | message in a single packet. | > |> | > |> Note that fragmented packets in which the fragment header does = not | > |> point to an ICMPv6 message are processed as data packets by the | > |> SEND SAVI device, i.e. they are forwarded if the state = associated | > |> to the source address is VALID, TENTATIVE_DAD, TESTING_VP and | > |> TESTING_VP', | > | and discarded otherwise. | > |> These packets are not further processed by the SEND SAVI device = to | > |> update the SAVI state; this would be the case, for example, for = a | > |> fragmented packet containing a Destination option and then a ND | > |> message. The reason for not reassembling such packets is to = avoid | > |> incurring in the cost for reassembling packets that are unlikely = to | > contain | > | SEND messages." | > |> ---- | > |> [Next paragraph to be added to Security considerations, in the '5.2. | > |> Protection Against Denial of Service Attacks' subsection] The | > |> inclusion of extension headers in any packet, or the = fragmentation | > |> of packets containing SEND messages, can be used to stress the | > |> SAVI device by requiring large amount of resources to inspect | > |> packets and reassemble the fragments. A SEND SAVI device MUST | > |> limit the amount of resources used to store and process these | > |> packets, for example by rate-limiting the processing of packets | > |> containing extension headers (or fragmented packets pointing to | > |> ICMPv6 message), in a per-port basis. | > |> | > |> | > |> Regards, | > |> Alberto | > |> | > |> | > |> | section of any SAVI solution document (i.e., FCFS, DHCP, = SEND | > |> and | MIX | documents) as residential threats: | > |> | | > |> | |> for |DHCP | > |> | SAVI> o SAVI limitations In some cases, the SAVI device = could not | > |> |be able | > |> to | > |> | process IP packets and so to update correctly the Binding = Table. | > |> | For example, this could be the case for encrypted packets | > |> (i.e., | with | > |> IPsec/ESP) | > |> | or fragmented packets. To mitigate this last case, the SAVI | > |> device | SHOULD proceed as | follows: | > |> | - If the Next Header value inside the Fragment header is | | > |> ND/UDP(DHCP), the | packet is processed by the SAVI device, = | | > |> - If the Next Header value inside the Fragment header is not | | > |> ND/UDP(DHCP) but there is a binding, the packet is processed by = the | > |> |SAVI | device, | - Else the packet is dropped and the = incident | > |> is logged. | > |> | | > |> | | > |> | Comments/alternative text (deadline: 8-september-2011) are | welcome! | > |> | | > |> | Thanks in advance. | > |> | | > |> | Best regards. | > |> | | > |> | JMC. | > |> | | > |> | 2011/6/28 Jean-Michel Combes: | > |> |> Hi Joel, | > |> |> | > |> |> 2011/6/28 Joel M. Halpern: | > |> |>> I don't think this works. | > |> |>> The question is not how often ND packets have that = structure, | but | > |> |>> whether | > |> |>> 1) Hosts will accept ND packets with that structure and | > |> |>> 2) Other protocols will use that structure. | > |> |>> | > |> |>> If both of those are true, which they currently are, then = a SAVI | > |> |>> device can not detect an ND packet which is fragmented and | > |> hiding |>> behind destination options. | > |> |>> But, contrary to your resolution below, since other = protocols use | > |> |>> that construct, SAVI devices can not simply drop all = packets | > |> that |>> are fragmented and where the only visible next = header | > |> is |>> destination options (or AH, or ESP.) they would be | > |> dropping |>> legitimate data packets. | > |> |> | > |> |> Yep, I missed this ... So, a new proposal: | > |> |> - if the Next Header value inside the Fragment header is | > |> |> ND/UDP(DHCP), the packet is processed by the SAVI device | > |> |> - if the Next Header value inside the Fragment header is = not | > |> |> ND/UDP(DHCP) and there is a binding, the packet is = processed by | > |> |> the SAVI device | > |> |> - else the packet is dropped and the incident is logged | > |> |> | > |> |>> | > |> |>> It does not matter whether any legitimate sender of ND messages | > |> |>> would ever use that construct. | > |> |>> | > |> |>> As far as I can tell, the only path to sanity here is for = the | > |> |>> hosts not to accept such packets. | > |> |>> And that is a matter for 6man, not for SAVI. We should simply | > |> |>> document this as a residual threat. | > |> |> | > |> |> IMHO, this is a matter for SAVI too, because, if the SAVI device | > |> |> is not able to process fragmented ND/DHCP packets from a = node | > |> to |> correctly update the Binding Table, by default, any = packet | > |> from |> this node will be dropped by the SAVI device even if | > |> hosts accept |> such packets. | > |> |> | > |> |> Cheers. | > |> |> | > |> |> JMC. | > |> |> | > |> |>> | > |> |>> Yours, | > |> |>> Joel | > |> |>> | > |> |>> | > |> |>> On 6/28/2011 1:26 PM, Jean-Michel Combes wrote: | > |> |>>> Based on RFC 2460: | > |> |>>> (1) the Next Header value inside the Fragment header identifies | > |> |>>> the first header of the Fragmentable Part of the = original packet | > |> |>>> (2) The Unfragmentable Part consists of the IPv6 header = plus | any | > |> |>>> extension headers that must be processed by nodes en = route | > |> to the |>>> destination, that is, all headers up to and = including | > |> the Routing |>>> header if present, else the Hop-by-Hop = Options | > |> header if present, |>>> else no extension headers. | > |> |>>> (3) Extension header order is: IPv6 header, Hop-by-Hop Options | > |> |>>> header, Destination Options header, Routing header, = Fragment | > |> |>>> header, Authentication header, Encapsulating Security | > |> Payload |>>> header, Destination Options header, upper-layer | > |> header |>>> | > |> |>>> So, as far as I can see, there are only 3 scenarios = where the | > |> |>>> Next Header value inside the Fragment header is not | > |> ND(including |>>> SEND, as this is just ND options)/DHCP: | > |> |>>> (a) AH | > |> |>>> (b) ESP | > |> |>>> (c) Destination Option | > |> |>>> | > |> |>>> IMHO, ND/DHCP messages with such extension headers are = not | > |> | common ... | > |> |>>> | > |> |>>> | > |> |>>>> > | > |> |>>>> > Then the SAVI devices can assume and require that = the | known | > | ULP | > |> |>>>> > is | > |> |>>>> > contained in the first fragment, thus they can determine | > | whether | > |> |>>>> > a | > |> |>>>> > packet is ND/DHCP/SEND, and reject any such = packets that | > | include | > |> |>>>> > a | > |> |>>>> > fragment header. | > |> |>>> Indeed, we could assume for each SAVI mechanism that: | > |> |>>> - if the Next Header value inside the Fragment header is | > |> |>>> ND/UDP(DHCP), the packet is processed | > |> |>>> - else the packet is dropped and the incident is logged | > |> |>>> | > |> |>>> As SAVI has a site/link scope, with the logs, IMHO, it should be | > |> |>>> easier for the SAVI admin to understand/solve the issue. | > |> |>>> | > |> |>>> 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 jmh@joelhalpern.com Wed Sep 7 07:02:54 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 573DC21F8BA4 for ; Wed, 7 Sep 2011 07:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.78 X-Spam-Level: X-Spam-Status: No, score=-101.78 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_29=0.6, MIME_8BIT_HEADER=0.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 c-loI08d2ym4 for ; Wed, 7 Sep 2011 07:02:49 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:16]) by ietfa.amsl.com (Postfix) with ESMTP id DE4EA21F886A for ; Wed, 7 Sep 2011 07:02:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E4CC44300F7; Wed, 7 Sep 2011 07:04:37 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.104] (pool-71-161-52-74.clppva.btas.verizon.net [71.161.52.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 0952F4300A4; Wed, 7 Sep 2011 07:04:35 -0700 (PDT) Message-ID: <4E6779D6.3090905@joelhalpern.com> Date: Wed, 07 Sep 2011 10:04:06 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: =?windows-1252?Q?Alberto_Garc=EDa?= References: <4E01F2FF.7030108@acm.org> <4E0A11D8.5010300@joelhalpern.com> <000001cc6c8a$a4857c80$ed907580$@it.uc3m.es> <4E662CAF.1010905@joelhalpern.com> <003c01cc6cb7$238670d0$6a935270$@it.uc3m.es> <4E665A4F.9080608@joelhalpern.com> <005301cc6d38$7a1403f0$6e3c0bd0$@it.uc3m.es> In-Reply-To: <005301cc6d38$7a1403f0$6e3c0bd0$@it.uc3m.es> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 'SAVI Mailing List' Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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 Sep 2011 14:02:54 -0000 The vulnerability was reported in several drafts discussed in v6ops and 6man. Specifically, we describe that there are trusted ports and untrusted ports, and RAs are blocked from untrusted ports (and similar filtering is applied to DHCPv6 responses.) However, using this mechanism, if a host is willing to reasssemalbe a packet and accept RAs that were fragmented and have extra headers, then an attacker on any port can Pprepare a false RA or RHCPv6 response. Add as many extension heaqders as desired Fragment the packet at any position he desires such that the ICMP or DHCP header is not in the first fragment Send the result It will get past the filtering. This is a vulnerability in the system as we describe it. As a secondary vulnerability, hosts can source NS/NA messages the wame way, and their contents will not be checked by the SAVI devices. This can mislead other nodes as to where the bound addresses actually reside, and whether they are in use. Yours, Joel M. Halpern On 9/7/2011 4:31 AM, Alberto García wrote: > Hi Joel, > > | -----Mensaje original----- > | De: Joel M. Halpern [mailto:jmh@joelhalpern.com] > | Enviado el: martes, 06 de septiembre de 2011 19:37 > | Para: Alberto García > | CC: 'SAVI Mailing List' > | Asunto: Re: [savi] Potential issue for all SAVI mechanisms? > | > | Your reading and mine of the fragment spec do not match. > | Start with an ICMP packet. > | Add a number of next headers before the ICMP header. > | Now the packet is too long. (Make it MUCH too long.) So it has to be > | fragmented. > | The next header field in the fragmentation header will point to the > header > | which is next in the reassembled packet. > | > | Note that in fragments after the first, the bytes following the fragment > | header are not even the start of a header. They are whatever bytes come > | next in the packet. > | > | So, if the ICMP does not fit in the first packet, the only way to find it > is to > | reassemble the whole packet. > | Asking every SAVI device to reassemble every packet which does not have > | TCP or UDP has the next header in the first fragment seems a major > | imposition. > | But that is what it would take to find the ICMP header. > > Completely agreed, so far we have the same understanding of the spec. > > | > | It seems to me much better to note this vulnerability in SAVI, and leave > it > | there. > > My misunderstanding is why you call this a 'vulnerability'. > [RFC4949]: " $ vulnerability > (I) A flaw or weakness in a system's design, implementation, or > operation and management that could be exploited to violate the > system's security policy. (See: harden.)" > > How can this be exploited to violate the system's security policy? From my > point of view, the issue we are discussing could prevent a legitimate user > to communicate, and we are discussing which would be the appropriate SAVI > behavior that works well for most cases without requiring too high cost from > SAVI devices. But I don't see how this relate to the security considerations > of the mechanism. > > Regards, > Alberto > > | If we want it fixed, 6man should simply instruct hosts not to accept RAs > or > | DHCPs in fragmented packets. > | > | Yours, > | Joel > | > | On 9/6/2011 1:05 PM, Alberto García wrote: > |> Hi Joel, > |> > |> | -----Mensaje original----- > |> | De: Joel M. Halpern [mailto:jmh@joelhalpern.com] Enviado el: > |> | martes, 06 de septiembre de 2011 16:23 > |> | Para: Alberto García; SAVI Mailing List > |> | Asunto: Re: [savi] Potential issue for all SAVI mechanisms? > |> | > |> | There seems to be an assumption in the fragment processing text > |> | that the next header that points to the ICMP will be in the first > packet. > |> > |> I think the assumption is that the first header after the > |> Fragmentation header is ICMP. > |> Every fragment has its fragmentation header, and as I have understood > |> from RFC 2460, on each of these fragments, the Next header of the > |> Fragmentation header will very likely contain the value of the first > |> header after the fragmentation one, i.e. ICMP. That is, it is not > |> relevant if the fragments are received in order or not, because all > |> will probably have the ICMP 'next header' value, being this an > |> indication that they have to be reassembled. So being the first packet > | does not seem to be relevant. > |> Although I think it is very unlikely to expect so, it may be a problem > |> if the fragments arrive disordered to the SAVI device and the ICMP > |> header is not the first, because the first received fragment (but not > |> the first fragment in the fragmentation sequence) would not be > |> identified as containing ICMP information. So it is not enough to have > |> the header in the first packet, but to have the ICMP header > |> immediately after the Fragmentation header. > |> Does this make sense? > |> > |> Do you think that we should process also packets containing ICMP > |> messages which are not immediately after the Fragmentation header? > |> If so, I think that every fragmented packet should be reassembled, and > |> then checked, which would be overkill for the SAVI device. > |> > |> | > |> | The reason there is a security threat is that an attacker can > |> | carefully compose a packet such that the ICMP header is not in the > |> | first packet, > |> and > |> | even the next-hezader type pointing to the ICMP is not in the first > |> | fragment. > |> > |> If I understand properly, the problem you are stating is that the SAVI > |> devices could forward the packet as 'data', with a source address that > |> is valid for the sender at the port at which it is validated, but the > |> message can convey 'false' ND information (I assume that for a > |> different [source] address of that used to send the packet) which may > |> influence in the ND caches of the destination nodes, isn’t it? > |> > |> If this is the case, I still don't figure out which is the security > |> problem, at least for SEND and ND. First, it seems that it does not > |> affect to the Source Address Validation function, which is the main > |> reason for SAVI, since the packet sent is valid from this point of > |> view (the sender should have been able to prove its address ownership > |> before sending this data). SAVI is now not intended to validate other > |> information, such as the validity of the contents of ND information. > |> Besides, for SEND deployments, the destination is going to check that > |> the message received has been signed with the key associated to the > |> address for which the message declares something, according to the SEND > | specification. > |> However, I have the feeling that there is something I have not > |> understood, sorry. > |> > |> | > |> | That needs to be identified. That is what needs to be identified > |> | in the security considerations section. > |> | > |> | As a separate matter, given the complexity of SEND it may be > |> | reasonable for SAVI SEND to require parsing all the headers in the > |> | first fragment, > |> where > |> | other SAVI cases probably can not do so. That is up to the WG. > |> > |> The problem with this is that the first fragment may not arrive in the > |> first place (as I said before), and other fragments arriving before > |> may not be available for reassembling. > |> > |> Regards, > |> Alberto > |> > |> | > |> | Yours, > |> | Joel > |> | > |> | On 9/6/2011 7:46 AM, Alberto García wrote: > |> |> Hi, > |> |> Caching up - still within the deadline :-) > |> |> > |> |> | -----Mensaje original----- > |> |> | De: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] En > |> |> nombre | de Jean-Michel Combes Enviado el: jueves, 18 de agosto > |> |> de 2011 | 19:51 | Para: SAVI Mailing List | Asunto: Re: [savi] > |> |> Potential issue for all SAVI mechanisms? > |> |> | > |> |> | Hi, > |> |> | > |> |> | I would like to come back on this point and find a consensus. > |> |> | Here is the text I propose to be added in the Security | > |> |> Considerations > |> |> > |> |> I agree that the issue must be considered, although I think that > |> |> the corresponding text should not appear in the Security > |> |> Considerations, but in the specification of the mechanism. In my > |> |> opinion, it is not a security side effect of the deployment of a > |> |> SAVI mechanism, but part of the functional specification to > |> |> address the fragmentation case (and the case in which there are > |> |> other headers before). In addition, I don't like very much to have > |> |> 'behaviors' being specified in many different sections. The > |> |> security considerations should just consider the case in which > |> |> this fragmentation processing is used by a malicious > |> | user to perform a DoS attack. > |> |> > |> |> I have made the exercise of try to adapt this to SEND SAVI, and I > |> |> ended up with the text I include below (based on Jean-Michel > |> |> initial text). The main differences with Jean-Michel's text are > |> |> - the approach is to address the general case in which IPv6 > |> |> extension headers appear: I think we need to state what should it > |> |> be done in this case (for which fragmentation is a particular > |> |> case). My opinion is that SAVI devices should jump over the > |> |> possible headers looking for ND information (SEND is heavy in > |> |> terms of processing, so just adding this processing does not seem > |> |> to be awkward - may other scenarios should be dealt with > |> |> differently). However, for the fragmentation particular case, I > |> |> adhere to the idea of only processing if the next header to the > |> |> fragmentation header is ICMPv6 (because I think the cost of > |> |> reassembling is heavier than just inspecting many headers of a > |> packet). > |> |> - I have tried to clarify which does 'process the packets' (for > |> |> the fragmented packet) mean in this context (whether the fragments > |> |> should be forwarded or not, how/when...) > |> |> - security considerations deals with DoS attacks exploiting this > |> |> behavior > |> |> > |> |> What do you think? > |> |> > |> |> ---- > |> |> |> |> DHCP> > |> |> "4.4 Processing messages containing IPv6 extension headers It may > |> |> occur that SEND messages relevant for SEND SAVI operation contain > |> |> IPv6 extension headers located before the SEND information. To > |> |> ensure that these messages are processed, the SEND SAVI device > |> |> SHOULD inspect any packet containing IPv6 extension headers until > |> |> it could determine whether it includes relevant SEND information > |> |> for SEND SAVI operation > |> or > |> | not. > |> |> > |> |> A particular case of this inspection occurs if the SEND message is > |> |> fragmented. In order to process fragmented SEND messages, the SEND > |> |> SAVI device SHOULD proceed as follows: > |> |> When a SEND SAVI device receives a fragmented packet, it SHOULD > |> |> inspect the Next Header value inside the Fragment header to check > |> |> if it is an ICMPv6 message. If the Fragment header does not point > |> |> to an > |> |> ICMPv6 message, then the packet MUST be treated as a data packet > |> |> by > |> | the SEND SAVI device. > |> |> Fragment packets pointing to ICMPv6 messages SHOULD be > | reassembled > |> | by > |> |> the SEND SAVI device according to [RFC2460]. The fragments MUST > |> |> NOT > |> | be > |> |> forwarded until the packet is reassembled and processed according > |> |> to the SEND SAVI specification (the SEND SAVI specification will > |> |> ultimately determine if the message should be forwarded or not, and > |> |> to which ports). When the SEND SAVI specification indicates that > |> |> the message should be forwarded, the SEND SAVI device MAY forward > |> |> the fragments as received originally, or it MAY forward the > |> |> message fragmented in a different way, or it MAY forward the > |> |> reassembled > |> | message in a single packet. > |> |> > |> |> Note that fragmented packets in which the fragment header does not > |> |> point to an ICMPv6 message are processed as data packets by the > |> |> SEND SAVI device, i.e. they are forwarded if the state associated > |> |> to the source address is VALID, TENTATIVE_DAD, TESTING_VP and > |> |> TESTING_VP', > |> | and discarded otherwise. > |> |> These packets are not further processed by the SEND SAVI device to > |> |> update the SAVI state; this would be the case, for example, for a > |> |> fragmented packet containing a Destination option and then a ND > |> |> message. The reason for not reassembling such packets is to avoid > |> |> incurring in the cost for reassembling packets that are unlikely to > |> contain > |> | SEND messages." > |> |> ---- > |> |> [Next paragraph to be added to Security considerations, in the > '5.2. > |> |> Protection Against Denial of Service Attacks' subsection] The > |> |> inclusion of extension headers in any packet, or the fragmentation > |> |> of packets containing SEND messages, can be used to stress the > |> |> SAVI device by requiring large amount of resources to inspect > |> |> packets and reassemble the fragments. A SEND SAVI device MUST > |> |> limit the amount of resources used to store and process these > |> |> packets, for example by rate-limiting the processing of packets > |> |> containing extension headers (or fragmented packets pointing to > |> |> ICMPv6 message), in a per-port basis. > |> |> > |> |> > |> |> Regards, > |> |> Alberto > |> |> > |> |> > |> |> | section of any SAVI solution document (i.e., FCFS, DHCP, SEND > |> |> and | MIX | documents) as residential threats: > |> |> | > |> |> | |> |> for |DHCP > |> |> | SAVI> o SAVI limitations In some cases, the SAVI device could > not > |> |> |be able > |> |> to > |> |> | process IP packets and so to update correctly the Binding Table. > |> |> | For example, this could be the case for encrypted packets > |> |> (i.e., | with > |> |> IPsec/ESP) > |> |> | or fragmented packets. To mitigate this last case, the SAVI > |> |> device | SHOULD proceed as | follows: > |> |> | - If the Next Header value inside the Fragment header is | > |> |> ND/UDP(DHCP), the | packet is processed by the SAVI device, | > |> |> - If the Next Header value inside the Fragment header is not | > |> |> ND/UDP(DHCP) but there is a binding, the packet is processed by the > |> |> |SAVI | device, | - Else the packet is dropped and the incident > |> |> is logged. > |> |> | > |> |> | > |> |> | Comments/alternative text (deadline: 8-september-2011) are > | welcome! > |> |> | > |> |> | Thanks in advance. > |> |> | > |> |> | Best regards. > |> |> | > |> |> | JMC. > |> |> | > |> |> | 2011/6/28 Jean-Michel Combes: > |> |> |> Hi Joel, > |> |> |> > |> |> |> 2011/6/28 Joel M. Halpern: > |> |> |>> I don't think this works. > |> |> |>> The question is not how often ND packets have that structure, > | but > |> |> |>> whether > |> |> |>> 1) Hosts will accept ND packets with that structure and > |> |> |>> 2) Other protocols will use that structure. > |> |> |>> > |> |> |>> If both of those are true, which they currently are, then a > SAVI > |> |> |>> device can not detect an ND packet which is fragmented and > |> |> hiding |>> behind destination options. > |> |> |>> But, contrary to your resolution below, since other protocols > use > |> |> |>> that construct, SAVI devices can not simply drop all packets > |> |> that |>> are fragmented and where the only visible next header > |> |> is |>> destination options (or AH, or ESP.) they would be > |> |> dropping |>> legitimate data packets. > |> |> |> > |> |> |> Yep, I missed this ... So, a new proposal: > |> |> |> - if the Next Header value inside the Fragment header is > |> |> |> ND/UDP(DHCP), the packet is processed by the SAVI device > |> |> |> - if the Next Header value inside the Fragment header is not > |> |> |> ND/UDP(DHCP) and there is a binding, the packet is processed > by > |> |> |> the SAVI device > |> |> |> - else the packet is dropped and the incident is logged > |> |> |> > |> |> |>> > |> |> |>> It does not matter whether any legitimate sender of ND > messages > |> |> |>> would ever use that construct. > |> |> |>> > |> |> |>> As far as I can tell, the only path to sanity here is for the > |> |> |>> hosts not to accept such packets. > |> |> |>> And that is a matter for 6man, not for SAVI. We should > simply > |> |> |>> document this as a residual threat. > |> |> |> > |> |> |> IMHO, this is a matter for SAVI too, because, if the SAVI > device > |> |> |> is not able to process fragmented ND/DHCP packets from a node > |> |> to |> correctly update the Binding Table, by default, any packet > |> |> from |> this node will be dropped by the SAVI device even if > |> |> hosts accept |> such packets. > |> |> |> > |> |> |> Cheers. > |> |> |> > |> |> |> JMC. > |> |> |> > |> |> |>> > |> |> |>> Yours, > |> |> |>> Joel > |> |> |>> > |> |> |>> > |> |> |>> On 6/28/2011 1:26 PM, Jean-Michel Combes wrote: > |> |> |>>> Based on RFC 2460: > |> |> |>>> (1) the Next Header value inside the Fragment header > identifies > |> |> |>>> the first header of the Fragmentable Part of the original > packet > |> |> |>>> (2) The Unfragmentable Part consists of the IPv6 header plus > | any > |> |> |>>> extension headers that must be processed by nodes en route > |> |> to the |>>> destination, that is, all headers up to and including > |> |> the Routing |>>> header if present, else the Hop-by-Hop Options > |> |> header if present, |>>> else no extension headers. > |> |> |>>> (3) Extension header order is: IPv6 header, Hop-by-Hop > Options > |> |> |>>> header, Destination Options header, Routing header, Fragment > |> |> |>>> header, Authentication header, Encapsulating Security > |> |> Payload |>>> header, Destination Options header, upper-layer > |> |> header |>>> > |> |> |>>> So, as far as I can see, there are only 3 scenarios where > the > |> |> |>>> Next Header value inside the Fragment header is not > |> |> ND(including |>>> SEND, as this is just ND options)/DHCP: > |> |> |>>> (a) AH > |> |> |>>> (b) ESP > |> |> |>>> (c) Destination Option > |> |> |>>> > |> |> |>>> IMHO, ND/DHCP messages with such extension headers are not > |> |> | common ... > |> |> |>>> > |> |> |>>> > |> |> |>>>> > > |> |> |>>>> > Then the SAVI devices can assume and require that the > | known > |> | ULP > |> |> |>>>> > is > |> |> |>>>> > contained in the first fragment, thus they can > determine > |> | whether > |> |> |>>>> > a > |> |> |>>>> > packet is ND/DHCP/SEND, and reject any such packets > that > |> | include > |> |> |>>>> > a > |> |> |>>>> > fragment header. > |> |> |>>> Indeed, we could assume for each SAVI mechanism that: > |> |> |>>> - if the Next Header value inside the Fragment header is > |> |> |>>> ND/UDP(DHCP), the packet is processed > |> |> |>>> - else the packet is dropped and the incident is logged > |> |> |>>> > |> |> |>>> As SAVI has a site/link scope, with the logs, IMHO, it > should be > |> |> |>>> easier for the SAVI admin to understand/solve the issue. > |> |> |>>> > |> |> |>>> 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 jeanmichel.combes@gmail.com Fri Sep 9 08:03:39 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 6106021F8B9F for ; Fri, 9 Sep 2011 08:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.01 X-Spam-Level: X-Spam-Status: No, score=-103.01 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, 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 IIFzJOdPyVfb for ; Fri, 9 Sep 2011 08:03:38 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id BB49121F8BAE for ; Fri, 9 Sep 2011 08:03:37 -0700 (PDT) Received: by gyd12 with SMTP id 12so1860621gyd.31 for ; Fri, 09 Sep 2011 08:05:30 -0700 (PDT) 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=aLF/cwLUmDPhlV1pxYolkJUhJAl/gFYFj5iSnPAY5Jg=; b=qFWZeCCb8O2A3T86pEPbrd5jWzdG9a3rKTgcg3RAgdQfBOO7wP6ARzSjx/ognjCO3a fdQRckr/RmWwbfTYVLobmfh2EJxqc0on9WfdWdr85NR7E6AYXJ1jnNHZcMOh2CpWgez4 ySHMHoYcCUAC/rxowfJV5W7dTAXmyFNNXFfQQ= MIME-Version: 1.0 Received: by 10.236.72.169 with SMTP id t29mr12646064yhd.110.1315580730545; Fri, 09 Sep 2011 08:05:30 -0700 (PDT) Received: by 10.146.82.14 with HTTP; Fri, 9 Sep 2011 08:05:30 -0700 (PDT) In-Reply-To: <4E665A4F.9080608@joelhalpern.com> References: <4E01F2FF.7030108@acm.org> <4E0A11D8.5010300@joelhalpern.com> <000001cc6c8a$a4857c80$ed907580$@it.uc3m.es> <4E662CAF.1010905@joelhalpern.com> <003c01cc6cb7$238670d0$6a935270$@it.uc3m.es> <4E665A4F.9080608@joelhalpern.com> Date: Fri, 9 Sep 2011 17:05:30 +0200 Message-ID: From: Jean-Michel Combes To: "Joel M. Halpern" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: SAVI Mailing List , =?ISO-8859-1?Q?Alberto_Garc=EDa?= Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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, 09 Sep 2011 15:03:39 -0000 Hi Joel, 2011/9/6 Joel M. Halpern : [snip] > > It seems to me much better to note this vulnerability in SAVI, and leave = it > there. Just a clarification: from your point of view, we have just to mention the issue without adding a potential solution (e.g., http://www.ietf.org/mail-archive/web/savi/current/msg01675.html) to mitigate it, correct? Thanks. Yours, JMC. > If we want it fixed, 6man should simply instruct hosts not to accept RAs = or > DHCPs in fragmented packets. > > Yours, > Joel > > On 9/6/2011 1:05 PM, Alberto Garc=EDa wrote: >> >> Hi Joel, >> >> | =A0-----Mensaje original----- >> | =A0De: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> | =A0Enviado el: martes, 06 de septiembre de 2011 16:23 >> | =A0Para: Alberto Garc=EDa; SAVI Mailing List >> | =A0Asunto: Re: [savi] Potential issue for all SAVI mechanisms? >> | >> | =A0There seems to be an assumption in the fragment processing text tha= t >> the >> | =A0next header that points to the ICMP will be in the first packet. >> >> I think the assumption is that the first header after the Fragmentation >> header is ICMP. >> Every fragment has its fragmentation header, and as I have understood fr= om >> RFC 2460, on each of these fragments, the Next header of the Fragmentati= on >> header will very likely contain the value of the first header after the >> fragmentation one, i.e. ICMP. That is, it is not relevant if the fragmen= ts >> are received in order or not, because all will probably have the ICMP >> 'next >> header' value, being this an indication that they have to be reassembled= . >> So >> being the first packet does not seem to be relevant. >> Although I think it is very unlikely to expect so, it may be a problem i= f >> the fragments arrive disordered to the SAVI device and the ICMP header i= s >> not the first, because the first received fragment (but not the first >> fragment in the fragmentation sequence) would not be identified as >> containing ICMP information. So it is not enough to have the header in t= he >> first packet, but to have the ICMP header immediately after the >> Fragmentation header. >> Does this make sense? >> >> Do you think that we should process also packets containing ICMP message= s >> which are not immediately after the Fragmentation header? >> If so, I think that every fragmented packet should be reassembled, and >> then >> checked, which would be overkill for the SAVI device. >> >> | >> | =A0The reason there is a security threat is that an attacker can caref= ully >> | =A0compose a packet such that the ICMP header is not in the first pack= et, >> and >> | =A0even the next-hezader type pointing to the ICMP is not in the first >> | =A0fragment. >> >> If I understand properly, the problem you are stating is that the SAVI >> devices could forward the packet as 'data', with a source address that i= s >> valid for the sender at the port at which it is validated, but the messa= ge >> can convey 'false' ND information (I assume that for a different [source= ] >> address of that used to send the packet) which may influence in the ND >> caches of the destination nodes, isn=92t it? >> >> If this is the case, I still don't figure out which is the security >> problem, >> at least for SEND and ND. First, it seems that it does not affect to the >> Source Address Validation function, which is the main reason for SAVI, >> since >> the packet sent is valid from this point of view (the sender should have >> been able to prove its address ownership before sending this data). SAVI >> is >> now not intended to validate other information, such as the validity of >> the >> contents of ND information. Besides, for SEND deployments, the destinati= on >> is going to check that the message received has been signed with the key >> associated to the address for which the message declares something, >> according to the SEND specification. >> However, I have the feeling that there is something I have not understoo= d, >> sorry. >> >> | >> | =A0That needs to be identified. =A0That is what needs to be identified= in >> the >> | =A0security considerations section. >> | >> | =A0As a separate matter, given the complexity of SEND it may be reason= able >> | =A0for SAVI SEND to require parsing all the headers in the first fragm= ent, >> where >> | =A0other SAVI cases probably can not do so. =A0That is up to the WG. >> >> The problem with this is that the first fragment may not arrive in the >> first >> place (as I said before), and other fragments arriving before may not be >> available for reassembling. >> >> Regards, >> Alberto >> >> | >> | =A0Yours, >> | =A0Joel >> | >> | =A0On 9/6/2011 7:46 AM, Alberto Garc=EDa wrote: >> |> =A0Hi, >> |> =A0Caching up =A0- still within the deadline :-) >> |> >> |> =A0| =A0-----Mensaje original----- >> |> =A0| =A0De: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] En n= ombre >> |> =A0| de =A0Jean-Michel Combes =A0Enviado el: jueves, 18 de agosto de = 2011 >> |> =A0| 19:51 >> |> =A0| =A0Para: SAVI Mailing List >> |> =A0| =A0Asunto: Re: [savi] Potential issue for all SAVI mechanisms? >> |> =A0| >> |> =A0| =A0Hi, >> |> =A0| >> |> =A0| =A0I would like to come back on this point and find a consensus. >> |> =A0| =A0Here is the text I propose to be added in the Security >> |> =A0| Considerations >> |> >> |> =A0I agree that the issue must be considered, although I think that t= he >> |> =A0corresponding text should not appear in the Security Consideration= s, >> |> =A0but in the specification of the mechanism. In my opinion, it is no= t a >> |> =A0security side effect of the deployment of a SAVI mechanism, but pa= rt >> |> =A0of the functional specification to address the fragmentation case = (and >> |> =A0the case in which there are other headers before). In addition, I >> |> =A0don't like very much to have 'behaviors' being specified in many >> |> =A0different sections. The security considerations should just consid= er >> |> =A0the case in which this fragmentation processing is used by a malic= ious >> | =A0user to perform a DoS attack. >> |> >> |> =A0I have made the exercise of try to adapt this to SEND SAVI, and I >> |> =A0ended up with the text I include below (based on Jean-Michel initi= al >> |> =A0text). The main differences with Jean-Michel's text are >> |> =A0- the approach is to address the general case in which IPv6 extens= ion >> |> =A0headers appear: I think we need to state what should it be done in >> |> =A0this case (for which fragmentation is a particular case). My opini= on >> |> =A0is that SAVI devices should jump over the possible headers looking= for >> |> =A0ND information (SEND is heavy in terms of processing, so just addi= ng >> |> =A0this processing does not seem to be awkward - may other scenarios >> |> =A0should be dealt with differently). However, for the fragmentation >> |> =A0particular case, I adhere to the idea of only processing if the ne= xt >> |> =A0header to the fragmentation header is ICMPv6 (because I think the = cost >> |> =A0of reassembling is heavier than just inspecting many headers of a >> packet). >> |> =A0- I have tried to clarify which does 'process the packets' (for th= e >> |> =A0fragmented packet) mean in this context (whether the fragments sho= uld >> |> =A0be forwarded or not, how/when...) >> |> =A0- security considerations deals with DoS attacks exploiting this >> |> =A0behavior >> |> >> |> =A0What do you think? >> |> >> |> =A0---- >> |> =A0> |> =A0DHCP> >> |> =A0"4.4 Processing messages containing IPv6 extension headers It may >> |> =A0occur that SEND messages relevant for SEND SAVI operation contain >> |> =A0IPv6 extension headers located before the SEND information. To ens= ure >> |> =A0that these messages are processed, the SEND SAVI device SHOULD ins= pect >> |> =A0any packet containing IPv6 extension headers until it could determ= ine >> |> =A0whether it includes relevant SEND information for SEND SAVI operat= ion >> or >> | =A0not. >> |> >> |> =A0A particular case of this inspection occurs if the SEND message is >> |> =A0fragmented. In order to process fragmented SEND messages, the SEND >> |> =A0SAVI device SHOULD proceed as follows: >> |> =A0When a SEND SAVI device receives a fragmented packet, it SHOULD >> |> =A0inspect the Next Header value inside the Fragment header to check = if >> |> =A0it is an ICMPv6 message. If the Fragment header does not point to = an >> |> =A0ICMPv6 message, then the packet MUST be treated as a data packet b= y >> | =A0the SEND SAVI device. >> |> =A0Fragment packets pointing to ICMPv6 messages SHOULD be reassembled >> | =A0by >> |> =A0the SEND SAVI device according to [RFC2460]. The fragments MUST NO= T >> | =A0be >> |> =A0forwarded until the packet is reassembled and processed according = to >> |> =A0the SEND SAVI specification (the SEND SAVI specification will >> |> =A0ultimately determine if the message should be forwarded or not, an= d to >> |> =A0which ports). When the SEND SAVI specification indicates that the >> |> =A0message should be forwarded, the SEND SAVI device MAY forward the >> |> =A0fragments as received originally, or it MAY forward the message >> |> =A0fragmented in a different way, or it MAY forward the reassembled >> | =A0message in a single packet. >> |> >> |> =A0Note that fragmented packets in which the fragment header does not >> |> =A0point to an ICMPv6 message are processed as data packets by the SE= ND >> |> =A0SAVI device, i.e. they are forwarded if the state associated to th= e >> |> =A0source address is VALID, =A0TENTATIVE_DAD, TESTING_VP and TESTING_= VP', >> | =A0and discarded otherwise. >> |> =A0These packets are not further processed by the SEND SAVI device to >> |> =A0update the SAVI state; this would be the case, for example, for a >> |> =A0fragmented packet containing a Destination option and then a ND >> |> =A0message. The reason for not reassembling such packets is to avoid >> |> =A0incurring in the cost for reassembling packets that are unlikely t= o >> contain >> | =A0SEND messages." >> |> =A0---- >> |> =A0[Next paragraph to be added to Security considerations, in the '5.= 2. >> |> =A0Protection Against Denial of Service Attacks' subsection] The >> |> =A0inclusion of extension headers in any packet, or the fragmentation= of >> |> =A0packets containing SEND messages, can be used to stress the SAVI >> |> =A0device by requiring large amount of resources to inspect packets a= nd >> |> =A0reassemble the fragments. A SEND SAVI device MUST limit the amount= of >> |> =A0resources used to store and process these packets, for example by >> |> =A0rate-limiting the processing of packets containing extension heade= rs >> |> =A0(or fragmented packets pointing to >> |> =A0ICMPv6 message), in a per-port basis. >> |> =A0 >> |> >> |> =A0Regards, >> |> =A0Alberto >> |> >> |> >> |> =A0| =A0section of any SAVI solution document (i.e., FCFS, DHCP, SEND= and >> |> =A0| MIX >> |> =A0| =A0documents) as residential threats: >> |> =A0| >> |> =A0|> |> =A0|DHCP >> |> =A0| =A0SAVI> =A0 o SAVI limitations In some cases, the SAVI device c= ould not >> |> =A0|be able >> |> =A0to >> |> =A0| =A0process IP packets and so to update correctly the Binding Tab= le. >> |> =A0| For =A0example, this could be the case for encrypted packets (i.= e., >> |> =A0| with >> |> =A0IPsec/ESP) >> |> =A0| =A0or fragmented packets. To mitigate this last case, the SAVI d= evice >> |> =A0| SHOULD =A0proceed as >> |> =A0| =A0follows: >> |> =A0| =A0- If the Next Header value inside the Fragment header is >> |> =A0| ND/UDP(DHCP), >> |> =A0the >> |> =A0| =A0packet is processed by the SAVI device, >> |> =A0| =A0- If the Next Header value inside the Fragment header is not >> |> =A0| =A0ND/UDP(DHCP) but there is a binding, the packet is processed = by the >> |> =A0|SAVI >> |> =A0| =A0device, >> |> =A0| =A0- Else the packet is dropped and the incident is logged. >> |> =A0| >> |> =A0| >> |> =A0| =A0Comments/alternative text (deadline: 8-september-2011) are we= lcome! >> |> =A0| >> |> =A0| =A0Thanks in advance. >> |> =A0| >> |> =A0| =A0Best regards. >> |> =A0| >> |> =A0| =A0JMC. >> |> =A0| >> |> =A0| =A02011/6/28 Jean-Michel Combes: >> |> =A0|> =A0 Hi Joel, >> |> =A0|> >> |> =A0|> =A0 2011/6/28 Joel M. Halpern: >> |> =A0|>> =A0 I don't think this works. >> |> =A0|>> =A0 The question is not how often ND packets have that structu= re, >> but >> |> =A0|>> =A0whether >> |> =A0|>> =A0 1) Hosts will accept ND packets with that structure and >> |> =A0|>> =A0 2) Other protocols will use that structure. >> |> =A0|>> >> |> =A0|>> =A0 If both of those are true, which they currently are, then = a SAVI >> |> =A0|>> =A0device can not detect an ND packet which is fragmented and = hiding >> |> =A0|>> =A0behind destination options. >> |> =A0|>> =A0 But, contrary to your resolution below, since other protoc= ols >> use >> |> =A0|>> =A0that construct, SAVI devices can not simply drop all packet= s that >> |> =A0|>> =A0are =A0fragmented and where the only visible next header is >> |> =A0|>> =A0destination =A0options (or AH, or ESP.) =A0they would be dr= opping >> |> =A0|>> =A0legitimate data >> |> =A0packets. >> |> =A0|> >> |> =A0|> =A0 Yep, I missed this ... So, a new proposal: >> |> =A0|> =A0 - if the Next Header value inside the Fragment header is >> |> =A0|> =A0ND/UDP(DHCP), =A0the packet is processed by the SAVI device >> |> =A0|> =A0 - if the Next Header value inside the Fragment header is no= t >> |> =A0|> =A0 ND/UDP(DHCP) and there is a binding, the packet is processe= d by >> |> =A0|> =A0the =A0SAVI device >> |> =A0|> =A0 - else the packet is dropped and the incident is logged >> |> =A0|> >> |> =A0|>> >> |> =A0|>> =A0 It does not matter whether any legitimate sender of ND mes= sages >> |> =A0|>> =A0would =A0ever use that construct. >> |> =A0|>> >> |> =A0|>> =A0 As far as I can tell, the only path to sanity here is for = the >> |> =A0|>> =A0hosts =A0not to accept such packets. >> |> =A0|>> =A0 And that is a matter for 6man, not for SAVI. =A0We should = simply >> |> =A0|>> =A0document this as a residual threat. >> |> =A0|> >> |> =A0|> =A0 IMHO, this is a matter for SAVI too, because, if the SAVI d= evice >> |> =A0|> =A0is =A0not able to process fragmented ND/DHCP packets from a = node to >> |> =A0|> =A0correctly update the Binding Table, by default, any packet f= rom >> |> =A0|> =A0this =A0node will be dropped by the SAVI device even if host= s accept >> |> =A0|> =A0such =A0packets. >> |> =A0|> >> |> =A0|> =A0 Cheers. >> |> =A0|> >> |> =A0|> =A0 JMC. >> |> =A0|> >> |> =A0|>> >> |> =A0|>> =A0 Yours, >> |> =A0|>> =A0 Joel >> |> =A0|>> >> |> =A0|>> >> |> =A0|>> =A0 On 6/28/2011 1:26 PM, Jean-Michel Combes wrote: >> |> =A0|>>> =A0 Based on RFC 2460: >> |> =A0|>>> =A0 (1) the Next Header value inside the Fragment header iden= tifies >> |> =A0|>>> =A0the =A0first header of the Fragmentable Part of the origin= al >> packet >> |> =A0|>>> =A0 (2) The Unfragmentable Part consists of the IPv6 header p= lus >> any >> |> =A0|>>> =A0extension headers that must be processed by nodes en route= to >> the >> |> =A0|>>> =A0destination, that is, all headers up to and including the >> Routing >> |> =A0|>>> =A0header if present, else the Hop-by-Hop Options header if >> present, >> |> =A0|>>> =A0else no extension headers. >> |> =A0|>>> =A0 (3) Extension header order is: IPv6 header, Hop-by-Hop Op= tions >> |> =A0|>>> =A0header, Destination Options header, Routing header, Fragme= nt >> |> =A0|>>> =A0header, =A0Authentication header, Encapsulating Security P= ayload >> |> =A0|>>> =A0header, =A0Destination Options header, upper-layer header >> |> =A0|>>> >> |> =A0|>>> =A0 So, as far as I can see, there are only 3 scenarios where= the >> |> =A0|>>> =A0Next =A0Header value inside the Fragment header is not >> ND(including >> |> =A0|>>> =A0SEND, as =A0this is just ND options)/DHCP: >> |> =A0|>>> =A0 (a) AH >> |> =A0|>>> =A0 (b) ESP >> |> =A0|>>> =A0 (c) Destination Option >> |> =A0|>>> >> |> =A0|>>> =A0 IMHO, ND/DHCP messages with such extension headers are no= t >> |> =A0| =A0common ... >> |> =A0|>>> >> |> =A0|>>> >> |> =A0|>>>> =A0 > >> |> =A0|>>>> =A0 > =A0 =A0 Then the SAVI devices can assume and require t= hat the >> known >> | =A0ULP >> |> =A0|>>>> =A0 > =A0 is >> |> =A0|>>>> =A0 > =A0 =A0 contained in the first fragment, thus they can= determine >> | =A0whether >> |> =A0|>>>> =A0 > =A0 a >> |> =A0|>>>> =A0 > =A0 =A0 packet is ND/DHCP/SEND, and reject any such pa= ckets that >> | =A0include >> |> =A0|>>>> =A0 > =A0 a >> |> =A0|>>>> =A0 > =A0 =A0 fragment header. >> |> =A0|>>> =A0 Indeed, we could assume for each SAVI mechanism that: >> |> =A0|>>> =A0 - if the Next Header value inside the Fragment header is >> |> =A0|>>> =A0ND/UDP(DHCP), the packet is processed >> |> =A0|>>> =A0 - else the packet is dropped and the incident is logged >> |> =A0|>>> >> |> =A0|>>> =A0 As SAVI has a site/link scope, with the logs, IMHO, it sh= ould >> be >> |> =A0|>>> =A0easier for the SAVI admin to understand/solve the issue. >> |> =A0|>>> >> |> =A0|>>> =A0 Best regards. >> |> =A0|>>> >> |> =A0|>>> =A0 JMC. >> |> =A0|>>> >> |> =A0|>>> >> |> =A0|>>> >> |> =A0|>> >> |> =A0|> >> |> =A0| =A0_______________________________________________ >> |> =A0| =A0savi mailing list >> |> =A0| =A0savi@ietf.org >> |> =A0| =A0https://www.ietf.org/mailman/listinfo/savi >> |> >> |> =A0_______________________________________________ >> |> =A0savi mailing list >> |> =A0savi@ietf.org >> |> =A0https://www.ietf.org/mailman/listinfo/savi >> |> >> >> > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From jeanmichel.combes@gmail.com Fri Sep 9 08:04:57 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 703C521F8BF7 for ; Fri, 9 Sep 2011 08:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.309 X-Spam-Level: X-Spam-Status: No, score=-103.309 tagged_above=-999 required=5 tests=[AWL=0.290, 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 vytfUCrWds-O for ; Fri, 9 Sep 2011 08:04:57 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id DE89C21F8BEE for ; Fri, 9 Sep 2011 08:04:56 -0700 (PDT) Received: by gyd12 with SMTP id 12so1861827gyd.31 for ; Fri, 09 Sep 2011 08:06:52 -0700 (PDT) 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; bh=82DTBphvqgh7uEHfz5QnMSUtHDljE4PGKYbrwXxovdA=; b=ILpKbmJCLzwvW3yXkUrqy7ya+ijHf4ePwQ7ZQq+x+O051hvnVA85kCp6ZfFhteaxcy IcIDfBIcm/nEhfYYE2a53i3npvI26ggDJxXTNuLs43JAPZNEf1UrL9DgrQk7wQDQd1CU nqr1H0LhGqo8V7YEdAi6K+dxIyHqsYGzjQsgU= MIME-Version: 1.0 Received: by 10.236.200.195 with SMTP id z43mr12371580yhn.127.1315580810088; Fri, 09 Sep 2011 08:06:50 -0700 (PDT) Received: by 10.146.82.14 with HTTP; Fri, 9 Sep 2011 08:06:49 -0700 (PDT) In-Reply-To: References: <4E01F2FF.7030108@acm.org> <4E0A11D8.5010300@joelhalpern.com> <000001cc6c8a$a4857c80$ed907580$@it.uc3m.es> <4E662CAF.1010905@joelhalpern.com> <003c01cc6cb7$238670d0$6a935270$@it.uc3m.es> <4E665A4F.9080608@joelhalpern.com> Date: Fri, 9 Sep 2011 17:06:49 +0200 Message-ID: From: Jean-Michel Combes To: Fred Baker Content-Type: text/plain; charset=ISO-8859-1 Cc: SAVI Mailing List , =?ISO-8859-1?Q?Alberto_Garc=EDa?= Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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, 09 Sep 2011 15:04:57 -0000 Hi Fred, same clarification: from your point of view, we have just to mention the issue without adding a potential solution to mitigate it, correct? Thanks. Yours, JMC. 2011/9/6 Fred Baker : > > On Sep 6, 2011, at 10:37 AM, Joel M. Halpern wrote: >> It seems to me much better to note this vulnerability in SAVI, and leave it there. >> If we want it fixed, 6man should simply instruct hosts not to accept RAs or DHCPs in fragmented packets. > > having 6man fix it makes sense to me. I'm not sure how we can fix it in SAVI without asking the switch to reassemble fragmented messages. > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From jmh@joelhalpern.com Fri Sep 9 08:52: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 9E61A21F86AA for ; Fri, 9 Sep 2011 08:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 1rTlfEgN5DhA for ; Fri, 9 Sep 2011 08:52:47 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id 31FE321F88B6 for ; Fri, 9 Sep 2011 08:52:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 78EDD325C156; Fri, 9 Sep 2011 08:54:42 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.104] (pool-71-161-51-56.clppva.btas.verizon.net [71.161.51.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id C20D03228BE9; Fri, 9 Sep 2011 08:54:41 -0700 (PDT) Message-ID: <4E6A369F.1070605@joelhalpern.com> Date: Fri, 09 Sep 2011 11:54:07 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Jean-Michel Combes References: <4E01F2FF.7030108@acm.org> <4E0A11D8.5010300@joelhalpern.com> <000001cc6c8a$a4857c80$ed907580$@it.uc3m.es> <4E662CAF.1010905@joelhalpern.com> <003c01cc6cb7$238670d0$6a935270$@it.uc3m.es> <4E665A4F.9080608@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: SAVI Mailing List , =?windows-1252?Q?Alberto_Garc=EDa?= Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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, 09 Sep 2011 15:52:48 -0000 Agreed. Our document should not describe the solution. Joel On 9/9/2011 11:05 AM, Jean-Michel Combes wrote: > Hi Joel, > > > 2011/9/6 Joel M. Halpern: > > [snip] > >> >> It seems to me much better to note this vulnerability in SAVI, and leave it >> there. > > Just a clarification: from your point of view, we have just to mention > the issue without adding a potential solution (e.g., > http://www.ietf.org/mail-archive/web/savi/current/msg01675.html) to > mitigate it, correct? > > Thanks. > > Yours, > > JMC. > >> If we want it fixed, 6man should simply instruct hosts not to accept RAs or >> DHCPs in fragmented packets. >> >> Yours, >> Joel >> From fred@cisco.com Fri Sep 9 09:50:45 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 CA1E721F8802 for ; Fri, 9 Sep 2011 09:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.792 X-Spam-Level: X-Spam-Status: No, score=-102.792 tagged_above=-999 required=5 tests=[AWL=-0.193, 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 C5bo51qVQUZi for ; Fri, 9 Sep 2011 09:50:45 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 339F321F87D3 for ; Fri, 9 Sep 2011 09:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1196; q=dns/txt; s=iport; t=1315587161; x=1316796761; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=P+7UgzY46eEwRlgR4XWVYAqLyW+4eHmPByycE1AM/uA=; b=NrNilz2UJRYPZRtwqGBuas4V8bA64QnudDzehi1G8PPeBC7wMUMH/rAb u1zqe8pAUaeoUsvc8p9sKMET/tBpYU/H/QNiNiFqyw6IUeqAY2WWfto53 FuWR2rfa5yq13PouhLsLit+DAmzMu5aTsKvsYi3Hz1ni9RQLqDPsNv7H9 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAHAFpDak6rRDoH/2dsb2JhbABBoVaGO3iBUgEBAQECAQEBAQ8BJzQLBQsLGC4nMAYTGweHVASYMAGeUoYOYASHbYtLhRWMJQ X-IronPort-AV: E=Sophos;i="4.68,357,1312156800"; d="scan'208";a="1194263" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 09 Sep 2011 16:52:40 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p89GqdOm011123; Fri, 9 Sep 2011 16:52:40 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Fri, 09 Sep 2011 09:52:40 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Fri, 09 Sep 2011 09:52:40 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Fri, 9 Sep 2011 09:52:30 -0700 Message-Id: <6808F94D-BDE1-464A-99D7-491D7174EE57@cisco.com> References: <4E01F2FF.7030108@acm.org> <4E0A11D8.5010300@joelhalpern.com> <000001cc6c8a$a4857c80$ed907580$@it.uc3m.es> <4E662CAF.1010905@joelhalpern.com> <003c01cc6cb7$238670d0$6a935270$@it.uc3m.es> <4E665A4F.9080608@joelhalpern.com> To: Jean-Michel Combes X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: SAVI Mailing List , =?iso-8859-1?Q?Alberto_Garc=EDa?= Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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, 09 Sep 2011 16:50:46 -0000 On Sep 9, 2011, at 8:06 AM, Jean-Michel Combes wrote: > Hi Fred, >=20 > same clarification: from your point of view, we have just to mention > the issue without adding a potential solution to > mitigate it, correct? Yes. =46rom my perspective, the most likely solution to be developed in = 6man is to ignore ICMP messages with headers or which arrive fragmented, = so that sending the messages is at most a bandwidth dos but has no other = real effect. In SAVI, however, it makes sense to mention that there is a = problem. > Thanks. >=20 > Yours, >=20 > JMC. >=20 > 2011/9/6 Fred Baker : >>=20 >> On Sep 6, 2011, at 10:37 AM, Joel M. Halpern wrote: >>> It seems to me much better to note this vulnerability in SAVI, and = leave it there. >>> If we want it fixed, 6man should simply instruct hosts not to accept = RAs or DHCPs in fragmented packets. >>=20 >> having 6man fix it makes sense to me. I'm not sure how we can fix it = in SAVI without asking the switch to reassemble fragmented messages. >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >>=20 From jeanmichel.combes@gmail.com Fri Sep 9 10:01: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 3771D21F846D for ; Fri, 9 Sep 2011 10:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 7jtevnhBCABI for ; Fri, 9 Sep 2011 10:01:42 -0700 (PDT) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8114521F85B9 for ; Fri, 9 Sep 2011 10:01:42 -0700 (PDT) Received: by gwb17 with SMTP id 17so1966374gwb.15 for ; Fri, 09 Sep 2011 10:03:35 -0700 (PDT) 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=PxWhuumReN7sCjHMUfCbXOVz8bs1vWJQwPwrUlASHSA=; b=S3gOxevEOuQcZ9Cy9oZI4vFYG3VoJv3t4Ij67MqfMnxVqv7u0gAWDVKqAqtrxd93uo hao3RhccRuWx6nmxMXlwotqrBc+YMjHVVC9QO/Iaq9892QJoc3ER5A91pvvsMQugMwtA /8x1d/dvi9zXr/DmKUhw6Hb0hGsSo1BE4s2Eo= MIME-Version: 1.0 Received: by 10.236.200.195 with SMTP id z43mr13235965yhn.127.1315587815539; Fri, 09 Sep 2011 10:03:35 -0700 (PDT) Received: by 10.146.82.14 with HTTP; Fri, 9 Sep 2011 10:03:35 -0700 (PDT) In-Reply-To: <6808F94D-BDE1-464A-99D7-491D7174EE57@cisco.com> References: <4E01F2FF.7030108@acm.org> <4E0A11D8.5010300@joelhalpern.com> <000001cc6c8a$a4857c80$ed907580$@it.uc3m.es> <4E662CAF.1010905@joelhalpern.com> <003c01cc6cb7$238670d0$6a935270$@it.uc3m.es> <4E665A4F.9080608@joelhalpern.com> <6808F94D-BDE1-464A-99D7-491D7174EE57@cisco.com> Date: Fri, 9 Sep 2011 19:03:35 +0200 Message-ID: From: Jean-Michel Combes To: Fred Baker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: SAVI Mailing List , =?ISO-8859-1?Q?Alberto_Garc=EDa?= Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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, 09 Sep 2011 17:01:43 -0000 OK. Thanks. I would appreciate the opinion from other people in the WG (i.e., just mentioning the issue and the consequences v.s. mentioning the issue and adding text about a potential solution to mitigate it), please. Thanks. Best regards. JMC. 2011/9/9 Fred Baker : > > On Sep 9, 2011, at 8:06 AM, Jean-Michel Combes wrote: > >> Hi Fred, >> >> same clarification: from your point of view, we have just to mention >> the issue without adding a potential solution to >> mitigate it, correct? > > Yes. From my perspective, the most likely solution to be developed in 6ma= n is to ignore ICMP messages with headers or which arrive fragmented, so th= at sending the messages is at most a bandwidth dos but has no other real ef= fect. In SAVI, however, it makes sense to mention that there is a problem. > >> Thanks. >> >> Yours, >> >> JMC. >> >> 2011/9/6 Fred Baker : >>> >>> On Sep 6, 2011, at 10:37 AM, Joel M. Halpern wrote: >>>> It seems to me much better to note this vulnerability in SAVI, and lea= ve it there. >>>> If we want it fixed, 6man should simply instruct hosts not to accept R= As or DHCPs in fragmented packets. >>> >>> having 6man fix it makes sense to me. I'm not sure how we can fix it in= SAVI without asking the switch to reassemble fragmented messages. >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> > > From junbi@cernet.edu.cn Sat Sep 10 10:10: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 46D5E21F8770 for ; Sat, 10 Sep 2011 10:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.902 X-Spam-Level: X-Spam-Status: No, score=-99.902 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696, 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 fve7d7mhY9i8 for ; Sat, 10 Sep 2011 10:10:21 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id BF1C421F86E0 for ; Sat, 10 Sep 2011 10:10:20 -0700 (PDT) Received: from junbiVAIOz138([101.38.13.233]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm124e6bb5b2; Sun, 11 Sep 2011 01:12:13 +0800 Message-ID: From: "Jun Bi" To: "Jean-Michel Combes" , "Fred Baker" References: <4E01F2FF.7030108@acm.org><4E0A11D8.5010300@joelhalpern.com><000001cc6c8a$a4857c80$ed907580$@it.uc3m.es><4E662CAF.1010905@joelhalpern.com><003c01cc6cb7$238670d0$6a935270$@it.uc3m.es><4E665A4F.9080608@joelhalpern.com><6808F94D-BDE1-464A-99D7-491D7174EE57@cisco.com> In-Reply-To: Date: Sun, 11 Sep 2011 01:12:09 +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.3508.1109 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3508.1109 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: bENG1C1B Cc: SAVI Mailing List , =?utf-8?Q?Alberto_Garc=C3=ADa?= Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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: Sat, 10 Sep 2011 17:10:22 -0000 I vote for "just mentioning the issue and the consequences" I agree with Fred and Joel. This common threat should be fixed by 6man or other WGs working on IPv6 itself. In SAVI, we just mention the issues (and actually also the requirement to fix it by other WGs). Especially when the current SAVI charter forbids to change protocol or create new protocol, our solution is weakened, then it is hard for us to fix it completely. thanks, Jun Bi -----原始邮件----- From: Jean-Michel Combes Sent: Saturday, September 10, 2011 1:03 AM To: Fred Baker Cc: SAVI Mailing List ; Alberto García Subject: Re: [savi] Potential issue for all SAVI mechanisms? OK. Thanks. I would appreciate the opinion from other people in the WG (i.e., just mentioning the issue and the consequences v.s. mentioning the issue and adding text about a potential solution to mitigate it), please. Thanks. Best regards. JMC. 2011/9/9 Fred Baker : > > On Sep 9, 2011, at 8:06 AM, Jean-Michel Combes wrote: > >> Hi Fred, >> >> same clarification: from your point of view, we have just to mention >> the issue without adding a potential solution to >> mitigate it, correct? > > Yes. From my perspective, the most likely solution to be developed in 6man > is to ignore ICMP messages with headers or which arrive fragmented, so > that sending the messages is at most a bandwidth dos but has no other real > effect. In SAVI, however, it makes sense to mention that there is a > problem. > >> Thanks. >> >> Yours, >> >> JMC. >> >> 2011/9/6 Fred Baker : >>> >>> On Sep 6, 2011, at 10:37 AM, Joel M. Halpern wrote: >>>> It seems to me much better to note this vulnerability in SAVI, and >>>> leave it there. >>>> If we want it fixed, 6man should simply instruct hosts not to accept >>>> RAs or DHCPs in fragmented packets. >>> >>> having 6man fix it makes sense to me. I'm not sure how we can fix it in >>> SAVI without asking the switch to reassemble fragmented messages. >>> _______________________________________________ >>> 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 alberto@it.uc3m.es Mon Sep 12 09:33:11 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 006C821F8B43 for ; Mon, 12 Sep 2011 09:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 SQpmdHkZsrFH for ; Mon, 12 Sep 2011 09:33:10 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDF921F86DD for ; Mon, 12 Sep 2011 09:33:09 -0700 (PDT) X-uc3m-safe: yes Received: from BOMBO (wlap006.it.uc3m.es [163.117.139.189]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 15C86C283E2; Mon, 12 Sep 2011 18:35:12 +0200 (CEST) From: =?utf-8?Q?Alberto_Garc=C3=ADa?= To: "'Jun Bi'" , "'Jean-Michel Combes'" , "'Fred Baker'" References: <4E01F2FF.7030108@acm.org><4E0A11D8.5010300@joelhalpern.com><000001cc6c8a$a4857c80$ed907580$@it.uc3m.es><4E662CAF.1010905@joelhalpern.com><003c01cc6cb7$238670d0$6a935270$@it.uc3m.es><4E665A4F.9080608@joelhalpern.com><6808F94D-BDE1-464A-99D7-491D7174EE57@cisco.com> In-Reply-To: Date: Mon, 12 Sep 2011 18:35:40 +0200 Message-ID: <003701cc716a$028deef0$07a9ccd0$@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFTB4vJwakhVfIfNKzvlDJLZuN+EQINlRVdAbHq4KYA5WEYMgGuC5/rAcdsZG8C+kqQyAIxP+zVAPzbFJICSl3pqwEzQR0CAaz4hQsCi/1NCAGAbyVqlYD0+uA= Content-Language: es X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18382.000 Cc: 'SAVI Mailing List' Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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 Sep 2011 16:33:11 -0000 Hi, For me it's also fine the 'just mentioning the issue and the = consequences' approach. Regards, Alberto | -----Mensaje original----- | De: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] En nombre de = Jun | Bi | Enviado el: s=C3=A1bado, 10 de septiembre de 2011 19:12 | Para: Jean-Michel Combes; Fred Baker | CC: SAVI Mailing List; Alberto Garc=C3=ADa | Asunto: Re: [savi] Potential issue for all SAVI mechanisms? | =20 | I vote for "just mentioning the issue and the consequences" | =20 | I agree with Fred and Joel. This common threat should be fixed by = 6man or | other WGs working on IPv6 itself. | In SAVI, we just mention the issues (and actually also the = requirement to fix | it by other WGs). Especially when the current SAVI charter forbids to = change | protocol or create new protocol, our solution is weakened, then it is = hard | for us to fix it completely. | =20 | thanks, | Jun Bi | =20 | =20 | =20 | -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- | From: Jean-Michel Combes | Sent: Saturday, September 10, 2011 1:03 AM | To: Fred Baker | Cc: SAVI Mailing List ; Alberto Garc=C3=ADa | Subject: Re: [savi] Potential issue for all SAVI mechanisms? | =20 | OK. Thanks. | =20 | I would appreciate the opinion from other people in the WG (i.e., = just | mentioning the issue and the consequences v.s. mentioning the issue = and | adding text about a potential solution to mitigate it), please. | =20 | Thanks. | =20 | Best regards. | =20 | JMC. | =20 | 2011/9/9 Fred Baker : | > | > On Sep 9, 2011, at 8:06 AM, Jean-Michel Combes wrote: | > | >> Hi Fred, | >> | >> same clarification: from your point of view, we have just to = mention | >> the issue without adding a potential solution to mitigate it, | >> correct? | > | > Yes. From my perspective, the most likely solution to be developed = in | > 6man is to ignore ICMP messages with headers or which arrive | > fragmented, so that sending the messages is at most a bandwidth dos | > but has no other real effect. In SAVI, however, it makes sense to | > mention that there is a problem. | > | >> Thanks. | >> | >> Yours, | >> | >> JMC. | >> | >> 2011/9/6 Fred Baker : | >>> | >>> On Sep 6, 2011, at 10:37 AM, Joel M. Halpern wrote: | >>>> It seems to me much better to note this vulnerability in SAVI, = and | >>>> leave it there. | >>>> If we want it fixed, 6man should simply instruct hosts not to | >>>> accept RAs or DHCPs in fragmented packets. | >>> | >>> having 6man fix it makes sense to me. I'm not sure how we can fix = it | >>> in SAVI without asking the switch to reassemble fragmented = messages. | >>> _______________________________________________ | >>> 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 | =20 | _______________________________________________ | savi mailing list | savi@ietf.org | https://www.ietf.org/mailman/listinfo/savi From jari.arkko@piuha.net Wed Sep 21 11:38:25 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 3DAE021F8B32 for ; Wed, 21 Sep 2011 11:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 O0Y4BKCpXj8X for ; Wed, 21 Sep 2011 11:38:24 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 5647121F8A97 for ; Wed, 21 Sep 2011 11:38:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 423952D543; Wed, 21 Sep 2011 21:40:53 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xbuu906JCZor; Wed, 21 Sep 2011 21:40:52 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 5C2CE2CE32; Wed, 21 Sep 2011 21:40:52 +0300 (EEST) Message-ID: <4E7A2FB4.9080303@piuha.net> Date: Wed, 21 Sep 2011 21:40:52 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Jun Bi References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SAVI Mailing List Subject: [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: Wed, 21 Sep 2011 18:38:25 -0000 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? > 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. > 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). > 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? Editorial: > Figure 2 Instance of BST First use of the abbreviation BST. Please expand somewhere. > Figure 3 Instance of FT As above. > If there is enough binding > entry resource, resources > If the binding anchor is switch port, there can be vulnerability in > a switch port Jari From xuke@mail.tsinghua.edu.cn Sat Sep 24 01:15:02 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 B1DFD21F8B54 for ; Sat, 24 Sep 2011 01:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] 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 8WnQm4Daa+48 for ; Sat, 24 Sep 2011 01:15:02 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by ietfa.amsl.com (Postfix) with ESMTP id D7DD721F8B64 for ; Sat, 24 Sep 2011 01:15:01 -0700 (PDT) Received: from [115.171.233.45] (helo=xuke-air) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1R7NQT-0002oh-Rv for savi@ietf.org; Sat, 24 Sep 2011 16:17:34 +0800 Date: Sat, 24 Sep 2011 16:17:34 +0800 From: "xuke" To: "SAVI Mailing List" References: <201109241504437330313@mail.tsinghua.edu.cn> Message-ID: <201109241617340411817@mail.tsinghua.edu.cn> Organization: Institute of Computer Network and Technology, Tsinghua University X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Subject: [savi] [SAVI]possible future works X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: xuke@mail.tsinghua.edu.cn List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2011 08:15:02 -0000 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 Ethernet access subnet. However, there are many efforts need SAVI workgroup to make and there are many works to be done for SAVI prompting, there are some possible future works I suggest: (1) 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) 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) Even though SAVI has a preliminary application in WiFi scenario, its application in mobile communication(3G,LTE etc.) scenario still need to be exploited. xuke From junbi@cernet.edu.cn Sat Sep 24 06:59:06 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 8490721F8ABE for ; Sat, 24 Sep 2011 06:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.488 X-Spam-Level: X-Spam-Status: No, score=-97.488 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_HAS_XAIMC=2.696, 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 Z-0VCFlDAgPu for ; Sat, 24 Sep 2011 06:59:06 -0700 (PDT) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id B87F021F8ABC for ; Sat, 24 Sep 2011 06:59:04 -0700 (PDT) Received: from junbiVAIOz138([115.170.148.46]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54e7e56b9; Sat, 24 Sep 2011 22:01:38 +0800 Message-ID: <59FEDFBDF20440EAA9A52CD97E558B6B@junbiVAIOz138> From: "Jun Bi" To: , "SAVI Mailing List" References: <201109241504437330313@mail.tsinghua.edu.cn> <201109241617340411817@mail.tsinghua.edu.cn> In-Reply-To: <201109241617340411817@mail.tsinghua.edu.cn> Date: Sat, 24 Sep 2011 22:01:39 +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.3508.1109 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3508.1109 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: qF2n2H1B 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: Sat, 24 Sep 2011 13:59:06 -0000 I agree that those are potential topics of SAVI WG. Regarding to the SAVI for IPv4/IPv6 co-existence and transition, I also think we need to study source address validation for those "traditional" IPv6 transition methods, such as ISATAP, etc. In CERNET2 operation, we had found that some users access IPv6 by ISATAP, but for some reasons, they didn't use the IPv6 source address of that tunnel, but use the IPv6 source address of another LAN interface of the same PC. Another potentail area is to study SAVI beyond the local link, for example, to ehance uRPF loose mode by reduceing the false negative. thanks, Jun Bi -----原始邮件----- From: xuke Sent: Saturday, September 24, 2011 4:17 PM To: SAVI Mailing List Subject: [savi] [SAVI]possible future works 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 Ethernet access subnet. However, there are many efforts need SAVI workgroup to make and there are many works to be done for SAVI prompting, there are some possible future works I suggest: (1) 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) 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) Even though SAVI has a preliminary application in WiFi scenario, 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 From bjornliu@gmail.com Sat Sep 24 09:23:01 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 D803021F8B85 for ; Sat, 24 Sep 2011 09:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, 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 KD5WTCfD8hmM for ; Sat, 24 Sep 2011 09:23:00 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 893FD21F8B88 for ; Sat, 24 Sep 2011 09:23:00 -0700 (PDT) Received: by vws5 with SMTP id 5so5425696vws.31 for ; Sat, 24 Sep 2011 09:25:33 -0700 (PDT) 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=4M9Y/brx+xtYQ2z6Vs0d2Crwu3FjXWKn2LefLDPSM6Y=; b=FZkwn8BElEXh+eE5EcPrOJERd3X81GUIzqq0eZ0zhYLXl2zx1KHBx6La6snf4oDvHZ ID0p7+EWrigLVcWj7xRYlPKkoeaDhUF7GYIXXsjA5CU33lGh3xXh77c/smL3dzHhLT3a 5exMtOmmeXA9UEjSJ5IuWdwPy/dOGTmvQKGTc= MIME-Version: 1.0 Received: by 10.52.77.71 with SMTP id q7mr4124952vdw.145.1316881533707; Sat, 24 Sep 2011 09:25:33 -0700 (PDT) Received: by 10.52.188.134 with HTTP; Sat, 24 Sep 2011 09:25:33 -0700 (PDT) Date: Sat, 24 Sep 2011 12:25:33 -0400 Message-ID: From: Bingyang LIU To: savi@ietf.org Content-Type: multipart/alternative; boundary=20cf3071cf9607258604adb26004 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: Sat, 24 Sep 2011 16:23:02 -0000 --20cf3071cf9607258604adb26004 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable uRPF loose mode has significant false negative. Surprisingly, it also has false positive. False negative: uRPF only checks the existence of the source prefix in the forwarding table, rather than checking the reverse direction. A random selected source address has the probability of 0.58 (according to the current advertised IPv4 address space in BGP) to circumvent uRPF loose mode= , which results in very high false negative. Besides, a slightly smarter attacker can use routable source addresses rather than using random ones, s= o that she can circumvent all loose mode uRPF checks. Finally, uRPF loose mod= e can do nothing with Distributed Redirected DoS (DrDoS). In DrDoS the source addresses of the spoofing packets' are the victims' IP addresses which are obviously routable and considered valid by uRPF loose mode. As known, a DrDoS attack amplified by DNS reached the 100Gbps, which is the highest attack volume ever observed, according to ARBOR's security report 2010. False positive: uRPF loose mode is considered to be very loose to avoid false positive. However it may cause false positive when applied to non-DFZ (default free zone). Consider the scenario in this picture [ http://netarchlab.tsinghua.edu.cn/~liuby/fp.jpg]. D is an border router of the non-DFZ, and the FIB is listed. According to uRPF loose mode, the valid packet (src=3D2.0.0.0/8, dst=3D1.1.0.0/16) sent from S to D through P2 will= be denied by D, because 2.0.0.0/8 matches the default route (in either type of loose mode uRPF defined in RFC3704, the packet will be denied). Briefly speaking, uRPF loose mode may cause false positive in non-DFZ. We obviously need better technique to source spoofing than uRPF loose mode. Bingyang Liu ------------------------------ I agree that those are potential topics of SAVI WG. Regarding to the SAVI for IPv4/IPv6 co-existence and transition, I also thi= nk we need to study source address validation for those "traditional" IPv6 transition methods, such as ISATAP, etc. In CERNET2 operation, we had found that some users access IPv6 by ISATAP, but for some reasons, they didn't us= e the IPv6 source address of that tunnel, but use the IPv6 source address of another LAN interface of the same PC. Another potentail area is to study SAVI beyond the local link, for example,= to ehance uRPF loose mode by reduceing the false negative. thanks, Jun Bi -----=E5=E5=E9=E4----- From: xuke Sent: Saturday, September 24, 2011 4:17 PM To: SAVI Mailing List Subject: [savi] [SAVI]possible future works Dear SAVI WG members There is no doubt, SAVI has made significant contribution for IP source add= ress validation and anti-spoofing in the scenario of pure IPv6 Ethernet access subnet. However, there are many efforts need SAVI workgroup to make and there are many works to be done for SAVI prompting, there are some possible future works I suggest: (1) 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) 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) Even though SAVI has a preliminary application in WiFi scenario, its application in mobile communication(3G,LT= E etc.) scenario still need to be exploited. xuke --=20 Bingyang Liu Network Architecture Lab, Network Center,Tsinghua Univ. Beijing, China Home Page: http://netarchlab.tsinghua.edu.cn/~liuby --20cf3071cf9607258604adb26004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
uRPF loose mode has significant false negative. Surprisingly,= it also has false positive.=A0

False negative: uRPF only checks the=A0existence=A0of the source prefix = in the forwarding table, rather than checking the reverse direction. A rand= om selected source address has the probability of 0.58 (according to the cu= rrent advertised IPv4 address space in BGP) to circumvent uRPF loose mode, = which results in very high false negative. Besides, a slightly smarter atta= cker can use routable source addresses rather than using random ones, so th= at she can circumvent all loose mode uRPF checks. Finally, uRPF loose mode = can do nothing with Distributed Redirected DoS (DrDoS). In DrDoS the=A0source addresses of=A0the spoofing packets'= =A0are the victims'=A0IP addresses whi= ch are obviously routable and considered valid by uRPF loose mode. As known= , a DrDoS attack amplified by DNS reached the 100Gbps, which is the highest= attack volume ever observed, according to ARBOR's security report 2010= .=A0

Fal= se positive: uRPF loose mode is considered to be very loose to avoid false = positive. However it may cause false positive when applied to non-DFZ (defa= ult free zone). Consider the scenario in this picture [http://netarchlab.tsinghua.e= du.cn/~liuby/fp.jpg]. D is an border router of the non-DFZ, an= d the FIB is listed. According to uRPF loose mode, the valid packet (src=3D= 2.0.0.0/8, dst=3D1.1.0.0/16) sent from S to D through P2 will be denied by D, becau= se 2.0.0.0/8 matches the default route (in= either type of loose mode uRPF defined in RFC3704, the packet will be deni= ed). Briefly speaking, uRPF loose mode may cause false positive in non-DFZ.= =A0

We obviously need better tech= nique to source spoofing than uRPF loose mode.

Bingyang Liu


I agree that those are potential topics of SAVI WG.
Regarding to the SAVI for IPv4/IPv6 co-existence and transition, = I also=A0think we need to study source address validation for thos= e "traditional"=A0IPv6 transition methods, such as ISATA= P, etc. In CERNET2 operation, we had=A0found that some users acces= s IPv6 by ISATAP, but for some reasons, they=A0didn't use the = IPv6 source address of that tunnel, but use the IPv6 source=A0addr= ess of another LAN interface of the same PC.
Another potentail area is to study SAVI beyond the local link, fo=
r example,=A0to ehance uRPF loose mode by reduceing the false nega=
tive.
thanks,
Jun Bi




-----=E5=E5=E9=E4-----=A0From: xuke
Sent: Saturday,=
 September 24, 2011 4:17 PM
To: SAVI Mailing List
Subject: [savi] [SAVI]possible future works

Dear SAVI WG members


There is no doubt, SAVI has made significant contribution for IP =
source=A0address validation and anti-spoofing in the scenario of p=
ure IPv6 Ethernet=A0access subnet. However, there are many efforts=
 need SAVI workgroup to make=A0and there are many works to be done=
 for SAVI prompting, there are some=A0possible future works I sugg=
est:=A0(1) Considering there would be a long period to transit IPv=
4 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) Applying SAVI technology into non-Ethernet access subnet circ=
umstance.=A0In the matter of fact, many netizens still use PPoE, A=
DSL and=A0ISDN technology to access Internet. It means a lot to te=
lecommunication=A0carriers for applying SAVI into those scenarios.=
=A0(3) Even though SAVI has a preliminary application in WiFi scen=
ario, its=A0application in mobile communication(3G,LTE etc.) scena=
rio still need to
be exploited.

xuke



-- 
Bingyang Liu
Network A=
rchitecture Lab, Network Center,Tsinghua Univ.
Beijing, China
Home Pa=
ge: http://netarchlab.=
tsinghua.edu.cn/~liuby



--20cf3071cf9607258604adb26004--

From swmike@swm.pp.se  Sun Sep 25 00:15:01 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 C25BE21F8B3E for ; Sun, 25 Sep 2011 00:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.545
X-Spam-Level: 
X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054,  BAYES_00=-2.599]
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 Lg5HqZThrHHA for ; Sun, 25 Sep 2011 00:14:58 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 9351921F8B3A for ; Sun, 25 Sep 2011 00:14:55 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 80C779C; Sun, 25 Sep 2011 09:17:31 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7B5E19A; Sun, 25 Sep 2011 09:17:31 +0200 (CEST)
Date: Sun, 25 Sep 2011 09:17:31 +0200 (CEST)
From: Mikael Abrahamsson 
To: Bingyang LIU 
In-Reply-To: 
Message-ID: 
References: 
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: savi@ietf.org
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: Sun, 25 Sep 2011 07:15:01 -0000

On Sat, 24 Sep 2011, Bingyang LIU wrote:

> We obviously need better technique to source spoofing than uRPF loose 
> mode.

In my opinion, for IPv4 uRPF loose is only used for ddos protection in 
conjunction with null-routing the prefix of the source you want to block.

Using it for antispoofing stopped working a long time ago, as you pointed 
out.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

From junbi@cernet.edu.cn  Sun Sep 25 00:42:34 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 0C1D321F89BA for ; Sun, 25 Sep 2011 00:42:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.136
X-Spam-Level: 
X-Spam-Status: No, score=-96.136 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_HAS_XAIMC=2.696, RCVD_ILLEGAL_IP=1.908, 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 hLmxVRI3XIMz for ; Sun, 25 Sep 2011 00:42:33 -0700 (PDT)
Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id 0120621F88B7 for ; Sun, 25 Sep 2011 00:42:31 -0700 (PDT)
Received: from junbiVAIOz138([1.203.95.37]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54e7f4ffb; Sun, 25 Sep 2011 15:45:08 +0800
Message-ID: <533866227DC249FAB3BAAD4E4CA75A59@junbiVAIOz138>
From: "Jun Bi" 
To: "Mikael Abrahamsson" , "Bingyang LIU" 
References:  
In-Reply-To: 
Date: Sun, 25 Sep 2011 15:45:08 +0800
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 15.4.3508.1109
X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3508.1109
X-AIMC-AUTH: junbi
X-AIMC-MAILFROM: junbi@cernet.edu.cn
X-AIMC-Msg-ID: qMeYjH1B
Cc: savi@ietf.org
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: Sun, 25 Sep 2011 07:42:34 -0000

>Using it for antispoofing stopped working a long time ago, as you pointed 
>out.

Yes, so maybe SAVI WG could extend the charter to cover that filed.

thanks,
Jun Bi

-----原始邮件----- 
From: Mikael Abrahamsson
Sent: Sunday, September 25, 2011 3:17 PM
To: Bingyang LIU
Cc: savi@ietf.org
Subject: Re: [savi] [SAVI]possible future works

On Sat, 24 Sep 2011, Bingyang LIU wrote:

> We obviously need better technique to source spoofing than uRPF loose 
> mode.

In my opinion, for IPv4 uRPF loose is only used for ddos protection in
conjunction with null-routing the prefix of the source you want to block.

Using it for antispoofing stopped working a long time ago, as you pointed
out.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se
_______________________________________________
savi mailing list
savi@ietf.org
https://www.ietf.org/mailman/listinfo/savi 


From jari.arkko@piuha.net  Sun Sep 25 19:26:14 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 4B1B921F8672 for ; Sun, 25 Sep 2011 19:26:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.573
X-Spam-Level: 
X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 mRvfgC8rXBAX for ; Sun, 25 Sep 2011 19:26:13 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id A584321F863E for ; Sun, 25 Sep 2011 19:26:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6E7702D543; Mon, 26 Sep 2011 05:28:44 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrODbLdjxQNu; Mon, 26 Sep 2011 05:28:43 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 9FFB02CE32; Mon, 26 Sep 2011 05:28:42 +0300 (EEST)
Message-ID: <4E7FE358.50509@piuha.net>
Date: Mon, 26 Sep 2011 10:28:40 +0800
From: Jari Arkko 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2
MIME-Version: 1.0
To: Jun Bi , SAVI Mailing List 
References: <4DDC19D4.2040104@piuha.net>
In-Reply-To: <4DDC19D4.2040104@piuha.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [savi] AD review of draft-ietf-savi-framework
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, 26 Sep 2011 02:26:14 -0000

Jun,

I have reviewed the new version and it looks good, but I wonder if this suggested change was missed:

>> The reason to develop SAVI method variants for each single IP address
>> configuration method, in addition to the variant that handles all IP
>> address assignment methods, is to minimize the complexity of the
>> common case:  many link deployments today either are constrained to a
>> single IP address assignment methods or, equivalently from the
>> perspective of the SAVI method, separate IP address assignment
>> methods into different IP address prefixes.  The SAVI method for such
>> links can be simpler than the SAVI method for links with multiple IP
>> address assignment methods per IP address prefix.
>>
>
> Hmm. I'm not sure I buy this. First of all, I would claim that many
> links support multiple address assignment methods. For instance, dual
> stack links typically today support SLAAC for IPv6 and DHCP for IPv4.
> And its obvious that to fly in the IETF, the SAVI solution needs to
> support multiple methods. I would just replace the above text with:
>
> To provide a complete solution, SAVI methods need to support a variety
> of address configuration mechanisms. Of course there may be different
> SAVI specifications that specify, for instance SAVI functionality for
> IPv4 and IPv6 address configuration. It is expected that SAVI methods
> can collectively support DHCP [rfc2131,rfc3315], Stateless Address
> Autoconfiguration [rfc4862 ] with or
> without Secure Neighbor Discovery [rfc3971], IKEv2
> [rfc5996,rfc5739,rfc5026] and combinations thereof.

Or perhaps you disagreed with the change. In any case, I can't find a change in the new document or any discussion about this particular issue. Can you take a look?

Nevertheless, I have sent the document forward to a last call.

Jari


From iesg-secretary@ietf.org  Mon Sep 26 06:59:35 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 B354321F8C87; Mon, 26 Sep 2011 06:59:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.501
X-Spam-Level: 
X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 xp8y2BSsaF6F; Mon, 26 Sep 2011 06:59:34 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E194621F8C82; Mon, 26 Sep 2011 06:59:34 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 3.60
Message-ID: <20110926135934.21902.82720.idtracker@ietfa.amsl.com>
Date: Mon, 26 Sep 2011 06:59:34 -0700
Cc: savi@ietf.org
Subject: [savi] Last Call:  (Source Address	Validation Improvement Framework) to Informational RFC
X-BeenThere: savi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ietf@ietf.org
List-Id: Mailing list for the SAVI working group at IETF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Sep 2011 13:59:35 -0000

The IESG has received a request from the Source Address Validation
Improvements WG (savi) to consider the following document:
- 'Source Address Validation Improvement Framework'
   as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-10-10. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   The Source Address Validation Improvement method was developed to
   complement ingress filtering with finer-grained, standardized IP
   source address validation.  This document describes and motivates the
   design of the SAVI method.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-savi-framework/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-savi-framework/


No IPR declarations have been submitted directly on this I-D.



From jari.arkko@piuha.net  Mon Sep 26 09:30:39 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 AD48211E80A0 for ; Mon, 26 Sep 2011 09:30:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.574
X-Spam-Level: 
X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 Ze+6nUDmq+Am for ; Mon, 26 Sep 2011 09:30:38 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 827F611E809C for ; Mon, 26 Sep 2011 09:30:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CE37D2D543; Mon, 26 Sep 2011 19:33:20 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgCT6rXaDbyQ; Mon, 26 Sep 2011 19:33:19 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 054622CE32; Mon, 26 Sep 2011 19:33:16 +0300 (EEST)
Message-ID: <4E80A94B.7080305@piuha.net>
Date: Tue, 27 Sep 2011 00:33:15 +0800
From: Jari Arkko 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2
MIME-Version: 1.0
To: joel.halpern@ericsson.com, Russ Housley 
References: <7C4DFCE962635144B8FAE8CA11D0BF1E055F69357F@MX14A.corp.emc.com> <4DCD4DEA.2050902@joelhalpern.com> <7C4DFCE962635144B8FAE8CA11D0BF1E055F6937FA@MX14A.corp.emc.com> <4DD142AE.5030409@joelhalpern.com> <7C4DFCE962635144B8FAE8CA11D0BF1E055F693A04@MX14A.corp.emc.com> <4DD15A40.2010209@joelhalpern.com>
In-Reply-To: <4DD15A40.2010209@joelhalpern.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: david.black@emc.com, savi@ietf.org, jeanmichel.combes@gmail.com
Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-05
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, 26 Sep 2011 16:30:39 -0000

Joel,

I would like to close the loop on this issue.

I think we promised a change on this, and Russ is holding a Discuss until we do.

(I realize that there are bigger issues on the SAVI docs, but I'm working through the various issues this week, and this one seemed easy to solve. More e-mail on the other topics soon.)

Jari

On 17.05.2011 01:09, Joel M. Halpern wrote:
> I can plan to make these changes at the end of the last call.
> Joel
>
> On 5/16/2011 12:56 PM, david.black@emc.com wrote:
>> Joel,
>>
>> I think the LACP discussion could be added to 4.1.1.
>>
>> I also think that there's a general theme that needs to be covered across all of 4.1.1 - 4.1.4: When there are multiple traffic egress points from a domain (4.1.1 - 4.1.4 cover four different types of domains), the SAVI checks on all the egresses should be coordinated and consistent in order to avoid surprises when the traffic switches to a different egress point.
>>
>> Thanks,
>> --David
>>
>>> -----Original Message-----
>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>>> Sent: Monday, May 16, 2011 11:29 AM
>>> To: Black, David
>>> Cc: dmcpherson@verisign.com; fred@cisco.com; joel.halpern@ericsson.com; gen-art@ietf.org;
>>> savi@ietf.org; christian.vogt@ericsson.com; jeanmichel.combes@gmail.com
>>> Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-05
>>>
>>> Looking at the draft more carefully (when I am more awake, sorry), I
>>> think what you are asking is that more text be put in section 4.1, maybe
>>> a subsection?  That additional text would talk about placement on a
>>> switch that is not directly attached to the client, but is not as far
>>> upstream as the first hop router?  That text would include mention of
>>> the effect of spanning tree variation and LACP path changes.
>>>
>>> Sorry I was dense,
>>> Joel
>>>
>>> On 5/15/2011 9:45 PM, david.black@emc.com wrote:
>>>> Joel,
>>>>
>>>> If LACP is running active-passive across links to two different switches, there may be no physical
>>> network node common to the currently active and currently passive paths for some traffic.  If SAVI
>>> is set up poorly, a switch to the currently passive link could remove validation checks or black-
>>> hole traffic that was flowing on the previously active link. For example, binding an IP address to a
>>> single port or ports on a single switch is insufficient in such an environment (address validation
>>> binding needs to span switches).
>>>>
>>>> The material in 5.2.4 on Multi-LAN Hosts looks like a starting point - wrt SAVI, active-passive
>>> link aggregation across multiple switches can be a way to get into that sort of trouble on a single
>>> LAN (!).  Beyond that, I think the notion that SAVI checks should be consistent across alternate
>>> paths for the same traffic is applicable at other scopes, e.g., all egresses from a multi-homed
>>> network to the ISP networks involved.
>>>>
>>>> Thanks,
>>>> --David
>>>>
>>>>> -----Original Message-----
>>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>>>>> Sent: Friday, May 13, 2011 11:28 AM
>>>>> To: Black, David
>>>>> Cc: dmcpherson@verisign.com; fred@cisco.com; joel.halpern@ericsson.com; gen-art@ietf.org;
>>>>> savi@ietf.org; christian.vogt@ericsson.com; jeanmichel.combes@gmail.com
>>>>> Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-05
>>>>>
>>>>> Thank you David.
>>>>> I think I understand the second part of your comment (about
>>>>> multi-instance hosts), and will have to look at the document more to see
>>>>> how to address that.
>>>>>
>>>>> I am not sure I understand what the question is regarding the LACP /
>>>>> link group issue.  Is this really different from the issues that arise
>>>>> whenever the SAVI functionality is not on the leaf switch?  Where in the
>>>>> document do you think it would help to discuss this?
>>>>>
>>>>> Thank you,
>>>>> Joel
>>>>>
>>>>> On 5/13/2011 1:03 AM, david.black@emc.com wrote:
>>>>>> I am the assigned Gen-ART reviewer for this draft. For background on
>>>>>> Gen-ART, please see the FAQ at
>>>>>> .
>>>>>>
>>>>>> Please resolve these comments along with any other Last Call comments
>>>>>> you may receive.
>>>>>>
>>>>>> Document: draft-ietf-savi-threat-scope-05
>>>>>> Reviewer: David L. Black
>>>>>> Review Date: 12 May 2011
>>>>>> IETF LC End Date: 18 May 2011
>>>>>>
>>>>>> Summary: This draft is on the right track, but has open issues, described in the review.
>>>>>>
>>>>>> This draft discusses the threats and deployment environment for IP source
>>>>>> address validation with particular attention to finer-grain validation that
>>>>>> could be used within a network to validate IP addresses closer to the sources
>>>>>> of network traffic than ingress to an ISP's network.
>>>>>>
>>>>>> Major issues:
>>>>>>
>>>>>> There is no discussion of link teaming or aggregation (e.g., via LACP); this
>>>>>> may affect source address validation functionality by requiring the same
>>>>>> validation checks on all aggregated ports.  An important case to discuss
>>>>>> is where the aggregated host links are connected to ports on different switches
>>>>>> (e.g., in an active/passive configuration).
>>>>>>
>>>>>> The discussion of multi-instance hosts in section 5.2.3 is incomplete
>>>>>> in several important aspects:
>>>>>>
>>>>>> (1) Some of the software switch implementations are single instance switches
>>>>>> whose implementation is distributed across multiple physical servers.  This
>>>>>> results in concerns similar to the link aggregation discussion above.
>>>>>>
>>>>>> (2) Live migration of virtual machines among physical servers causes
>>>>>> relocation of MAC addresses across switch ports.  A so-called "gratuitous ARP"
>>>>>> is often used to inform the network of the MAC address move; port-based
>>>>>> source address validation information needs to move in response to such ARPs.
>>>>>>
>>>>>> (3) MAC address relocation is also used as a failure recovery technique; the
>>>>>> surviving hardware element (e.g., host in a cluster) takes over the MAC
>>>>>> addresses of the failed hardware; like the previous case, a "gratuitous ARP"
>>>>>> is a common means of informing the network that the MAC address has moved,
>>>>>> and source address validation information needs to move in response to it.
>>>>>>
>>>>>> Minor issues:
>>>>>>
>>>>>> There doesn't seem to be much discussion of dynamic network reconfiguration,
>>>>>> which may change traffic egress points.  VRRP may be a useful example to
>>>>>> discuss beyond the typical routing protocol updates to forwarding tables.
>>>>>>
>>>>>> Nits/editorial comments:
>>>>>>
>>>>>> idnits 2.12.11 ran clean.
>>>>>>
>>>>>> Thanks,
>>>>>> --David
>>>>>> ----------------------------------------------------
>>>>>> David L. Black, Distinguished Engineer
>>>>>> EMC Corporation, 176 South St., Hopkinton, MA  01748
>>>>>> +1 (508) 293-7953             FAX: +1 (508) 293-7786
>>>>>> david.black@emc.com        Mobile: +1 (978) 394-7754
>>>>>> ----------------------------------------------------
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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 joel.halpern@ericsson.com  Mon Sep 26 09:32: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 127E721F8C8A for ; Mon, 26 Sep 2011 09:32:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.904
X-Spam-Level: 
X-Spam-Status: No, score=-5.904 tagged_above=-999 required=5 tests=[AWL=0.695,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 k+6gagvMTEQ5 for ; Mon, 26 Sep 2011 09:32:04 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 245DE21F8C85 for ; Mon, 26 Sep 2011 09:32:04 -0700 (PDT)
Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p8QGYNHv009207; Mon, 26 Sep 2011 11:34:38 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 26 Sep 2011 12:34:32 -0400
From: Joel Halpern 
To: Jari Arkko , Russ Housley 
Date: Mon, 26 Sep 2011 12:34:30 -0400
Thread-Topic: [savi] Gen-ART review of draft-ietf-savi-threat-scope-05
Thread-Index: Acx8agLu5HAytFHIQg6UB9e+DdxrRAAABrWA
Message-ID: <49044C2B7F64814BAA8D09EA7B8D723216153EB462@EUSAACMS0701.eamcs.ericsson.se>
References: <7C4DFCE962635144B8FAE8CA11D0BF1E055F69357F@MX14A.corp.emc.com> <4DCD4DEA.2050902@joelhalpern.com> <7C4DFCE962635144B8FAE8CA11D0BF1E055F6937FA@MX14A.corp.emc.com> <4DD142AE.5030409@joelhalpern.com> <7C4DFCE962635144B8FAE8CA11D0BF1E055F693A04@MX14A.corp.emc.com> <4DD15A40.2010209@joelhalpern.com> <4E80A94B.7080305@piuha.net>
In-Reply-To: <4E80A94B.7080305@piuha.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "david.black@emc.com" , "savi@ietf.org" , "jeanmichel.combes@gmail.com" 
Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-05
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, 26 Sep 2011 16:32:05 -0000

That is one of a number of changes that are blocked pending the primary iss=
ue resolution.
Yours,
Joel=20

-----Original Message-----
From: Jari Arkko [mailto:jari.arkko@piuha.net]=20
Sent: Monday, September 26, 2011 12:33 PM
To: Joel Halpern; Russ Housley
Cc: david.black@emc.com; savi@ietf.org; jeanmichel.combes@gmail.com
Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-05

Joel,

I would like to close the loop on this issue.

I think we promised a change on this, and Russ is holding a Discuss until w=
e do.

(I realize that there are bigger issues on the SAVI docs, but I'm working t=
hrough the various issues this week, and this one seemed easy to solve. Mor=
e e-mail on the other topics soon.)

Jari

On 17.05.2011 01:09, Joel M. Halpern wrote:
> I can plan to make these changes at the end of the last call.
> Joel
>
> On 5/16/2011 12:56 PM, david.black@emc.com wrote:
>> Joel,
>>
>> I think the LACP discussion could be added to 4.1.1.
>>
>> I also think that there's a general theme that needs to be covered acros=
s all of 4.1.1 - 4.1.4: When there are multiple traffic egress points from =
a domain (4.1.1 - 4.1.4 cover four different types of domains), the SAVI ch=
ecks on all the egresses should be coordinated and consistent in order to a=
void surprises when the traffic switches to a different egress point.
>>
>> Thanks,
>> --David
>>
>>> -----Original Message-----
>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>>> Sent: Monday, May 16, 2011 11:29 AM
>>> To: Black, David
>>> Cc: dmcpherson@verisign.com; fred@cisco.com;=20
>>> joel.halpern@ericsson.com; gen-art@ietf.org; savi@ietf.org;=20
>>> christian.vogt@ericsson.com; jeanmichel.combes@gmail.com
>>> Subject: Re: [savi] Gen-ART review of=20
>>> draft-ietf-savi-threat-scope-05
>>>
>>> Looking at the draft more carefully (when I am more awake, sorry), I=20
>>> think what you are asking is that more text be put in section 4.1,=20
>>> maybe a subsection?  That additional text would talk about placement=20
>>> on a switch that is not directly attached to the client, but is not=20
>>> as far upstream as the first hop router?  That text would include=20
>>> mention of the effect of spanning tree variation and LACP path changes.
>>>
>>> Sorry I was dense,
>>> Joel
>>>
>>> On 5/15/2011 9:45 PM, david.black@emc.com wrote:
>>>> Joel,
>>>>
>>>> If LACP is running active-passive across links to two different=20
>>>> switches, there may be no physical
>>> network node common to the currently active and currently passive=20
>>> paths for some traffic.  If SAVI is set up poorly, a switch to the=20
>>> currently passive link could remove validation checks or black- hole=20
>>> traffic that was flowing on the previously active link. For example,=20
>>> binding an IP address to a single port or ports on a single switch is i=
nsufficient in such an environment (address validation binding needs to spa=
n switches).
>>>>
>>>> The material in 5.2.4 on Multi-LAN Hosts looks like a starting=20
>>>> point - wrt SAVI, active-passive
>>> link aggregation across multiple switches can be a way to get into=20
>>> that sort of trouble on a single LAN (!).  Beyond that, I think the=20
>>> notion that SAVI checks should be consistent across alternate paths=20
>>> for the same traffic is applicable at other scopes, e.g., all egresses =
from a multi-homed network to the ISP networks involved.
>>>>
>>>> Thanks,
>>>> --David
>>>>
>>>>> -----Original Message-----
>>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>>>>> Sent: Friday, May 13, 2011 11:28 AM
>>>>> To: Black, David
>>>>> Cc: dmcpherson@verisign.com; fred@cisco.com;=20
>>>>> joel.halpern@ericsson.com; gen-art@ietf.org; savi@ietf.org;=20
>>>>> christian.vogt@ericsson.com; jeanmichel.combes@gmail.com
>>>>> Subject: Re: [savi] Gen-ART review of=20
>>>>> draft-ietf-savi-threat-scope-05
>>>>>
>>>>> Thank you David.
>>>>> I think I understand the second part of your comment (about=20
>>>>> multi-instance hosts), and will have to look at the document more=20
>>>>> to see how to address that.
>>>>>
>>>>> I am not sure I understand what the question is regarding the LACP=20
>>>>> / link group issue.  Is this really different from the issues that=20
>>>>> arise whenever the SAVI functionality is not on the leaf switch? =20
>>>>> Where in the document do you think it would help to discuss this?
>>>>>
>>>>> Thank you,
>>>>> Joel
>>>>>
>>>>> On 5/13/2011 1:03 AM, david.black@emc.com wrote:
>>>>>> I am the assigned Gen-ART reviewer for this draft. For background=20
>>>>>> on Gen-ART, please see the FAQ at=20
>>>>>> .
>>>>>>
>>>>>> Please resolve these comments along with any other Last Call=20
>>>>>> comments you may receive.
>>>>>>
>>>>>> Document: draft-ietf-savi-threat-scope-05
>>>>>> Reviewer: David L. Black
>>>>>> Review Date: 12 May 2011
>>>>>> IETF LC End Date: 18 May 2011
>>>>>>
>>>>>> Summary: This draft is on the right track, but has open issues, desc=
ribed in the review.
>>>>>>
>>>>>> This draft discusses the threats and deployment environment for=20
>>>>>> IP source address validation with particular attention to=20
>>>>>> finer-grain validation that could be used within a network to=20
>>>>>> validate IP addresses closer to the sources of network traffic than =
ingress to an ISP's network.
>>>>>>
>>>>>> Major issues:
>>>>>>
>>>>>> There is no discussion of link teaming or aggregation (e.g., via=20
>>>>>> LACP); this may affect source address validation functionality by=20
>>>>>> requiring the same validation checks on all aggregated ports.  An=20
>>>>>> important case to discuss is where the aggregated host links are=20
>>>>>> connected to ports on different switches (e.g., in an active/passive=
 configuration).
>>>>>>
>>>>>> The discussion of multi-instance hosts in section 5.2.3 is=20
>>>>>> incomplete in several important aspects:
>>>>>>
>>>>>> (1) Some of the software switch implementations are single=20
>>>>>> instance switches whose implementation is distributed across=20
>>>>>> multiple physical servers.  This results in concerns similar to the =
link aggregation discussion above.
>>>>>>
>>>>>> (2) Live migration of virtual machines among physical servers=20
>>>>>> causes relocation of MAC addresses across switch ports.  A so-called=
 "gratuitous ARP"
>>>>>> is often used to inform the network of the MAC address move;=20
>>>>>> port-based source address validation information needs to move in re=
sponse to such ARPs.
>>>>>>
>>>>>> (3) MAC address relocation is also used as a failure recovery=20
>>>>>> technique; the surviving hardware element (e.g., host in a=20
>>>>>> cluster) takes over the MAC addresses of the failed hardware; like t=
he previous case, a "gratuitous ARP"
>>>>>> is a common means of informing the network that the MAC address=20
>>>>>> has moved, and source address validation information needs to move i=
n response to it.
>>>>>>
>>>>>> Minor issues:
>>>>>>
>>>>>> There doesn't seem to be much discussion of dynamic network=20
>>>>>> reconfiguration, which may change traffic egress points.  VRRP=20
>>>>>> may be a useful example to discuss beyond the typical routing protoc=
ol updates to forwarding tables.
>>>>>>
>>>>>> Nits/editorial comments:
>>>>>>
>>>>>> idnits 2.12.11 ran clean.
>>>>>>
>>>>>> Thanks,
>>>>>> --David
>>>>>> ----------------------------------------------------
>>>>>> David L. Black, Distinguished Engineer EMC Corporation, 176 South=20
>>>>>> St., Hopkinton, MA  01748
>>>>>> +1 (508) 293-7953             FAX: +1 (508) 293-7786
>>>>>> david.black@emc.com        Mobile: +1 (978) 394-7754
>>>>>> ----------------------------------------------------
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> savi mailing list
>>>>>> savi@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/savi
>>>>>>
>>>>
>>>>
>>
>>
> _______________________________________________
> savi mailing list
> savi@ietf.org
> https://www.ietf.org/mailman/listinfo/savi
>


From junbi@tsinghua.edu.cn  Mon Sep 26 10:50:35 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 2E17111E80D3 for ; Mon, 26 Sep 2011 10:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.803
X-Spam-Level: 
X-Spam-Status: No, score=-99.803 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495, 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 Up36IXJ47Z6w for ; Mon, 26 Sep 2011 10:50:34 -0700 (PDT)
Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by ietfa.amsl.com (Postfix) with ESMTP id 540E211E80CD for ; Mon, 26 Sep 2011 10:50:34 -0700 (PDT)
Received: from th024128.ip.tsinghua.edu.cn ([59.66.24.128] helo=junbiVAIOz138) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1R8FMg-0002lP-QD; Tue, 27 Sep 2011 01:53:14 +0800
Message-ID: 
From: "Jun Bi" 
To: "Jari Arkko" , "Jun Bi" , "SAVI Mailing List" 
References: <4DDC19D4.2040104@piuha.net> <4E7FE358.50509@piuha.net>
In-Reply-To: <4E7FE358.50509@piuha.net>
Date: Tue, 27 Sep 2011 01:53:17 +0800
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 15.4.3508.1109
X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3508.1109
Subject: Re: [savi] AD review of draft-ietf-savi-framework
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, 26 Sep 2011 17:50:35 -0000

Hi Jari,

I think we missed your comment is good and your text below is perfect.
Then how can we proceed now? (we replace the text and submit a new version?)

thanks,
Jun Bi

-----原始邮件----- 
From: Jari Arkko
Sent: Monday, September 26, 2011 10:28 AM
To: Jun Bi ; SAVI Mailing List
Subject: Re: [savi] AD review of draft-ietf-savi-framework

Jun,

I have reviewed the new version and it looks good, but I wonder if this 
suggested change was missed:

>> The reason to develop SAVI method variants for each single IP address
>> configuration method, in addition to the variant that handles all IP
>> address assignment methods, is to minimize the complexity of the
>> common case:  many link deployments today either are constrained to a
>> single IP address assignment methods or, equivalently from the
>> perspective of the SAVI method, separate IP address assignment
>> methods into different IP address prefixes.  The SAVI method for such
>> links can be simpler than the SAVI method for links with multiple IP
>> address assignment methods per IP address prefix.
>>
>
> Hmm. I'm not sure I buy this. First of all, I would claim that many
> links support multiple address assignment methods. For instance, dual
> stack links typically today support SLAAC for IPv6 and DHCP for IPv4.
> And its obvious that to fly in the IETF, the SAVI solution needs to
> support multiple methods. I would just replace the above text with:
>
> To provide a complete solution, SAVI methods need to support a variety
> of address configuration mechanisms. Of course there may be different
> SAVI specifications that specify, for instance SAVI functionality for
> IPv4 and IPv6 address configuration. It is expected that SAVI methods
> can collectively support DHCP [rfc2131,rfc3315], Stateless Address
> Autoconfiguration [rfc4862 ] with or
> without Secure Neighbor Discovery [rfc3971], IKEv2
> [rfc5996,rfc5739,rfc5026] and combinations thereof.

Or perhaps you disagreed with the change. In any case, I can't find a change 
in the new document or any discussion about this particular issue. Can you 
take a look?

Nevertheless, I have sent the document forward to a last call.

Jari

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