Re: [savi] RFC6620 Page 15 - Data Trigger
Joel Halpern Direct <jmh.direct@joelhalpern.com> Wed, 07 May 2014 14:30 UTC
Return-Path: <jmh.direct@joelhalpern.com>
X-Original-To: savi@ietfa.amsl.com
Delivered-To: savi@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 1BED91A077E
for <savi@ietfa.amsl.com>; Wed, 7 May 2014 07:30:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44])
by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id JhI1NskiiGzD for <savi@ietfa.amsl.com>;
Wed, 7 May 2014 07:30:53 -0700 (PDT)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156])
by ietfa.amsl.com (Postfix) with ESMTP id DF6C11A0779
for <savi@ietf.org>; Wed, 7 May 2014 07:30:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
by mailc2.tigertech.net (Postfix) with ESMTP id 0E2A72199C;
Wed, 7 May 2014 07:30:50 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net
Received: from Joels-MacBook-Pro.local (unknown [190.112.55.105])
(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
by mailc2.tigertech.net (Postfix) with ESMTPSA id 2EE6721998;
Wed, 7 May 2014 07:30:49 -0700 (PDT)
Message-ID: <536A4398.6070102@joelhalpern.com>
From: Joel Halpern Direct <jmh.direct@joelhalpern.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Leaf Yeh <leaf.yeh.sdo@gmail.com>,
"'Joel M. Halpern'" <jmh@joelhalpern.com>,
'SAVI Mailing List' <savi@ietf.org>,
'marcelo bagnulo braun' <marcelo@it.uc3m.es>,
"'Eric Levy- Abegnoli (elevyabe)'" <elevyabe@cisco.com>
References: <536846e7.637a420a.27dc.02df@mx.google.com>
<5368508C.9060205@joelhalpern.com>
<53685d07.8564420a.3494.3c0a@mx.google.com>
<5368EB4D.7000704@joelhalpern.com>
<5369a6d9.838f440a.7e55.1450@mx.google.com>
In-Reply-To: <5369a6d9.838f440a.7e55.1450@mx.google.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/savi/jHNg_BhtM4Mybw8en6VX1ioaj6k
X-Mailman-Approved-At: Thu, 17 Jul 2014 08:43:14 -0700
Subject: Re: [savi] RFC6620 Page 15 - Data Trigger
X-BeenThere: savi@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mailing list for the SAVI working group at IETF <savi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/savi>,
<mailto:savi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/savi/>
List-Post: <mailto:savi@ietf.org>
List-Help: <mailto:savi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/savi>,
<mailto:savi-request@ietf.org?subject=subscribe>
Date: Wed, 07 May 2014 14:30:55 -0000
X-Original-Date: Wed, 07 May 2014 10:30:48 -0400
X-List-Received-Date: Wed, 07 May 2014 14:30:55 -0000
With regard to protecting hosts from "on-link" attackers, there are two different cases. If the SAVI function is on the device with a dedicated port to the end device (or an authenticated port) then there is no value in sending the NS back to the entity which sent it. (Some of this is conceptually buried in the definition of binding scopes in SAVI, and can be hard to realize.) In the case where the SAVI function is upstream of the usage port (for example, it is on the router port, with bridges / switches between the prot and the users) there are many weaknesses in SAVI efficacy. That is clearly stated in the documents. Sending the NS back on that port will not as far as I can tell help resolve much, if any, of those weaknesses. We did discuss this extensively in the working group. Yours, Joel On 5/6/14, 11:21 PM, Leaf Yeh wrote: > Joel - The goal of SAVI is very specific. it is to prevent one node from > claiming an address that is belongs to (by assignment or proper > claiming) another node. Can you please restate your concern with the data > trigger in terms of how it fails to meet that goal?.... > Sending solicitations back onto that LAN (which seems to be what you are > asking for) does not actually help with that problem. > > I guess your logic sounds right. DAD_NS should sent through the TP, which > may connect to other SAVI device (and more hosts) within the same scope, > i.e. the same link, or the same broadcast domain. But the above logic sounds > not cover my concern on the host to abuse the source address within the > on-link prefix. > > Sending DAD_NS back to the VP receiving the data trigger, sounds useful for > a check. Wrong or harmful? > > > Best Regards, > Leaf > >
- [savi] RFC6620 Page 15 - Data Trigger Leaf Yeh
- Re: [savi] RFC6620 Page 15 - Data Trigger Joel M. Halpern
- Re: [savi] RFC6620 Page 15 - Data Trigger Leaf Yeh
- Re: [savi] RFC6620 Page 15 - Data Trigger Joel M. Halpern
- Re: [savi] RFC6620 Page 15 - Data Trigger Leaf Yeh
- Re: [savi] RFC6620 Page 15 - Data Trigger Leaf Yeh
- Re: [savi] RFC6620 Page 15 - Data Trigger Joel Halpern Direct