Subject: [savi] Your Vote: Incremental SAVI Deployment

From: Christian Vogt <[email-masked]>
Date: Sat, 11 Apr 2009 20:22:34 -0700

Folks -

At the SAVI meeting in San Francisco, we talked about the incremental
deployment of SAVI.  One question on this topic was whether we want SAVI
devices to function in the presence of legacy switches on the same link.
More specifically, we pondered whether we want SAVI to support arbitrary
interconnections of SAVI devices and legacy switches on the same link.
We voted on this question and the result was in favor of supporting such
arbitrary interconnections.  I would now like to confirm this vote on
this mailing list.

Should SAVI support links with arbitrary interconnections of SAVI
devices and legacy switches?  Please choose one of the following:

(1) Yes, arbitrary interconnections of SAVI devices and legacy switches
     should be supported.

(2) No, it is fine for SAVI to restrict how SAVI devices and legacy
     switches are interconnected.

In case you vote for option (2), please describe briefly how you think
said restriction should look like, and why you think this would be
useful.

Please vote by Sunday, April 19, 2009.

- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 12 Apr 2009 12:10:05 +0200

Hi,

I think the question here is what it means to be supported.
Does this mean that the resulting security must be the same than if all 
the devices are SAVI devices? I guess not. So what level of security 
degradation is acceptable? I think this was not very clearly stated 
during the discussion in the meeting.
I think that it is not very hard to support arbitrary mixes of savi and 
non savi devices as long we accept a security level degradation. We may 
want to quantify this. Basically, the impact is that you can track the 
spoofer up to the link rather than up to the actual host if the link 
contains a non savi device.

The other interesting question is whether imposing some restrictions in 
the ways savi and non savi devices are interconnected would render some 
problems easy to deal with. For instance, would this make easier to 
secure the SAVI protocol? I don't feel i can answer to this question 
right now, but for me is important to keep in mind that the ways the 
savi devices and non savi devices are interconnected is another variable 
we can play with if we need to solve a hard problem.

Regards, marcelo

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

---

From: Christian Vogt <[email-masked]>
Date: Sun, 12 Apr 2009 15:29:55 -0700

Marcelo -

"Support for arbitrary interconnections of SAVI devices and legacy
switches" is here meant as a robustness property:  Does a SAVI device
run havoc if it encounters a legacy switch on its link?  Does it produce
false positives?  Does the binding distribution/verification protocol,
if any, work across legacy switches?  You are right that there may be
security degradations on links with both types of switches.  It would be
unwise to assume that a link with legacy switches could be equally
secured as a link where all switches are SAVI-capable.

Personally, I like your idea of leaving us some flexibility with respect
to possible link topology restrictions.  We might find later that such
restrictions can help us in the design of SAVI.  At this stage, it is
hard to tell whether restrictions could be useful, and if so, which type
of restrictions.  If you think we should leave us this flexibility,
please vote for option (2).  This doesn't mean that we shouldn't try to
avoid any restrictions.  But it means that we could live with them if we
find that they are really useful.

- Christian

On Apr 12, 2009, at 3:10, marcelo bagnulo braun wrote:

> Hi,
>
> I think the question here is what it means to be supported. Does this
> mean that the resulting security must be the same than if all the
> devices are SAVI devices? I guess not. So what level of security
> during the discussion in the meeting. I think that it is not very hard
> to support arbitrary mixes of savi and non savi devices as long we
> accept a security level degradation. We may want to quantify this.
> Basically, the impact is that you can track the spoofer up to the link
> rather than up to the actual host if the link contains a non savi
> device.
>

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 14 Apr 2009 00:01:08 +0800

Hi All,

I vote (1).

Reason: certainly the operator should consider the incremental deployment 
and the *general* topology.
It's easy for the operator to configure the switch with CLI, but it's not 
easy to change the existing topology.

thanks,
Jun Bi

---

From: Dave Thaler <[email-masked]>
Date: Mon, 13 Apr 2009 09:28:44 -0700

For those of us who weren't in the meeting, it would help to vote
if we better understood the consequences of (1) and the consequences of (2).
For example, what's the disadvantage of (1)?

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christian Vogt
> Sent: Saturday, April 11, 2009 8:23 PM
> To: SAVI Mailing List
> Subject: [savi] Your Vote: Incremental SAVI Deployment
>
> Folks -
>

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 14 Apr 2009 11:12:09 +0800

Hi,

I think here we are voting for the requirements from operators (users of 
SAVI), not from the viewpoints from solution designers.

The scenario is that the operators could not replace all existing legacy 
switches on one signal day
(it's a common case in realistic). So when one legacy switch is out of its 
lifetime, the operator may replace
this old switch with one NEW SAVI device.

So the advantage of (1) is to bring more flexibilities to operators.
It seems there would be no disadvantage of (1) from operators' viewpoints 
when deploying SAVI on an existing subnet).
The disadvantage of (2) seems to be bring some restricts to operators when 
they replace a legacy switch on an existing subnet.

thanks,
Jun Bi

----- Original Message ----- 
From: "Dave Thaler" <[email-masked]>
To: "Christian Vogt" <[email-masked]>; "SAVI Mailing List" 
<[email-masked]>
Sent: Tuesday, April 14, 2009 12:28 AM
Subject: Re: [savi] Your Vote: Incremental SAVI Deployment

---

From: Dave Thaler <[email-masked]>
Date: Mon, 13 Apr 2009 22:00:21 -0700

If (1) had no disadvantages then why would anyone vote for (2)?
There must be something (e.g. complexity of solution).

-Dave

> From: Jun Bi [mailto:[email-masked]]
> Sent: Monday, April 13, 2009 8:12 PM
> To: Dave Thaler; Christian Vogt; SAVI Mailing List
> > if we better understood the consequences of (1) and the consequences
> of
> > (2).

---

From: Fred Baker <[email-masked]>
Date: Mon, 13 Apr 2009 22:49:50 -0700

> (1) Yes, arbitrary interconnections of SAVI devices and legacy  
> switches should be supported.
>

 From my perspective, you can hook savi switches together any way you  
like, but the effects of some configurations may differ from others.  
SAVI switches are intelligent. They are not magical.

The real question here relates to the address distribution protocol  
that Christian is pushing.

I think the SAVI switch is securing the things it serves; it is not  
securing the entire switching domain.

If a savi switch is attached to a non-savi switch, the non-savi switch  
will not participate in the protocol. The savi switch could determine  
by observation (snooping or fcfs) what addresses come from it, but it  
won't know how many ports there are, so it will have limited  
capabilities at best. If the same savi switch is attached to another  
savi switch, that savi switch will secure its own ports. So in the  
first case, the savi switch can't protect against ports not on it, and  
in the second case it has no need to - the other savi switch will do  
that.

If an attacker uses SLAAC, when it sends out the DAD probe, the user  
of the address will reply. If a savi switch sees an address being used  
with the wrong MAC (across a neighboring switch, savi or otherwise),  
it can reply with a DAD reponse, and the switch can install a filter  
to make that address go away. That, or we develop a protocol to do the  
same thing, but only if someone can explain why DAD is insufficient.

Consider this. If I have a cheap five port 10/100/1000 switch attached  
to a network containing several cat 6Ks, the BDP model requires the  
cheap switch to have enough memory to store the entire savi table for  
the entire swithed domain. "Cheap" goes straight down the toilet if we  
do that, and as a result so will the standard.

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 14 Apr 2009 23:02:48 +0800

Thank Fred's analysis.

The words for voting is a little bit confusing.
To accurately express my option, I want to express in the following way:

"Under the arbitrary interconnections of SAVI devices and legacy switches,
SAVI device must LINK-WIDELY CORRECTLY anti-spoof for hosts directly
attached to it".

For example, we have SAVI devices S1 and S2, and legacy device L1 and L2.
S1 directly connects hosts A1, A2
S2 directly connects hosts B1, B2
L1 directly connects hosts C1, C2

Given ANY topology of S1, S2, L2 (arbitrary interconnections), the
requirements to solutions are:
(1) if source address of A1 is legally assigned, then if any of A2, B1 or B2
uses A1' source address, then the packets would be dropped by S1 or S2, but
C1,C2 MAY still send packets with A1's source address.
(2) if source address of B1 is legally assigned, then any of A1, A2, B2
could not spoof B1's source address. C1 and C2 MAY still spoof.
(3) if source address of C1 is legally assigned, then any of A1, A2, B1, B2,
could not spoof C1's source address, but C2 MAY still spoof.

Again, I don't mean we need a BDP to achieve this goal, the goal could be 
achieved by
snooping and using the existing control protocols.

thanks,
Jun Bi

----- Original Message ----- 
From: "Fred Baker" <[email-masked]>
To: "Dave Thaler" <[email-masked]>
Cc: "Jun Bi" <[email-masked]>; "Christian Vogt"
<[email-masked]>; "SAVI Mailing List" <[email-masked]>
Sent: Tuesday, April 14, 2009 1:49 PM
Subject: Re: [savi] Your Vote: Incremental SAVI Deployment

> From my perspective, you can hook savi switches together any way you like, 
> but the effects of some configurations may differ from others.  SAVI 
> switches are intelligent. They are not magical.
>
> The real question here relates to the address distribution protocol  that 
> Christian is pushing.
>
> will not participate in the protocol. The savi switch could determine  by 
> observation (snooping or fcfs) what addresses come from it, but it  won't 
> know how many ports there are, so it will have limited  capabilities at 
> best. If the same savi switch is attached to another  savi switch, that 
> savi switch will secure its own ports. So in the  first case, the savi 
> switch can't protect against ports not on it, and  in the second case it 
> has no need to - the other savi switch will do  that.
>
> If an attacker uses SLAAC, when it sends out the DAD probe, the user  of 
> the address will reply. If a savi switch sees an address being used  with 
> the wrong MAC (across a neighboring switch, savi or otherwise),  it can 
> reply with a DAD reponse, and the switch can install a filter  to make 
> that address go away. That, or we develop a protocol to do the  same 
> thing, but only if someone can explain why DAD is insufficient.
>
> Consider this. If I have a cheap five port 10/100/1000 switch attached  to 
> a network containing several cat 6Ks, the BDP model requires the  cheap 
> switch to have enough memory to store the entire savi table for  the 
> entire swithed domain. "Cheap" goes straight down the toilet if we  do 
> that, and as a result so will the standard.
>
>
>

---

From: Fred Baker <[email-masked]>
Date: Tue, 14 Apr 2009 08:08:56 -0700

I think you are saying that a network is protected from spoofing by a  
given host if and only if the switch that host is attached to is  
protecting the network - eg, is a savi switch. That makes sense to me.

On Apr 14, 2009, at 8:02 AM, Jun Bi wrote:

> Again, I don't mean we need a BDP to achieve this goal, the goal  
> could be achieved by
> ----- Original Message ----- From: "Fred Baker" <[email-masked]>
>>> (2) No, it is fine for SAVI to restrict how SAVI devices and  
>>> legacy switches are interconnected.
>>
>> From my perspective, you can hook savi switches together any way  
>> you like, but the effects of some configurations may differ from  
>> others.  SAVI switches are intelligent. They are not magical.
>>
>> The real question here relates to the address distribution  
>> protocol  that Christian is pushing.
>>
>> If a savi switch is attached to a non-savi switch, the non-savi  
>> switch will not participate in the protocol. The savi switch could  
>> determine  by observation (snooping or fcfs) what addresses come  
>> from it, but it  won't know how many ports there are, so it will  
>> have limited  capabilities at best. If the same savi switch is  
>> attached to another  savi switch, that savi switch will secure its  
>> own ports. So in the  first case, the savi switch can't protect  
>> against ports not on it, and  in the second case it has no need to  
>> - the other savi switch will do  that.
>>
>> If an attacker uses SLAAC, when it sends out the DAD probe, the  
>> user  of the address will reply. If a savi switch sees an address  
>> being used  with the wrong MAC (across a neighboring switch, savi  
>> or otherwise),  it can reply with a DAD reponse, and the switch can  
>> install a filter  to make that address go away. That, or we develop  
>> a protocol to do the  same thing, but only if someone can explain  
>> why DAD is insufficient.
>>
>> Consider this. If I have a cheap five port 10/100/1000 switch  
>> attached  to a network containing several cat 6Ks, the BDP model  
>> requires the  cheap switch to have enough memory to store the  
>> entire savi table for  the entire swithed domain. "Cheap" goes  
>> straight down the toilet if we  do that, and as a result so will  
>> the standard.
>>
>>
>>
>
>

---

From: "Jun Bi" <[email-masked]>
Date: Wed, 15 Apr 2009 13:27:04 +0800

Yes, thanks.

Jun Bi
----- Original Message ----- 
From: "Fred Baker" <[email-masked]>
To: "Jun Bi" <[email-masked]>
Cc: "Dave Thaler" <[email-masked]>; "Christian Vogt" 
<[email-masked]>; "SAVI Mailing List" <[email-masked]>
Sent: Tuesday, April 14, 2009 11:08 PM
Subject: Re: [savi] Your Vote: Incremental SAVI Deployment

>> Again, I don't mean we need a BDP to achieve this goal, the goal  could 
>> be achieved by

---

From: "Jun Bi" <[email-masked]>
Date: Wed, 15 Apr 2009 14:38:29 +0800

How about we configure VLANs to divide hosts directly attached to SAVI 
switches and hosts under legacy switches. Then we may greatly simplify the 
problem and it's still acceptable some operators viewpoint (configuring, not 
changing the existing topology).

thanks,
Jun

---

From: Fred Baker <[email-masked]>
Date: Wed, 15 Apr 2009 06:34:56 -0400

On Apr 15, 2009, at 2:38 AM, Jun Bi wrote:

> How about we configure VLANs to divide hosts directly attached to  
> SAVI switches and hosts under legacy switches. Then we may greatly  
> simplify the problem and it's still acceptable some operators  
> viewpoint (configuring, not changing the existing topology).

That is certainly a recommendation we could include. That said, in my  
experience people use VLANs for reasons related to their  
organizations, not related to their switches.

---

From: Christian Vogt <[email-masked]>
Date: Wed, 22 Apr 2009 19:41:59 -0700

On Apr 13, 2009, Dave Thaler wrote:

> If (1) had no disadvantages then why would anyone vote for (2)? There
> must be something (e.g. complexity of solution).

This is exactly right, Dave.  Requiring SAVI devices to work correctly
despite being mixed with legacy switches might make the solution more
complex.  Unfortunately, we don't know yet how much more complex it
would get.  But this voting was suggested during the SAVI session to get
a better feeling of how important folks consider the ability to mix SAVI
devices with legacy switches.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Wed, 22 Apr 2009 19:44:06 -0700

> The real question here relates to the address distribution protocol  

For the record:  I am not pushing for a binding distribution protocol.
There was significant agreement during the SAVI meeting in San Francisco
that we should first analyze the need for such a protocol before we
consider designing one.  And this is the approach we should follow.

- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 23 Apr 2009 09:48:03 +0200

ZhangDong escribió:
> IMHO, an analysis is the premise before we make any decision. I mean the exact analysis decides the direction of the work.
>
> According to the discussion in the ml before, I summarize a scenario. I gusess the it cover the common cases. 
> The legend of the figure is:
> REST--rest part of network
> S--savi switch
> L--legacy switch
> H--host
> The savi device may need to  handle with three kinds of relationship:
> a. between S1 and S2
> b. between S3 and L2 (problem of incremental savi deployment)
> c. between S4 and S5 (problem of  the multi-savi-device Links)
>
>                                --------------
>                               |    REST      |
>                                --------------
>                               /               \
>                          -----                 -----
>                         |  S1 |               | L1 |
>                          -----                 -----
>                        /    |     \           /    |     \
>                    ----   ----   ----    ----   ----   ----
>                   |S2 | |S3 | | L2 |  |S4 | |S5 | | L3 |
>                    ----   ----   ----    ----   ----   ----
>                   /   \   /  \    /   \    /  \    /  \     /  \
>                 Ha Hb Hc Hd He Hf Hg Hh Hi  Hj Hk  Hl 
>
> Am i missing something?
>   

i think what we need to define here, is what protection is expected for
each source address involved
regards, marcelo

> Thanks 
>
> Dong Zhang
>
>
> ----- 原始邮件 -----
> 发件人: Christian Vogt <[email-masked]>
> 日期: 2009年 4月 23日, 星期四,  上午10:44
> 主题: Re: [savi] Your Vote: Incremental SAVI Deployment
> 收件人: Fred Baker <[email-masked]>
> 抄送: SAVI Mailing List <[email-masked]>
>
>
>