Re: [savi] RFC6620 Page 15 - Data Trigger

["Leaf Yeh" <[e-mail]>]

Joel - 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.)

Sending the DAD_NS intends to make sure the end device has initiated a
interface with the source address in the data packet sent out. 
Otherwise, the end device could spoof a lot of source address at no cost
within the same on-link prefix. The address space here is at least /64.


Best Regards,
Leaf



-----Original Message-----
From: Joel Halpern Direct [mailto:[e-mail]] 
Sent: Wednesday, May 07, 2014 10:31 PM
To: Leaf Yeh; 'Joel M. Halpern'; 'SAVI Mailing List'; 'marcelo bagnulo
braun'; 'Eric Levy- Abegnoli (elevyabe)'
Subject: Re: [savi] RFC6620 Page 15 - Data Trigger

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
>
>