Subject: Re: [savi] 答复: About the failure situation mentioned by Marcelo

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 05 May 2009 10:42:15 +0200

Guang Yao escribió:
>
>   
>> However, there isn’t another “strict secure” anchor satisfying this 
>> requirement currently.
>>
>> Thus we have two directions here:
>>
>> 1 bindings are only set up for directly attached hosts, and the 
>> binding entries are used to “deny” the traffic from the legacy-SAVI 
>> port.(class A)
>>     
>
> i am not sure if a follow, what happens to the packets arriving through 
> the SAV legacy port? No filtering whatsoever is ever made, or a binding 
> is created using DAD packets or else?
>
> / *Guang:*/
> I mean, the bindings set up on SAVI-Host port are used to deny the traffic
> from SAVI-Legacy port.
> For example,
> Address A1, A2, A3 are bound on SAVI-Host port,
> Then traffic from SAVI-Legacy port is filtered on !A1 && ! A2 && !A3.
>
>
>   
So basically, if a host is connected through a non SAVI switch to a SAVI
device, its source address can be spoofed, by any other host, in
particular, by a host that is connected to a _different_ port of the
SAVI enabled device, is this correct?

>> 2 bindings are also set up for remote hosts without differences with 
>> directly attached hosts.(class B)
>>
>> Because of the situation mentioned by Marcelo above, SAVI device 
>> cannot rely on control packets only, and must use auxiliary protocols,
>>
>>     
>
> i am not sure why you bring the BDP or MLD protocol here. I mean, this 
> situation occurs when there is a single SAVI device so a BDP will not 
> help here. What can be done is to learn using data packets (instead of 
> discarding them)
>
> / *Guang:*/
> I'm not sure why you mean there is a single SAVI device here. There can be
> another SAVI device
> also connected to a same upstream device as this SAVI device.
>
>   
right, but my point is that the situation that i described, also occurs
in the case that you have a single SAVI device in the whole subnet. so i
am not sure why we need to consider the BDP to solve this, since it may
occur in a situaton where you don't have a second savi device

>> e.g., BDP or MLD.
>>
>> In this direction, the SAVI device doesn’t have to distinguish 
>> SAVI-Legacy port and SAVI-Host port. And the packets from the 
>> SAVI-Legacy port are filtered based on “allow” rules.
>>
>> However, I will try to make out two points here:
>>
>> (a) Set up bindings for remote hosts will not provide stronger 
>> security than using bindings from adjacent hosts to “deny” packets 
>> from remote hosts
>>
>>     
> i don't understand what you mean here
>
>   
>> For a class B device, there are only two kinds of addresses: bound 
>> addresses and unbound addresses.
>>
>> Whenever an address appears from a SAVI-Legacy port, and it has been 
>> bound on other ports, this packet will be dropped by both class A and 
>> class B device.
>>
>>     
> that is not obvious to me from the description you made of the class a above
>
>   
>> Whenever a new address appears from a SAVI-Legacy port, the class B 
>> SAVI cannot drop the packet but set up a new binding for the address, 
>> typically based on the principle “FCFS”.
>>
>>     
> right
>
>   
>> However, FCFS actually means using existing bindings to “deny” packets 
>> from SAVI-Legacy port, which is used by class A.
>>
>>     
> i don't understand what you mean here
>
> / *Guang:*/
> I mean, for example,
> Addresses A1, A2, A3... are bound on SAVI-Host port,
> And Address B1 appears on SAVI-Legacy port.
> If FCFS is used, if B1!= A1, A2, A3..., a new binding is set up for B1 and
> let pass B1.
> And in class A solution, if B1 != A1, A2, A3..., B1 is also let pass.
> Thus FCFS and class A have the same filtering ability.
>
>   

Not really,

Using your example above, in the FCFS case you decribe above, if a
packet with source address B1 is received through a different port, then
it is discarded. In the class A solution, the SAVI device will always
let packet with source address B1 pass. irrespectively from which legacy
port is received.

So, in FCFS, the set of hosts that can spoof address B1 is limited to
the set of hosts attached to the same lsavi port. While in the calss a
solution above any host can spoof address B1.

so, in FCFS source address connected to a SAVI switch through a legacy
device, they still obtain some protection while in the class a solution
you describe, they obtain none. so, no, the filtering capabilities are
not the same

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 06 May 2009 13:12:19 +0200

Guang Yao escribió:
> I don't think this is a reasonable hypothesis. Multiple SAVI devices is a
> more common situation.
>   

It is not an hypothesis that i am stating here. I am saying that the
problem occurs even in the case of a single SAVI device, so i am not
sure how this relates to an inter savi protocol.
> I fully agree that if two or more SAVI-Legacy ports exist on a SAVI switch,
> FCFS may have better performance.
>   
great!

> But please note that another failure may happen:
> Suppose two SAVI-Legacy ports L1, L2 exist on a SAVI device S, 
> A node B uses address B1, and its packets are forwarded by the legacy switch
> attached to L1. Unfortunately, all its traffics
> Are delivered to another node attaching to the legacy switch, without being
> forwarded to S. Thus you never bind B1 with L1.
> However, if another node uses B1 even after B is using B1, and its traffic
> are forwarded to S on port L2. Then you will bind B1 with L2.
> As a result, packets from B will be filtered by S, even it uses B1 first.
>
>   

So, the failure mode here requires that:
1- The DAD msg from the node A (The first one to use the source address
is lost)
2- Then, that A sends packets only addressed to nodes connected to the
same legacy switch
3- Then that node B autoconfigures the same address than node A
4- The, that the DAD msg of node B is lost (if not node A would defned
its address)
5- Then that node B does send a packet through the SAVI device.
In this case the node A who was the first to configure would be blocked
by the SAVI device.
I guess you realize that the probability of step 3 is incredibly low. In
addition, this occurs if the TWO DAD packets are also lost and the
traffic pattern is very specific.

(in particular, i quote again the probability of step 3

According to RFC4429, the probability of a colision if nodes select the
iid randomly (whcih is what DAD is aiming to prevent) is:
(different values for different number of nodes in the subnte, ranging
from 500 to 500000)
Pb(262, 500) <= 5.4e-14
Pb(262, 5000) <= 5.4e-12
Pb(262, 50000) <= 5.4e-10
Pb(262, 500000) <= 5.4e-08)

So, i don't think this as a failure mode is a real concern, but we may
disagree.

Regards, marcelo

> FCFS is not a good idea for remote nodes.
>
> If FCFS wants to avoid such bad filtering, it's better not distinguish
> SAVI-Legacy port from SAVI legacy port. Then, you can find that class A
> Still has same filtering ability as FCFS, in spite of far less memory cost.
>
>
>
>
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 14 May 2009 14:26:25 +0200

Guang Yao escribió:
>> A node B uses address B1, and its packets are forwarded by the legacy
>>     
> switch
>   
>> Are delivered to another node attaching to the legacy switch, without
>>     
> being
>   
> /*Guang*/
> See this situation you mentioned:
> +-------+
> |  HOST |
> +-------+
>     |
> +------------------+
> |    LEGACY SWITCH |
> +------------------+
>     |
> +------------------+
> |  SAVI CPS DEVICE |
> +------------------+
>     |
> +----------------+
> |  REST of WORLD |
> +----------------+
>
>
> You said SAVI device may reboot and lost previous bindings.
>
> Then the first few packets are not DAD, but data packets.
how come? Are you assuming DAD packets were lost?

>  If the data
> packets don't reach SAVI, not binding will be set up. Thus, a second user of
> an address may trigger a binding before the first one. Then FCFS will set up
> a wrong binding.
>   

this only happens if the set of events i have described below occurs,
and i made the point that the probability of that happenining is negligible.
> And I don't think it is a collision problem. Triggering the SAVI device to
> set up wrong binding is an attacking model against SAVI itself.
>
>
>   

I am kind of confused here.
In your previous email you stated: "But please note that another failure
may happen"
And then you described a failure. I addressed to you the events that
were needed to that failure to happen, and made the point that the
probability of that failure was negligible.
However, now you talk about an attack.

So are you talking about an attack or a failure?
If you are talking about an atack, please describe it in detail, cause
you have previously described a failure.

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 16 May 2009 22:56:14 +0200

Guang Yao escribió:
> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 marcelo
> bagnulo braun
> 发送时间: 2009年5月14日 20:26
> 收件人: Guang Yao
> 抄送: 'SAVI Mailing List'
> 主题: Re: [savi] 答复: 答复: 答复: About the failure situation mentioned by
> Marcelo
>
> Guang Yao escribió:
>   
>>> However, if another node uses B1 even after B is using B1, and its
>>>       
> traffic
>   
>> packets don't reach SAVI, not binding will be set up. Thus, a second user
>>     
> of
>   
>> an address may trigger a binding before the first one. Then FCFS will set
>>     
> up
>   
>> a wrong binding.
>>   
>>     
>
> It doesn't require that two DAD both are lost.
> If the SAVI device is turned on after the nodes attached to legacy switches
> are configured,
> FCFS will cause wrong binding.
>   

I am guessing we are making different set of assumptions here, cause i
fail to see how this could be the case

Regards, marcelo

> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi
>
>
>
>