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

From: "Guang Yao" <[email-masked]>
Date: Wed, 29 Apr 2009 09:36:20 +0800

Christian and Marcelo,

Sorry for my long absence from the discussion.

I will try to present my opinions on recent topics:

1 The situation mentioned by Marcelo

/* content from Marcelo's mail

In addition to that, there is the impact of failures.

Consider the following scenario that i have presented in a previous email:

+-------+

|  HOST |

+-------+

    |

+------------------+

|    LEGACY SWITCH |

+------------------+

    |

+------------------+

|  SAVI CPS DEVICE |

+------------------+

    |

+----------------+

|  REST of WORLD |

+----------------+

I understand this can be a very common configuration, for instance when the
SAVI function is located in the router rather than in the switch(this seems
to be the topology the broadband forum is looking into), or when you are
having an incremental deployment of SAVI and you have upgraded some switches
and not others

Suppose that the HOST boots and perform DAD.

The savi cps device creates state

everything is working fine

SAVI CPS device is rebooted (happens all the time at home for instance)

Now the SAVI CPS Data base is deleted and SAVI CPS starts dropping packets
from HOST, since HOST will not perform the DAD again

*/

The point of Marcelo is that the SAVI device may reboot and the binding
states are lost, which makes the SAVI device drops packets incorrectly.

This is good start point to discuss which hosts are to be administrated by
SAVI device.

As I mentioned in some previous mails, the only unspoofable anchors are 1
exclusive switch port, 2 secure MAC address in 802.1ae/af and 802.11i.
Unfortunately, they are only valid for directly attached hosts. This means,
if a host is not directly attached to SAVI device, its anchor is spoofable
and doesn't necessarily represent the host itself.

If we can find other anchors that can work on a device not directly
connected, things will be different. 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)

                   Then the situation mentioned by Marcelo can be handled.
The SAVI device doesn't have to set up bindings based on the traffic from
legacy switch and the traffic from legacy switch will not be filtered
incorrectly.

                   This solution has an advantage that the directly attached
host can be bound tightly with strong anchor.

                   The disadvantage of this solution is that the SAVI device
must distinguish SAVI-Legacy port and SAVI-Host port. Currently manual
configuration is the most proper mechanism, which bring administration cost.

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

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.

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

However, FCFS actually means using existing bindings to "deny" packets from
SAVI-Legacy port, which is used by class A.

And neither class A nor class B devices can distinguish spoofing from
unspoofing at the SAVI-Legacy port, for they share the same anchor.

Thus, class A and class B actually have the same filtering ability, which
means setting up bindings for remote hosts will not achieve better filtering
ability.

(b)     Class A controls spoofing from adjacent hosts better.

Whenever spoofing happens from adjacent hosts, class A device knows exactly
who is spoofing. This is a good feature for management.

However, class B device only knows spoofing happens, but it doesn't know
whether the spoofing happens locally or remotely.

And setting up bindings for remote hosts costs a lot of memory. Actually,
the memory cost will be a big problem in a big network. Class B also needs
additional protocol.

Another point is, the feature of the traffic from SAVI-Legacy port is much
different from that from SAVI-host port. Thus it is reasonable to
distinguish different kinds of ports.

The summary of above argument is, class A is better than class B, which
means " bindings are only set up for directly attached hosts, and the
binding entries are used to "deny" the traffic from the legacy-SAVI port."

Best regards,

Guang

--

Guang Yao

Network Research Center

Tsinghua University

Beijing, China

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 30 Apr 2009 15:38:44 +0200

Guang Yao escribió:
> /* content from Marcelo’s mail
>
> I understand this can be a very common configuration, for instance 
> when the SAVI function is located in the router rather than in the 
> switch(this seems to be the topology the broadband forum is looking 
> into), or when you are having an incremental deployment of SAVI and 
> you have upgraded some switches and not others
>
> Now the SAVI CPS Data base is deleted and SAVI CPS starts dropping 
> packets from HOST, since HOST will not perform the DAD again
>
> */
>
> The point of Marcelo is that the SAVI device may reboot and the 
> binding states are lost, which makes the SAVI device drops packets 
> incorrectly.
>
> This is good start point to discuss which hosts are to be 
> administrated by SAVI device.
>
> As I mentioned in some previous mails, the only unspoofable anchors 
> are 1 exclusive switch port, 2 secure MAC address in 802.1ae/af and 
> 802.11i. Unfortunately, they are only valid for directly attached 
> hosts. This means, if a host is not directly attached to SAVI device, 
> its anchor is spoofable and doesn’t necessarily represent the host itself.
>
> connected, things will be different.
>
well, we have SEND SAVI, but it has other limitiations i.e. requre send 
deplyment, so we can leave out of this particular disucssion

> However, there isn’t another “strict secure” anchor satisfying this 
> requirement currently.
>
> 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)
>
> Then the situation mentioned by Marcelo can be handled. The SAVI 
> device doesn’t have to set up bindings based on the traffic from 
> This solution has an advantage that the directly attached host can be 
> bound tightly with strong anchor.
>
> The disadvantage of this solution is that the SAVI device must 
> distinguish SAVI-Legacy port and SAVI-Host port. Currently manual 

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

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

> unspoofing at the SAVI-Legacy port, for they share the same anchor.
Would a class A solution you describe above coud be able to distinguish 
when an address used in port 1 connected to a legacy siwthc is next used 
to port 2 which is also connected to a legacy switch?

> Thus, class A and class B actually have the same filtering ability, 
> which means setting up bindings for remote hosts will not achieve 
> better filtering ability.
>
I don't understnad this conclusion, I don't thionk the filtering 
capability is the same

> Whenever spoofing happens from adjacent hosts, class A device knows 
> exactly who is spoofing.This is a good feature for management.
>
> However, class B device only knows spoofing happens, but it doesn’t 
> know whether the spoofing happens locally or remotely.
>

i don't understnad what do you mean by this.
Using the state in the savi binding, a class b can track down the 
address to a port where either a host or a legacy switch is directly 
connected.

> And setting up bindings for remote hosts costs a lot of memory. 
> Actually, the memory cost will be a big problem in a big network. 
> Class B also needs additional protocol.
>
> Another point is, the feature of the traffic from SAVI-Legacy port is 
> much different from that from SAVI-host port. Thus it is reasonable to 
mmm, i don't see why is this reasonable,

> The summary of above argument is, class A is better than class B, 
> which means “ bindings are only set up for directly attached hosts, 
> and the binding entries are used to “deny” the traffic from the 
> legacy-SAVI port.”
>

i still don't very clear about how the class A solution work, so i am nt 
sure i agree with the statement

Regards, marcelo