Subject: [savi] RFC6620 Page 15 - Data Trigger

From: "Leaf Yeh" <[email-masked]>
Date: Tue, 6 May 2014 10:20:17 +0800

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 05 May 2014 23:01:32 -0400

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:
>        the Duplicate Address Detection process ... The DAD_NS messages
> are not
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi
>

---

From: "Leaf Yeh" <[email-masked]>
Date: Tue, 6 May 2014 11:54:41 +0800

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:[email-masked]] 
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:
> It seems the DAD_NS are not sent to 'any of VP', but sent to TP, after 
> If this data packet use the prefix assigned on this link, we don't 
> the SAVI (on-link) prefix list to filtering the 'transit traffic'. Right?
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 06 May 2014 10:01:49 -0400

I suspect I am misunderstanding you.

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?

You should also note that in the case of a multi-access LAN where SAVI 
is not being run on the individual ports which point to individual 
machines, and where there is not authentication, then there are 
significant limitations on the ability of SAVI to protect one claimant 
from another within that scope.  This is spelled out in the SAVI 
documents.  Sending solicitations back onto that LAN (which seems to be 
what you are asking for) does not actually help with that problem.

Yours,
Joel

---

From: "Leaf Yeh" <[email-masked]>
Date: Wed, 7 May 2014 11:21:55 +0800

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

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Tuesday, May 06, 2014 10:02 PM
To: Leaf Yeh; 'SAVI Mailing List'; 'marcelo bagnulo braun'; 'Eric Levy-
Abegnoli (elevyabe)'

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?

You should also note that in the case of a multi-access LAN where SAVI is
not being run on the individual ports which point to individual machines,
and where there is not authentication, then there are significant
limitations on the ability of SAVI to protect one claimant from another
within that scope.  This is spelled out in the SAVI documents.  Sending
solicitations back onto that LAN (which seems to be what you are asking for)
does not actually help with that problem.

Yours,
Joel

On 5/5/14, 11:54 PM, Leaf Yeh wrote:
> 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.
>
>
> 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
>
>
>
> To: Leaf Yeh; 'SAVI Mailing List'; 'marcelo bagnulo braun'; 'Eric 
> Levy- Abegnoli (elevyabe)'
> 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.
>>         the Duplicate Address Detection process ... The DAD_NS 
>> messages are not
>>
>> 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.
>>
>> 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?

---

From: "Leaf Yeh" <[email-masked]>
Date: Thu, 8 May 2014 10:08:34 +0800

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:[email-masked]] 
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
> 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
>
>