Subject: [savi] SAVI Bindings For Hosts Behind Legacy Switches?

From: Christian Vogt <[email-masked]>
Date: Wed, 20 May 2009 13:29:00 -0700

Forked from thread:  "About the failure situation mentioned by Marcelo".

Marcelo, Guang, and all -

Thanks for your discussion on whether SAVI bindings should be created
only for directly attached hosts, or also for hosts attached via legacy
switches.  This discussion was extremely useful.  Let me summarize a few
conclusions from it.

You have identified two classes of SAVI solutions:

- Class A, in which SAVI devices create bindings only for hosts that are
   directly attached.

- Class B, in which SAVI devices create bindings also for host that are
   attached via one or more legacy switches.

FWIW, on a personal note, I think that both of these solution classes
are FCFS, they are just different variants of it.  The variants have
important differences, for sure, but they both follow the FCFS model.
After all, they only affect which hosts are to be protected, not how the
hosts are protected.

Given the restrictions set forth by our charter, neither of the above
two classes of SAVI solutions can be a silver bullet, of course.  Both
models have their limitations, as your discussions has shown:

- Class A provides a lower level of protection because the addresses of
   hosts behind a legacy switch are not protected against spoofing.
   This defeats the purpose of SAVI in deployment scenarios where all
   hosts are separated from the SAVI device through a legacy switch. An
   example where this may be the case is DSL networks, where SAVI may
   be performed on a provider-side device, and all hosts attach to this
   SAVI device via a legacy switch on the customer side.

- Class A requires extra manual configuration of SAVI devices in terms
   of which binding anchors are to be protected, and which are not.

- Class B may, in specific cases, introduce a higher vulnerability to
   denial of service than class A:  In general, a vulnerability to
   denial of service exists if an attacker (a) finds out about the
   address of a victim host, and (b) is in a position to trick a SAVI
   device into creating a fake binding for the victim host's address,
   using a binding anchor other than the one the victim host would use.
   This would cause the SAVI device to prevent the victim host from
   using its own address.

   A situation where this vulnerability may occur is where a SAVI device
   does not receive the first packet sent by the victim host, but the
   attacker does.  The SAVI device then does not create a binding for  
the
   victim host, potentially enabling the attacker to create a fake
   binding on behalf of the victim host.  The presence of a legacy  
switch
   between the SAVI device on one side, and the victim host and the
   attacker on the other side, increases the chance that this situation
   occurs for two reasons:  First, because the probability for loss is
   higher for packets that have to traverse a legacy switch to reach the
   SAVI device.  Second, because the legacy switch may deliberately not
   forward a packet to the SAVI device if the destination is known not  
to
   be reachable via the SAVI device. In such a situation, class B would
   enable the attacker to create a fake binding on behalf of the victim
   host, whereas class A does not.

- Class B may potentially requires more memory per SAVI device than
   class A.  SAVI devices need to maintain bindings not only for
   directly attached hosts, but also for hosts behind legacy switches.

Given that both classes of SAVI solutions have strengths and weaknesses
relative to each other, we may consider giving the network administrator
the possibility to choose.  All that would be needed for this is a
capability of SAVI devices to en- or disable protection of specific
binding anchors.  Protection being enabled for all binding anchors would
thus represent a SAVI solution of class A, while disabling protection
for binding anchors associated with legacy switches would represent a
SAVI solution of class B.  The important question is what the default
should be.  We should discuss this question.

- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 21 May 2009 19:16:05 +0200

Christian,

Christian Vogt escribió:
>   attacker does.
and also the attacker knows that the savi device has not received the packet
I mean, i really think this attack as you described, it hardly an 
attack. I mean, are you suggesting that the attacker will wait to launch 
an attack until it finds a node that connects to the network, sends it 
first packet, the packet is not received by the savi device so it can 
send the first packet to trick the savi device?
I am not sure how effective would be such an attack. The attacker needs 
to wait there till all the conditions hold to manage to block the node.
I don't think this is a serious issue.

>   The SAVI device then does not create a binding for the
>   binding on behalf of the victim host.  The presence of a legacy switch
>   forward a packet to the SAVI device if the destination is known not to
>   be reachable via the SAVI device. 
mmm, it is more complex that that.
the first packet is expected to be the NADV for DAD, whcih is tracked by 
the SAVI device and is used to create a binding
So, the situation is that the DAD addressed to the sol node mcast group 
is not forwared. That requires at least that the L2 multicast is 
implemented (i.e. it is not mapped to the bradcast) and that there is no 
node of the same sol node mcast group in other ports of the savi device.

> In such a situation, class B would
sure, the scope of protection is proportional to the memory required. 
Similarly, you can reduce the memory required by limiting the number of 
bindings you have. Of course it imply less protection.
So, this is not related about class A or Class B, but to the fact that 
if you want to have n bindings, you need n times the memory requried for 
a binding.

Regards, marcelo

---

From: Christian Vogt <[email-masked]>
Date: Thu, 21 May 2009 10:52:27 -0700

Marcelo -

> and also the attacker knows that the savi device has not received the
> packet I mean, i really think this attack as you described, it  
> hardly an
> send the first packet to trick the savi device? I am not sure how
> effective would be such an attack. The attacker needs to wait there  
> till
> all the conditions hold to manage to block the node. I don't think  
> this
> is a serious issue.

True.

>> The SAVI device then does not create a binding for the victim host,
>> potentially enabling the attacker to create a fake binding on  
>> behalf of
>> the victim host.  The presence of a legacy switch between the SAVI
>> device on one side, and the victim host and the attacker on the other
>> side, increases the chance that this situation occurs for two  
>> reasons:
>> First, because the probability for loss is higher for packets that  
>> have
>> to traverse a legacy switch to reach the SAVI device.  Second,  
>> because
>> the legacy switch may deliberately not forward a packet to the SAVI
>> device if the destination is known not to be reachable via the SAVI
>> device.
>
> mmm, it is more complex that that. the first packet is expected to be
> the NADV for DAD, whcih is tracked by the SAVI device and is used to
> create a binding So, the situation is that the DAD addressed to the  
> sol
> node mcast group is not forwared. That requires at least that the L2
> multicast is implemented (i.e. it is not mapped to the bradcast) and
> that there is no node of the same sol node mcast group in other  
> ports of
> the savi device.

Right, the legacy switch would have to be an MLD-snooping switch.
Otherwise, the switch would forward the DAD Neighbor Solicitation to all
of its ports, hence also always to the SAVI device.  This is why I said
"the legacy switch /may/ not forward a packet to the SAVI device"
because in many cases it will.

> bindings you have. Of course it imply less protection. So, this is not
> related about class A or Class B, but to the fact that if you want to
> have n bindings, you need n times the memory requried for a binding.

What is relevant here is whether we endow SAVI devices with a capability
to disable protection of certain binding anchors (typically switch
ports).  This determines whether a SAVI device can rely on a different
SAVI device to handle some of its binding anchors, and hence to refrain
from establishing bindings for that anchor.  Without such a capability,
multiple SAVI devices may end up creating the same binding.

According to Guang's definition of class A and class B, the capability
to disable protection of certain binding anchors exists only for class
A.  Therefore, this /is/ related to Guang's classification.
Nevertheless, there is nothing that would prevent adding the same
capability to FCFS, which we are currently associating with class B.
And I think this would make sense because it helps reducing memory
requirements for SAVI devices.  Do you agree?

- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 21 May 2009 20:00:43 +0200

Christian Vogt escribió:
>> packet I mean, i really think this attack as you described, it hardly an
>> effective would be such an attack. The attacker needs to wait there till
>> all the conditions hold to manage to block the node. I don't think this
>> is a serious issue.
>
> True.
>
>>> potentially enabling the attacker to create a fake binding on behalf of
>>> side, increases the chance that this situation occurs for two reasons:
>>> First, because the probability for loss is higher for packets that have
>>> to traverse a legacy switch to reach the SAVI device.  Second, because
>> create a binding So, the situation is that the DAD addressed to the sol
>> that there is no node of the same sol node mcast group in other ports of
>> the savi device.
>

sure, disabling SAVI on a per port basis seems a reasonable feature to 
have in general. Seems a matter of local policy though
Moreover i would expect that by default switches will have savi off in 
all ports and that savi capability needs to be turn on explicitly in the 
device, and it maybe on for some ports and not for others.
This is beyond the issue of memory consumption i guess.  But again, this 
a matter of the swithc vendor and the local policy imho
regards, marcelo

---

From: Christian Vogt <[email-masked]>
Date: Thu, 21 May 2009 11:17:56 -0700

> have in general. Seems a matter of local policy though Moreover i  
> would
> expect that by default switches will have savi off in all ports and  
> that
> savi capability needs to be turn on explicitly in the device, and it
> maybe on for some ports and not for others. This is beyond the issue  
> of
> memory consumption i guess.  But again, this a matter of the swithc
> vendor and the local policy imho

Yes, this is a good way of looking at it.  At the same time, the
capability to disable protection of certain binding anchors was the key
difference between Guang's class A and class B.

My conclusion is hence that we have found consensus here to add this
capability to our SAVI solution, and that we can close this issue.  (In
fact, some of us were discussing such a capability earlier, and the
conclusion already then was that this would be a good idea.  The
capability just wasn't added to the SAVI solution yet.)

If somebody thinks there is more to be discussed, please speak up.

- Christian

---

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

Christian Vogt escribió:
>> have in general. Seems a matter of local policy though Moreover i would
>> expect that by default switches will have savi off in all ports and that
>> maybe on for some ports and not for others. This is beyond the issue of

mmm, i understood that the main difference was that bindins were created 
based only in DAD packets (class A) or were  created by  DAD and data 
packts (class B), and that class A was by defualt dropping packets 
(unless a binding existed) while class B was by default creating a 
binding (if the binding did not exist)

Class A also required to configure which ports were connected to legacy 
devices to work prperly

What we are agreeing here is that it would be reaosnable to allow savi 
to be disable for a set of ports, but this is not same to impose 
configuration of which ports are savi and which are not, based on what 
is connected to them in order to make the solution work.

Having the capability of disabling SAVI on a per ports issues is a 
feature. Requiring to do so when a legacy device is connect to it, is a 
burden

Just to clarify

Regards, marcelo

---

From: Christian Vogt <[email-masked]>
Date: Thu, 21 May 2009 12:21:51 -0700

Marcelo -

> binding (if the binding did not exist)

Guang's definition of classes A and B did not cover which packet types
to use for binding creation.  It only covered for which binding anchors
to create bindings.

This said, our discussion did, partly, touch both of these aspects,
leading to an association of class A with CPS and of class B with FCFS.
But I think the discussion of CPS vs. FCFS should be separate.

> to be disable for a set of ports [...]

Yes.

> [...] but this is not same to impose configuration of which ports are
> savi and which are not, based on what is connected to them in order to
> make the solution work.

Absolutely.

- Christian

---

From: "Guang Yao" <[email-masked]>
Date: Sun, 31 May 2009 16:03:03 +0800

-----Original Message-----
From: Christian Vogt [mailto:[email-masked]] 
Sent: Thursday, May 21, 2009 4:29 AM
To: Marcelo Bagnulo Braun; Guang Yao; SAVI Mailing List
Subject: SAVI Bindings For Hosts Behind Legacy Switches?

IMO, both solution classes are also working for CPS. They can be discussed
without regarding whether FCFS or CPS or something else is chosen.

Exactly!
And I want to give two of my points here:
1 FCFS
I think there are at least 3 kinds of FCFS:
(1) FCFS to the routing system
(2) FCFS to the SAVI system
(3) FCFS to a SAVI device

Only (1) is reasonable to trigger a new binding. However, in FCFS draft,
(3) is taken as (1). This defect of class B is actually due to (3) is not
equal to (1), 
especially for indirect connected hosts. If hosts are direct connected to
SAVI device,
(1) can be inferred from (3). This is the reason why I prefer class A than
class B. The
same thing also happens on CPS.

And as I mentioned in previous mails, even with a perfect BDP, FCFS is still
not
reasonable to set up legal bindings, because (3) cannot be inferred from
(2). However,
for CPS, (1) can be inferred from CPS.

There is actually no difference between FCFS and CPS on the basic idea: who
uses it first, and who gets it.
The real difference is, which is real FCFS, and which just looks like
"FCFS".

I think the memory cost problem is an important problem. I have discussed
with some switch vendors,
and they told me it is very hard for an access device to set up a filtering
table for potentially thousands of hosts

- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 31 May 2009 12:38:20 +0200

>    host, whereas class A does not.
I am kind of confused with the format of the reply, since it is hard to 
distinguish the original text from Christian and Guang's reply, but, i 
understnad that the text below is Guang's reply....

> (1) FCFS to the routing system
I don't understnad what do you mean by FCFS to the routing system, do 
you mean the case the SAVI device is colocated with a router?

> (3) FCFS to a SAVI device
I fail to see the difference between these two... do you mean 2) is the 
case you have multiple SAVI devices and 3) being the case where you have 
only one SAVI device?

> for CPS, (1) can be inferred from CPS.
I cannot comment on this since i don't understand the definitions of 1,2 
and 3

> uses it first, and who gets it.
i agree with this

> The real difference is, which is real FCFS, and which just looks like
no, the difference is what is the default action when the device 
receives a data packet for which it doesn't have a binding, to learn or 
to discard

> table for potentially thousands of hosts

I disagree that the memory requirements are different
both FCFS and CPS learn based on DAD packets (FCFS also learns in the 
case of data packets)
In general, hosts will issue the DAD and as i understand both CPS and 
FCFS will generate a binding based on the DAD packet, is this correct 
for CPS?
If so, then i argue that the amount of memory is very similar in both 
cases. I mean, the need to use data packets to create binding is deal 
with those cases where the DAD is lost or not issued after a change in 
the topology, which will not change significantly the amount of memory 
needed

Regards, marcelo

---

From: "Guang Yao" <[email-masked]>
Date: Sun, 31 May 2009 21:51:29 +0800

> From: marcelo bagnulo braun [mailto:[email-masked]]
> Sent: Sunday, May 31, 2009 6:38 PM
> To: Guang Yao
> Cc: 'Christian Vogt'; 'SAVI Mailing List'
> Subject: Re: SAVI Bindings For Hosts Behind Legacy Switches?
> 
> Guang Yao escribió:

Sorry for confusing. 
> case you have multiple SAVI devices and 3) being the case where you have

(1) means the address is first ever appearing on the current routing system,
including all the network device.
(2) means the address is first ever appearing on one of all the SAVI
devices.
> receives a data packet for which it doesn't have a binding, to learn or

I think the inner difference is which is real FCFS.

> the topology, which will not change significantly the amount of memory

Here we just discuss that class B requires more memory than class A, not
CPS and FCFS.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 31 May 2009 16:10:37 +0200

Guang Yao escribió:
>>> switches.  This discussion was extremely useful.  Let me summarize a
>>>       
>> few
>>     
>>> conclusions from it.
>>>
>>> IMO, both solution classes are also working for CPS. They can be
>>>       
> discussed
>   

I fail to see how is this relevant. I mean, the savi device can only 
create binding when the savi device sees the packet. How is it relevant 
when the address is first ever appearing in the routing system, or any 
other netowrk device if the device is not savi capable?

regards, marcelo

>>> (3) is taken as (1). This defect of class B is actually due to (3) is
>>>       
> not
>   
>>> equal to (1),
>>> especially for indirect connected hosts. If hosts are direct connected
>>>       
> to
>   
>>> SAVI device,
>>> (1) can be inferred from (3). This is the reason why I prefer class A
>>>       
> than
>   
>>> class B. The
>>> And as I mentioned in previous mails, even with a perfect BDP, FCFS is
>>>       
> still
>   
>>> not
>>> There is actually no difference between FCFS and CPS on the basic idea:
>>>       
>> who
>>     
>>> I think the memory cost problem is an important problem. I have
>>>       
> discussed
>   
>>> and they told me it is very hard for an access device to set up a
>>>       
> filtering
>

---

From: "Guang Yao" <[email-masked]>
Date: Sun, 31 May 2009 22:51:56 +0800

> Sent: Sunday, May 31, 2009 10:11 PM
> To: Guang Yao

Sure, only after the packet appears on a savi device, the savi device can
know which address will be bound.
But before binding, it must decide whether to bind and which to bind with.
If an address is first ever appearing on all the savi devices, is it
reasonable to bind it with the anchor it appears with?
I don't think so. A host may be the second to use that address in the
routing system, but fortunately, it appears first on the savi device.
That's what I mean, "FCFS to the savi system" doesn't necessarily mean "FCFS
to the routing system".
Protection should be provide to the entity who uses an address first in a
routing system, but not the entity who first forwards the packet to the savi
system.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 31 May 2009 17:03:03 +0200

Guang Yao escribió:
>>>>> Forked from thread:  "About the failure situation mentioned by
>>>>>           
>> Marcelo".
>>     
>>>>> only for directly attached hosts, or also for hosts attached via
>>>>>           
> legacy
>   
>>>>> - Class A, in which SAVI devices create bindings only for hosts that
>>>>>           
> are
>   
>>>>>    directly attached.
>>>>>
>>>>> - Class B, in which SAVI devices create bindings also for host that
>>>>>           
> are
>   
>>>>> After all, they only affect which hosts are to be protected, not how
>>>>>           
> the
>   
>>>>> hosts are protected.
>>>>>
>>>>> - Class A provides a lower level of protection because the addresses
>>>>>           
> of
>   
>>>>>    hosts are separated from the SAVI device through a legacy switch.
>>>>>           
>> An
>>     
>>>>>    example where this may be the case is DSL networks, where SAVI
>>>>>           
>> may
>>     
>>>>>    be performed on a provider-side device, and all hosts attach to
>>>>>           
> this
>   
>>>>>    using a binding anchor other than the one the victim host would
>>>>>           
>> use.
>>     
>>>>>    A situation where this vulnerability may occur is where a SAVI
>>>>>           
> device
>   
>>>>>    attacker on the other side, increases the chance that this
>>>>>           
> situation
>   
>>>>>    higher for packets that have to traverse a legacy switch to reach
>>>>>           
> the
>   
>>>>>    SAVI device.  Second, because the legacy switch may deliberately
>>>>>           
>> not
>>     
>>>>>    be reachable via the SAVI device. In such a situation, class B
>>>>>           
> would
>   
>>>>>    enable the attacker to create a fake binding on behalf of the
>>>>>           
> victim
>   
>>>> case you have multiple SAVI devices and 3) being the case where you
>>>>         
> have
>   
>>>> only one SAVI device?
>>>>
>>>>         
>>> (1) means the address is first ever appearing on the current routing
>>>       
> system,
>   
i understnad now
I agree that would be the ideal case, indeed.
I am not sure we can actually achieve that in the general case though 
and i am not yet convinced the corner cases are a problem.

I mean, we do have a set of border constraints that make the savi 
solution to have some limitiations so, i am not sure we will be able to 
achieve the ideal case w.r.t. this

Regards, marcelo

>>     
>>>>> Only (1) is reasonable to trigger a new binding. However, in FCFS
>>>>>           
> draft,
>   
>>>>> reasonable to set up legal bindings, because (3) cannot be inferred
>>>>>           
> from
>   
>>>>> (2). However,
>>>> I cannot comment on this since i don't understand the definitions of
>>>>         
> 1,2
>   
>>>> and 3
>>>>
>>>>
>>>>         
>>>>> There is actually no difference between FCFS and CPS on the basic
>>>>>           
> idea:
>   
>>>> who
>>>>
>>>>         
>>>>> Given that both classes of SAVI solutions have strengths and
>>>>>           
> weaknesses
>   
>>>>> relative to each other, we may consider giving the network
>>>>>           
>> administrator
>>     
>>>>> binding anchors.  Protection being enabled for all binding anchors
>>>>>           
>> would
>>

---

From: Christian Vogt <[email-masked]>
Date: Sun, 31 May 2009 15:37:24 -0700

On May 31, 2009, Marcelo Bagnulo Braun wrote:

>> discussed with some switch vendors, and they told me it is very  
>> hard for
>> an access device to set up a filtering table for potentially  
>> thousands
>> of hosts
>
> I disagree that the memory requirements are different both FCFS and  
> CPS
> learn based on DAD packets (FCFS also learns in the case of data
> packets) In general, hosts will issue the DAD and as i understand both
> CPS and FCFS will generate a binding based on the DAD packet, is this
> correct for CPS? If so, then i argue that the amount of memory is very
> similar in both cases. I mean, the need to use data packets to create
> binding is deal with those cases where the DAD is lost or not issued
> after a change in the topology, which will not change significantly  
> the
> amount of memory needed

There is one reason why CPS requires less state than FCFS, as the
protocols are defined /currently/:  CPS calls for SAVI devices to create
bindings only for directly attached hosts, not for hosts attached via
another switch.  This is based on the assumption that the ports of SAVI
devices are configured with respect to whether they connect to a host
directly, or whether they connect to another switch.  For ports
connecting to another switch, SAVI protection is disabled.

However, the same trick that CPS uses to reduce state can be applied to
FCFS.  All it requires is adding an option to disable SAVI protection
for certain ports.  Such an option would be useful anyhow, as Marcelo
stated earlier.  And I would encourage Marcelo to add this feature to
the FCFS specification.

Given that the option to disable SAVI protection for certain ports is
not really CPS-specific, I had refrained from comparing CPS and FCFS in
my original email in this thread.  Instead, I wrote the email in terms
of a SAVI device's behavior for ports connecting to another switch.
Later, the discussion flipped back to comparing CPS and FCFS, but this
was not the original intention.

- Christian