Re: [savi] RFC6620 Page 15 - Data Trigger

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

Joel - The limits on the number of addresses a host can claim are related to
keeping the bookkeeping state bounded.  If a hsot causes his own claims to
be lost, that is his problem, not SAVI's.

I guess you mean the host can claim any number of addresses if SAVI device's
memory permits.


Joel - I am not sure what threat you are trying to prevent in your
description.
Leaf - > How about send DAD_NS to the VP received data packet for the 
> double-check in the above process?

I intend to prevent the host abuse the source address within the on-link
prefix. If SAVI device sent the DAD_NS directly back to the VP received the
data, it expected the host do have initiated that source address under test
as the target address, and response the DAD_NA.


Best Regards,
Leaf



-----Original Message-----
From: Joel M. Halpern [mailto:[e-mail]] 
Sent: Tuesday, May 06, 2014 11:02 AM
To: Leaf Yeh; 'SAVI Mailing List'; 'marcelo bagnulo braun'; 'Eric Levy-
Abegnoli (elevyabe)'
Subject: Re: [savi] RFC6620 Page 15 - Data Trigger

I am not sure what threat you are trying to prevent in your description.
The goal of the SAVI work was to prevent one host from claiming the address
another host is using.  The limits on the number of addresses a host can
claim are related to keeping the bookkeeping state bounded.  If a hsot
causes his own claims to be lost, that is his problem, not SAVI's.

Yours,
Joel

On 5/5/14, 10:20 PM, Leaf Yeh wrote:
> I read RFC6620 again, still have some questions on it.
>
> Section 3.2.3 Page 15 @ the state of NO_BIND
>
> <quote>
>
> Upon the reception through a Validating Port (VP) of a DATA packet
>
>        containing IPAddr as the source address, the SAVI device SHOULD
>
>        execute the process of sending Neighbor Solicitation messages 
> of
>
>        the Duplicate Address Detection process ... The DAD_NS messages 
> are not
>
>        sent through any of the ports configured as Validating Ports.  
> The
>
>        DAD_NSOL messages are sent through Trusted Ports (but, of 
> course,
>
>        subject to usual switch behavior and possible MLD snooping
>
>        optimizations)... The state
>
>        is moved to TENTATIVE.  The LIFETIME is set to TENT_LT (i.e., LT:
>
>        =TENT_LT), the BINDING ANCHOR is set to VP (i.e., P:=VP), and 
> the
>
>        Creation time is set to the current value of the local clock.
>
> </quote>
>
> It seems the DAD_NS are not sent to 'any of VP', but sent to TP, after 
> the VP received a data packet, whose source address are not in binding 
> table of the SAVI device.
>
> If this data packet use the prefix assigned on this link, we don't 
> expect the DAD_NA from the TP.
>
> If the data packet use any IID-interface ID, i.e. the 64 bits of the 
> source address, the SAVI switch will set up a binding entry for each 
> source address.
>
> Then I guess we lost the finer-grained SAV here, and only can rely on 
> the SAVI (on-link) prefix list to filtering the 'transit traffic'. Right?
>
> I mean the malicious host can create a huge number of **valid** source 
> address within the on-link prefix. What was the design philosophy here?
>
> How about send DAD_NS to the VP received data packet for the 
> double-check in the above process?
>
> Best Regards,
>
> Leaf
>
>
>
> _______________________________________________
> savi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/savi
>