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

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 23 Jul 2009 12:07:55 +0200

Sorry for coming back to this, but i have further comments...

Christian Vogt escribió:
>
>  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.
>
I would like to come back to the level of protection achieved by this.

Suppose you have the following topology.

+-------------------+
|     Internet      |
+-------------------+
               |
               |
            +-------+
            | router|
            +-------+
               |  
            +--------+
            |SAVICPS1|--H3
            +--------+
             |     |
        +----+     +---+
        |              |
  +-------------+     +--------+
  |Legacy Switch|     |SAVICPS2|
  +-------------+     +--------+
       |                  |
       H1                 H2

So suppose that as you say, the SAVICPS does create bindings for ports 
connected to another switch.

So, how do we prevent H1 from spoofing H2 address when is sending 
packets to H3 (or to any host in the rest of the internet in the picture 
above)?

I mean, i understnad that the main idea in CPS is that there is 
perimeter defense, so all the borders need to provide protection.
I understand that in order to actually provide the protection, the 
SAVICPS1 device must create bindings for hosts connected behind the 
legacy switch, or am i missing something?

Regards, marcelo

---

From: "Jun Bi" <[email-masked]>
Date: Thu, 23 Jul 2009 21:19:58 +0800

----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "Christian Vogt" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>; "Guang Yao" 
<[email-masked]>
Sent: Thursday, July 23, 2009 6:07 PM
Subject: Re: [savi] SAVI Bindings For Hosts Behind Legacy Switches?

+-------------------+
|     Internet      |
+-------------------+
               |
               |
            +-------+
            | router|
            +-------+
               |
            +--------+
            |SAVICPS1|--H3
            +--------+
             |     |
        +----+     +---+
        |              |

     [Jun Bi]
       SAVI-CPS1 won't creat binding for trunk port.

 [Jun Bi]
  Dear Marcelo,
    Thank you for the question.
    CPS only validate the source address of SAVI deployment area (SAVI area) 
(for hosts directly attached to SAVI
    switches). The goal is to make the hosts in SAVI area (H1 and H3 in your 
picture) won't spoof.

    If the admistrator really want more benifit, we have a deployment 
suggestion.
    The network adminstrator knows which is SAVI-switch, which is 
non-SAVI-swtich.
    Then he can configure two VLANs, one for SAVI area, other for non-SAVI 
area,
    then assign differnt address space (prefixes) for two differnet areas.
    The layer 3 device will do the ingress filtering then H1 can't use H2's 
source address.

   Best Regards,
   Jun Bi

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 23 Jul 2009 16:20:08 +0200

Jun Bi escribió:
>
>
>
> ----- Original Message ----- From: "marcelo bagnulo braun" 
> <[email-masked]>

sorry, this is what i quoted above and that is what i meant... (i guess 
i was too concentrated in the ascii and disregarded the actual text)

>    CPS only validate the source address of SAVI deployment area (SAVI 
> area) (for hosts directly attached to SAVI
>    switches). The goal is to make the hosts in SAVI area (H1 and H3 in 
> your picture) won't spoof.

>    Then he can configure two VLANs, one for SAVI area, other for 
> non-SAVI area,
>    The layer 3 device will do the ingress filtering then H1 can't use 
> H2's source address.
>

so, basically you mean that in order to get SAVI protection _all_ the 
devices in the same IP subnetwork  MUST use SAVI devices and you cannot 
have legacy devices.

This must be explicitly mentioned since imho it is a severe deployment 
limitation.
In other words, if we want to deploy CPS in a subntework, then all the 
devices MUST be SAVI devices.

Regards, marcelo

---

From: "Jun Bi" <[email-masked]>
Date: Thu, 23 Jul 2009 22:41:53 +0800

----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "Jun Bi" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>; "Christian Vogt" 
<[email-masked]>; "Guang Yao" <[email-masked]>
Sent: Thursday, July 23, 2009 10:20 PM
Subject: Re: [savi] SAVI Bindings For Hosts Behind Legacy Switches?

          Hi, I don't want to use the word "protect", it should be 
"anti-spoof".
          SAVI-CPS could anti-spoof in SAVI-area, not none-SAVI area.
          If you deploy _all_ SAVI-CPS switch, then you anti-spoof for _all_ 
host.
          If you deploy some of them, then you anti-spoof for some host 
attched to the new SAVI-switch.
          I think it's reasonable. The more SAVI-switch you deploy, the more 
host you anti-spoof.
          There is no free luch.

          Hi, we mentioned it, that's why Christian also methion it at the 
email above.

          Not "MUST", did you see you reply?

Regards, marcelo

>   Jun Bi

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

---

From: "Guang Yao" <[email-masked]>
Date: Thu, 23 Jul 2009 23:06:50 +0800

> devices in the same IP subnetwork  MUST use SAVI devices and you cannot
[Guang Yao] 
We never mean it is a MUST. It is just a suggestion for deployment.
With partly deployment, CPS still works well, especially on filtering
spoofing from directly connected hosts.
On filtering spoofing packet from trunk port, IMO, CPS chooses the most
secure and effective way that only check whether conflict local bindings.
I know some mechanism would set up bindings on trunk port, but then a _BDP_
must be designed to
clear overdue bindings on the trunk port. Or else, there will be a lot of
other problems: memory cost,
dropping of legal packets, full binding table...

CPS at least makes sure every existing binding is valid without a BDP.
FCFS actually make use of "likely" valid bindings to filter packets, because
every binding may have been overdue.

If you think that is not enough,
OK, please design a SAVI solution that can protect _all_ the IP address in
the
IP subnetwork with only _partly_ deployment and _without_ modify current
protocols.
I think you may find it is impossible.
> devices MUST be SAVI devices.

[Guang Yao]

---

From: "Jun Bi" <[email-masked]>
Date: Thu, 23 Jul 2009 23:33:45 +0800

----- Original Message ----- 
From: "Guang Yao" <[email-masked]>
To: "'marcelo bagnulo braun'" <[email-masked]>; "'Jun Bi'" 
<[email-masked]>
Cc: "'SAVI Mailing List'" <[email-masked]>; "'Christian Vogt'" 
<[email-masked]>; "'Guang Yao'" <[email-masked]>
Sent: Thursday, July 23, 2009 11:06 PM
Subject: RE: [savi] SAVI Bindings For Hosts Behind Legacy Switches?

> every binding may have been overdue.

Hi Marcelo,

By reading all you emails, I think you also recognize the benifit of CPS.
Yes, you may ask more benifit, but please trade off the cost and the 
benifit.
CPS is really a low cost solution and be implemented in switch and tested. 
To recognize the benifit,
the WG at least could made some progress (having a solution works in some 
situation).
It doesn't mean CPS prevent other new technology. You could continute you 
work, but at
least now we did see FCFS has much more problems.

Thanks,
Jun

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 23 Jul 2009 16:48:43 +0200

Jun Bi escribió:
>>    switches). The goal is to make the hosts in SAVI area (H1 and H3 
>> in your picture) won't spoof.
>
>
>>
>          If you deploy _all_ SAVI-CPS switch, then you anti-spoof for 
> _all_ host.

but this is misleading
I mean, as if you see in the figure i sketched above, the host that is 
connected in the legacy switch can spoof the address of _any_ host even 
those that are connected to a SAVI device.

So if you have a network that is using some CPS SAVI devices and some 
legacy switches, an attacker connected to a legacy device can spoof any 
address in the network.

So when a host is connected to a SAVI device this doesn't mean that its 
address is protected and no attacker can spoof it, but what it means is 
that the host cannot spoof any other address of another host that is 
also connected to a savi device (this assuming that the DAD packets are 
widely distributed, which may not be the case, but this is a different 
story)

so i think the protection resulting from the solution is fairly weak.

Regards, marcelo

>          I think it's reasonable. The more SAVI-switch you deploy, the 
> more host you anti-spoof.
>          There is no free luch.
>
>
>          Hi, we mentioned it, that's why Christian also methion it at 
> the email above.
>

---

From: "Jun Bi" <[email-masked]>
Date: Thu, 23 Jul 2009 23:07:30 +0800

----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "Jun Bi" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>; "Christian Vogt" 
<[email-masked]>; "Guang Yao" <[email-masked]>
Sent: Thursday, July 23, 2009 10:48 PM
Subject: Re: [savi] SAVI Bindings For Hosts Behind Legacy Switches?

> those that are connected to a SAVI device.

           (1)The SAVI swtich could prevent the hosts directly attched to 
spoof another address,
        This is a benifit.
           (2)SAVI validate the source address, it doesn't protect the 
detination,that's why I sugesst
                you don't use the word "protect". Any host under legency
            switch could still spoof the source address, it's acceptable, 
because you didn't deploy new technology.
            You get some benifit in the deployment area, when you deploy all 
switch, then you get the highest security
              level, it's reasonable.
              Please note in FCFS, even the host directly attached to 
SAVI-FCFS-switch could still spoof source address.
            (3)Even the hosts under legacy switch won't need to be 
validated, we still proposed a deployment
               suggestion to to VLAN stated in my past email. At that case, 
H1 could not use H2's source
           Address.

> legacy switches, an attacker connected to a legacy device can spoof any 

              Please see above.Sice you did't deploy, why you ask the 
benifit of anti-spoofing.
> that the host cannot spoof any other address of another host that is also 
> connected to a savi device (this assuming that the DAD packets are widely 
> distributed, which may not be the case, but this is a different story)
>

               In the deployment suggestion by using VLAN, the attcker under 
legacy switch
              can't spoof the src of host under SAVI switch.
               So it's not weak.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 23 Jul 2009 17:59:47 +0200

Jun Bi escribió:
>>>>    CPS only validate the source address of SAVI deployment area 
>>>> (SAVI area) (for hosts directly attached to SAVI
>>>>    If the admistrator really want more benifit, we have a 
>>>> deployment suggestion.
>>>>    The layer 3 device will do the ingress filtering then H1 can't 
>>>> use H2's source address.
>>>>
>>>
>>>          If you deploy _all_ SAVI-CPS switch, then you anti-spoof 
>>> for _all_ host.
>>>          If you deploy some of them, then you anti-spoof for some 
>>> host attched to the new SAVI-switch.
>>
>> but this is misleading
>> I mean, as if you see in the figure i sketched above, the host that 
>> is connected in the legacy switch can spoof the address of _any_ host 
>> even those that are connected to a SAVI device.
>
>           (1)The SAVI swtich could prevent the hosts directly attched 
> to spoof another address,
>        This is a benifit.
>                you don't use the word "protect".Any host under legency
>            switch could still spoof the source address, it's 
> acceptable, because you didn't deploy new technology.
well, you could achieve better security if you used another approach

>
>            You get some benifit in the deployment area, when you 
> deploy all switch, then you get the highest security
>              level, it's reasonable.
how come?

>               suggestion to to VLAN stated in my past email. At that 
> case, H1 could not use H2's source
>           Address.
>
as i mentioned before, you can call it a deployment suggestion but what 
it really is is a mean to have all the devices in the subnetwork to be 
SAVI devices, which is the way to comply with the limitation imposed by 
the CPS savi

>> legacy switches, an attacker connected to a legacy device can spoof 
>> any address in the network.
>

I am not sure what do you mean by this, but again, if you have a legacy 
device in the same subnetwork, an attacker connected to the legacy 
device can spoof any address of the subnetwrok under SAVI CPS
>
>>
>> So when a host is connected to a SAVI device this doesn't mean that 
>> its address is protected and no attacker can spoof it, but what it 
>> means is that the host cannot spoof any other address of another host 
>> that is also connected to a savi device (this assuming that the DAD 
>> packets are widely distributed, which may not be the case, but this 
>> is a different story)
>>
>               In the deployment suggestion by using VLAN, the attcker 
> under legacy switch
Again, you can call it as you wish, but the fact is that SAVI CPS 
requires that all switches in the subnetwrok implement SAVI CPS because 
if not an attacker connected to the legacy switch can spoof any address

Regards, marcelo

>>
>> Regards, marcelo
>>
>>>          I think it's reasonable. The more SAVI-switch you deploy, 
>>> the more host you anti-spoof.
>>>          There is no free luch.
>>>
>>>
>>>          Hi, we mentioned it, that's why Christian also methion it 
>>> at the email above.
>>>
>>
>>
>>
>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 23 Jul 2009 18:05:27 +0200

> spoofing from directly connected hosts.
you mean that SAVI CPS only protects against atttacker connected to a 
SAVI device, If the attacker connects to a legacy switch, it can then 
sppof any address  of any host in the netwrok, even if the target host 
is connected directly to a SAVI device.

You can call this that it works well, i guess it is a matter of 
opinions, i wouldn't call it that way.
But i guess we need to agree that we disagree and let the WG to  decide 
if this is acceptable or not

> On filtering spoofing packet from trunk port, 
i am not sure what do you mean by this

> IMO, CPS chooses the most
how is mobility supported for instance?

> every binding may have been overdue.
what do you mean by overdue?

> OK, please design a SAVI solution that can protect _all_ the IP address in

the point is that protecting an unused address i by far less imporntat 
than protecting an actually used address, especially in SLAAC.
the only differenc ebetween an used and an unused address is a DAD NSOL, 
so there is not much gain protecting an unused address in SLAAC

there is however, a lot of benefit in protecting an address that is 
currently being used by a host

regards, marcelo

---

From: "Jun Bi" <[email-masked]>
Date: Fri, 24 Jul 2009 00:08:16 +0800

----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "Jun Bi" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>; "Christian Vogt" 
<[email-masked]>; "Guang Yao" <[email-masked]>
Sent: Thursday, July 23, 2009 11:59 PM
Subject: Re: [savi] SAVI Bindings For Hosts Behind Legacy Switches?

> well, you could achieve better security if you used another approach

            Please let us know the approach with better security.
            In my option, FCFS will lower the security.
            In CPS, the host under SAVI-swtich can't spoof. it's reasonable, 
predictable, and dependable.
            In FCFS,even the host user SAVI-switch can STILL spoof, it's NOT 
predictable, and dependable. Will you call FCFS brings better security?

>
>>
>>            You get some benifit in the deployment area, when you deploy 
>> all switch, then you get the highest security
>>              level, it's reasonable.
> as i mentioned before, you can call it a deployment suggestion but what it 
> really is is a mean to have all the devices in the subnetwork to be SAVI 
> devices, which is the way to comply with the limitation imposed by the CPS 
> savi

            It's very easy and CLEAR for a operator to divide SAVI area and 
non-SAVI area.

> device in the same subnetwork, an attacker connected to the legacy device 
> can spoof any address of the subnetwrok under SAVI CPS

               I meant, if you delpoy a SAVI swtich, then you prevent the 
host under this SAVI switch to spoof.
             Othewise,you could prevent it, it's reasonable, predictable, 
and dependable. Again, there is NO FREE LUCH.

> Again, you can call it as you wish, but the fact is that SAVI CPS requires 
> that all switches in the subnetwrok implement SAVI CPS because if not an 
> attacker connected to the legacy switch can spoof any address
>
> Regards, marcelo
>
>
>>>
>>> Regards, marcelo
>>>

---

From: "Jun Bi" <[email-masked]>
Date: Fri, 24 Jul 2009 00:19:09 +0800

----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "Guang Yao" <[email-masked]>
Cc: "'Jun Bi'" <[email-masked]>; "'SAVI Mailing List'" <[email-masked]>; 
"'Christian Vogt'" <[email-masked]>
Sent: Friday, July 24, 2009 12:05 AM
Subject: Re: [savi] SAVI Bindings For Hosts Behind Legacy Switches?

>> [Guang Yao] We never mean it is a MUST. It is just a suggestion for 
>> deployment.
>>
>
> you mean that SAVI CPS only protects against atttacker connected to a SAVI 
> device, If the attacker connects to a legacy switch, it can then sppof any 
> address  of any host in the netwrok, even if the target host is connected 
> directly to a SAVI device.
>
> You can call this that it works well, i guess it is a matter of opinions, 
> i wouldn't call it that way.
> But i guess we need to agree that we disagree and let the WG to  decide if 
> this is acceptable or not

You don't need to repeat it in any email.
As you see in my last eamil, my answer is:

(1)In CPS, if you delpoy a SAVI swtich, then you prevent the
host under this SAVI switch to spoof.
    Othewise,you could not  prevent it, it's reasonable, predictable,
and dependable.
   The more you deploy, the more host can't spoof, it's reasonable.
   There is NO FREE LUCH.

(2)  In CPS, the host under SAVI-swtich can't spoof (strictly). it's 
reasonable,
predictable, and dependable.
     In FCFS,even the host user SAVI-switch can STILL spoof, it's NOT
predictable, and dependable. Will you call FCFS brings better security?

(3) When deployment, it's very easy and CLEAR for a operator to divide SAVI 
area and
non-SAVI area. Then the attacking case you mentioned won't happen.

(4) Please give me a better design.

> so there is not much gain protecting an unused address in SLAAC

Did you really realize the problems of FCFS ?

thanks,
Jun

---

From: "Guang Yao" <[email-masked]>
Date: Fri, 24 Jul 2009 00:32:27 +0800

I want to summary my personal view on FCFS here:
[Guang Yao] 
1 The first weakness point is logic error.

As we know, FCFS currently uses the following logic:

"Bind the address if it is first ever appear on the switch, and drop the
packet with address conflicting current bindings."

And FCFS_with_BDP uses the following logic:

"Bind the address if it is first ever appear on all the SAVI switches on the
link, and drop the packet with address conflicting any the current binding
on all the SAVI switches."

The problem is, whether it is reasonable and sufficient to set up bindings
when one address is first ever appear on one or any of the SAVI device?

In a SLAAC only network, an implicit rule is that if a host uses an address
first, it has the right to hold this address and ask others not to use the
address. In another word, a reasonable binding is set up based on the clear
knowledge that the sender is the _first_ to use the address on the link.

However, both FCFS and FCFS with BDP fail to be compatible with this rule,
though it is not obvious. FCFS actually takes "first appear on one of the
FCFS device" as "first used in the local link". Unfortunately, they are not
equivalent.

For example, host H may be the first to use an address ADDR, but without
sending any packet to pass any of the FCFS devices, thus no binding will be
set up for it. Then, another host has the chance to trigger a binding of
ADDR. This binding will cause dropping of legal packets from H.

The wrong design principle of FCFS results in a lot of potential problems.

2 The failure model in DHCP only scenario

Recently FCFS is declared to support DHCP, except for no protection for
unused address. 

The first problem is that whether it is reasonable not to protect unused
addresses in DHCP only model. It is clear in a lot of DHCP only scenarios,
to allow other kinds of addresses will cause management problem. Another
problem is, since DHCP is the only used address assignment method, why not
choose a more stable and simple solution based on DHCPv6 snooping just as
DHCPv4 snooping, but choose an untested and potentially dangerous solution?
What's the benefit?

And a more serious problem is FCFS model will give chance to attackers to
trigger evil bindings to filter legal traffic. Because DHCPv6 server would
be likely to assign to a host the same address (Also an attacker may has the
chance to know the assigned address before the host if it is in the middle
of the victim and DHCPv6 server), an attacker has the chance to trigger that
address binding first. When a host gets a REPLY from DHCPv6 server, it
performs DAD but the attacker doesn't reply. Then once the victim sends
packets, these packets will be discarded by FCFS.

3 About BDP
	FCFS relies on a BDP to sync all the FCFS devices in order to make
it work "more correctly". (See section 1 to find why FCFS will never work
real correctly). BDP has been regarded as a bad idea by a lot of people.
Here just to list some of the defects of BDP.
1.	Violate charter.
2.	Heavy cost.
3.	Incrementally deployment problem.
4.	Secure problem on authentication between SAVI devices.
5.	Real time problem.
6.	Reliable problem.
7.	Economic problem.

Recently, there is a trend to use DAD as BDP. However, we don't think the
above problems are really solved if DAD is modified to have the function of
BDP. 

4 The problem of clearing binding
	FCFS doesn't have specified design of when and how to remove a
binding. This problem is same important as the problem of setting up
binding. No binding clear mechanism will surely make the binding table full
and no new binding can be set up after a time.
	
	However, it is hard for FCFS to design a binding clearing mechanism.
We think this problem is due to FCFS sets up binding without regarding the
packet is from directly connected hosts or not directly connected hosts. If
a not directly connected host is disconnected from a switch, the FCFS switch
receives no signal and cannot drop the corresponding binding.

	Though a BDP can make things better, the problem returns to the
problem of designing a _useable_ BDP.

5 Binding lost problem
	FCFS has declared its robustness when binding lost. However, I don't
think it is reasonable.
	Whenever a FCFS device reboot, an attacker can easily set up
bindings of all other addresses on the reboot device before any other hosts.
Then all other hosts will be blocked from network.
	Although FCFS can learn bindings from data traffic, the problem is,
it may not learn correct bindings.

6 Filtering cost
	The filtering cost is rarely high for FCFS.
	6.1. It will take every data packet into CPU
	6.2 It must go through a long "deny" list to make sure whether a
packet should be forwarded.

IMO, I don't agree to move forward with FCFS.

---

From: "Jun Bi" <[email-masked]>
Date: Fri, 24 Jul 2009 00:34:45 +0800

----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "Jun Bi" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>; "Christian Vogt" 
<[email-masked]>; "Guang Yao" <[email-masked]>
Sent: Friday, July 24, 2009 12:20 AM
Subject: Re: [savi] SAVI Bindings For Hosts Behind Legacy Switches?

>>            In CPS, the host under SAVI-swtich can't spoof. it's 
>> reasonable, predictable, and dependable.
>>            In FCFS,even the host user SAVI-switch can STILL spoof, it's 
>> NOT predictable, and dependable. Will you call FCFS brings better 
>> security?

> how is that?
> ...

Did you really didn't realize that FCFS will permit the host directly under 
SAVI swtich spoof?

Please read the msg from Eric on "not fixing the inaccuracy of our binding 
table". I think FCFS is A2.

----- Original Message ----- 
From: "Eric Levy-Abegnoli" <[email-masked]>
To: "Christian Vogt" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>
Sent: Thursday, July 23, 2009 4:25 PM
Subject: Re: [savi] Consensus call on "unregistered" source addresses

>>> (A) In networks where SLAAC is permitted for address configuration, how
>>> should a SAVI device treat packets with a source address for which
>>> neither a successful DAD procedure nor a DHCP assignment was seen?
>>>
>>> (A1) Discard the packet
>>> (A2) Forward and optionally log the packet
>>>
>>
>> [..] All devices are not equal (hardware/software wise, but also
>> deployment-wise), so would be acceptable to habe those which can't
>> verifyi the assumptions to not drop/log in my opinion.
>
> Eric, are you saying that you prefer (A2) without logging?

Christian , in the current state of the proposals, I am against both A1
and A2. A2 is the worse though, because it's "politically correct": it
does not break anything and provides "on the paper" all the tools to
further investigate anomalies.
In reality, logging in the data path is not safe, not reliable (must be
rate-limited), and prone to attacks. Logging it a useful and necessary
tool, not a solution in itself. We should not use it as an excuse for
not fixing the inaccuracy of our binding table.
As far as the "optional log", if we forward and don't log, what have we
accomplished? Isn't it what current non-savi devices do today?

---

From: "Jun Bi" <[email-masked]>
Date: Fri, 24 Jul 2009 00:38:09 +0800

----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "Jun Bi" <[email-masked]>
Cc: "Guang Yao" <[email-masked]>; "'SAVI Mailing List'" 
<[email-masked]>; "'Christian Vogt'" <[email-masked]>
Sent: Friday, July 24, 2009 12:16 AM
Subject: Re: [savi] SAVI Bindings For Hosts Behind Legacy Switches?

>> CPS is really a low cost solution and be implemented in switch and 
>> tested. To recognize the benifit,
> I simply fail to see how you conclude that.
>
> Let's consider CPS for SLAAC
>
> The main problem with CPS is that it hard-codes underlying assumption in 
> the network architecture. What do i mean by this? Well, basically, CPS 
> assumes that in order to allow a host to send packets, it must have been a 
> prior DAD. While this is common, it is not required by the current IPv6 
> architecture. But CPs hardcodes it in SAVI. The result is that the fate 
> sharing domain of the node is significantly increased. If the SAVI device 
> looses state, then the host is blocked. If the DAD packet is lost, the 
> host is blocked. The result is a significantly less robust network 
> architecture.
>
> I simply believe that is not a good tradeoff.
>
> then we can go to more practical issues.
>
> The CPS solution requires manual configuration of the ports (whehter they 
> are connected to a SAVI device, a host or a legacy switch)
> IIt doesn't protect from attackers connected to a legacy device from 
> spoofing any address in the subnetwork, even if the target host is 
> connected to a SAVI device. this means that either all the devices of the 
> network are SAVI devices or that significant attacks are possible.

Hi Marcelo,

Finally, I am happy that now you come back the technical questions, not keep 
arguing.
Is the above two questons are what you concern on CPS ?
The attached file is CPS-01. Please read and I think you questions are 
anwered.
The testing for an implemention in a switch also shows it works and we will 
have a demo at IETF75.

The let the operator configure the switch port is also reason.
The operator could have the right to decide which port is for host,which 
port is for trunk, which port
is for HDCPv6 server, etc. For port enabled binding, the port anti-spoofing.
Otherwise, it doesn't. We should provide the flexibility for users to 
configable.

Indeed we have implemented it. You could see the swtich at IETF 75.

For the ND loss, I think we discussed many times.
(1) We did a lot of test with our switch impemented CPS, we never found the 
ND loss.
(2) In IPv4, it requrie 3 redundent.
    In IPv6, it's configable. it's one of the possible way to fix it to ND 
packet redundent.

Best Regards,
Jun

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 23 Jul 2009 18:20:47 +0200

Jun Bi escribió:
>            In FCFS,even the host user SAVI-switch can STILL spoof, 
> it's NOT predictable, and dependable. Will you call FCFS brings better 
> security?
>
how is that?
...
>>
>>>
>> as i mentioned before, you can call it a deployment suggestion but 
>> what it really is is a mean to have all the devices in the subnetwork 
>> to be SAVI devices, which is the way to comply with the limitation 
>> imposed by the CPS savi
>
>            It's very easy and CLEAR for a operator to divide SAVI area 
> and non-SAVI area.
>
sure we can require the IP subnetwork to only have SAVI devices, but 
this is certainly a limitation

Regrads, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 23 Jul 2009 18:16:52 +0200

Jun Bi escribió:
> the WG at least could made some progress (having a solution works in 
> some situation).
> It doesn't mean CPS prevent other new technology. You could continute 
> you work, but at

The main problem with CPS is that it hard-codes underlying assumption in 
the network architecture. What do i mean by this? Well, basically, CPS 
assumes that in order to allow a host to send packets, it must have been 
a prior DAD. While this is common, it is not required by the current 
IPv6 architecture. But CPs hardcodes it in SAVI. The result is that the 
fate sharing domain of the node is significantly increased. If the SAVI 
device looses state, then the host is blocked. If the DAD packet is 
lost, the host is blocked. The result is a significantly less robust 
network architecture.

The CPS solution requires manual configuration of the ports (whehter 
they are connected to a SAVI device, a host or a legacy switch)
IIt doesn't protect from attackers connected to a legacy device from 
spoofing any address in the subnetwork, even if the target host is 
connected to a SAVI device. this means that either all the devices of 
the network are SAVI devices or that significant attacks are possible.

So, no, i don't agree to move forward with CPS.

Regards, marcelo

---

From: "Guang Yao" <[email-masked]>
Date: Fri, 24 Jul 2009 00:42:03 +0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> marcelo bagnulo braun
> Sent: Thursday, July 23, 2009 10:49 PM
> To: Jun Bi
> Cc: SAVI Mailing List; Christian Vogt; Guang Yao
[Guang Yao] 
CPS checks packet from trunk port based on "no local conflict" principle.
In another word, the host cannot spoof the host directly attached to the
switch. So at least it cannot spoof _any_ host, specially the directly
connected hosts.

And with the packet pass through more SAVI devices, the possibility is lower
for it to spoof.

And what is most important, the ability of SAVI is defined to be filtering,
not protect. Please see the charter.
> legacy switches, an attacker connected to a legacy device can spoof any
[Guang Yao] 
I cannot image a mechanism, deployed on a device, stops an attacker attached
to other device 
from spoofing others' addresses.
> widely distributed, which may not be the case, but this is a different
[Guang Yao] 
No, it is protected from used by other nodes attached to SAVI devices.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 24 Jul 2009 19:08:46 +0200

Guang Yao escribió:
> sending any packet to pass any of the FCFS devices,

the host should send a DAD when configuring the address in the 
interface, so the FCFS SAVI device will learn it from there
The remaining case is when the DAD is lost.
In that case what to do?
FCFS learns from the data packet (instead of blocking the legitimate 
user out of the network)

>  thus no binding will be
i certainly can see the benefits of having the dhcp server to act as an 
authorization server centrally allocating the addreses.
So, i can see a benefit in spoofing dhcp traffic
In addition, dhcp exchange is reliable, so it is more likely that the 
savi device can learn reliably from it

My concerns with this is what happens if the savi device looses the state?
As we discussed earlier, it is clear that in wireless networks, the node 
does not need to send any dhcp msg when the AP reboots.
the situation in the wired network still needs to be clarified by the 
dhcp experts, hope it can be done in the next meeting

An additional concern is about how to handle legacy switches, as we 
discussed extensively already.
An additionla concern is how to authenticat the dhcp server (i.e. how to 
prevent an attacker to send false dhcp msg and make beleive the savi 
device it has the right to use a given address)
An additional concern is how to deal with topology changes, where the 
ports where packets come from a soruce may change

> packets, these packets will be discarded by FCFS.
I am not sure i understnad this situation
Does the host has or not has the address allocated to it?
If it does not has it, but it is expecting to have the same address, 
there is no problem if it gets a different address.
If the host does has it assigned, the savi device would have the binding.

> Here just to list some of the defects of BDP.
how come?
current switches execute a number of protocols, hwo come this one would 
be a heavy cost and the other are not?

> 3.	Incrementally deployment problem.
not sure what do you mean by this

> 4.	Secure problem on authentication between SAVI devices.
i can't see how this is different from authenticating a dhcp server for 
instance or with configuring some ports to be the ones that are 
connecting the other SAVI devices as CPS does

> 7.	Economic problem.

i don't understnad what do you mean by none of these

> above problems are really solved if DAD is modified to have the function of

using DAD is another alternative, as you mention, and it has pros and 
cons that need to be analyzed

> receives no signal and cannot drop the corresponding binding.
so in cps, you assume that if the connection with the host is lost, then 
the binding is deleted?

So you actually hardcode the rule that the host must perform DAD when 
the links flaps?

what can i say, i don't think this is required by any rfc

In FCFS, before dropping a entry, a series of NUDs is performed to make 
sure that the host is no longer connected, so the binding can be 
reliably discarded.

> bindings of all other addresses on the reboot device before any other hosts.
this woudl require the attacker to be able to reboot the savi device to 
launch the attack or to limit the attacks to the moment when the savi 
device reboost, which hopefull is not very often

> Then all other hosts will be blocked from network.
Please note that FCFS works by definition better than CPS in this case.
In fcfs, if the nodes perform the DAD, then they are in like in CPS.
If they don't they can still be in, when they send a data packet. In CPS 
they are simply out
> 	6.1. It will take every data packet into CPU
wouldn't every solution require that?
I mean, since the savi device is epxected to filter every data apcket, 
then every data apcket needs to be processed

Regards, marcelo

---

From: Christian Vogt <[email-masked]>
Date: Sat, 25 Jul 2009 00:25:46 -0700

On Jul 23, 2009, Guang Yao wrote:

> I want to summary my personal view on FCFS here...

Guang -

Thanks for the detailed analysis!

Independent of whether one agrees with the conclusions you are making,
it seems that the middle-ground approach sketched in [1] would satisfy
your conclusions.  Is this right?

Recall the properties of the middle-ground approach:

- binding creation exclusively based on DAD packets (for SLAAC)
- protection of unused addresses in DHCP-only mode
- no need for BDP

Christian

[1] http://www.ietf.org/mail-archive/web/savi/current/msg00715.html

---

From: "Jun Bi" <[email-masked]>
Date: Mon, 27 Jul 2009 14:28:31 +0200

----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "Guang Yao" <[email-masked]>
Cc: "'SAVI Mailing List'" <[email-masked]>; "'Christian Vogt'" 
<[email-masked]>
Sent: Friday, July 24, 2009 7:08 PM
Subject: Re: [savi] SAVI Bindings For Hosts Behind Legacy Switches?

Guang Yao escribió:
> [Guang Yao] 1 The first weakness point is logic error.
>

           We talked many times on the DAD lost.
           1) the possiblity of lost is really very low
           2) One simple way to resolve it let the host to send redundent 
DAD by change
           the default value of  DupAddrDetectTransmits to more than 2. Then 
the lost possiblity will even lower.
           If be a low cost way compared FCFS to bring more cost the data 
plan in the switch (heavy burden).

            thanks,
            Jun

In that case what to do?

how come?

        It's differnet. A switch could control the rate of control packet 
(because if the rate of control packets such as NDP is high, it means 
something wrong in the host, then the switch could limit the rate or close 
the port to stop attacking. But a swtich could NEVER control the normal data 
packet rate, it might be 100Mbps constant, and there is no reason to limit 
the normal traffic rate, then FCFS need to track every data packet to match 
with a long list (binding table) (the cost is high for a access switch). 
CPS just need to match the bit to see if it is a control packet. (the cost 
is low). So it is different.

   Best Regars,
   Jun Bi

Regards, marcelo

---

From: "Jun Bi" <[email-masked]>
Date: Mon, 27 Jul 2009 14:17:23 +0200

----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "Jun Bi" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>; "Christian Vogt" 
<[email-masked]>; "Guang Yao" <[email-masked]>
Sent: Thursday, July 23, 2009 6:20 PM
Subject: Re: [savi] SAVI Bindings For Hosts Behind Legacy Switches?

> sure we can require the IP subnetwork to only have SAVI devices, but this 
> is certainly a limitation
You may call it has "limitation" (everything in the world has limitation),
but it also means you agree it works. A solution which is working and with 
low cost brought to switch is doable.
The vendors already showed their support.

thanks,
Jun

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Mon, 27 Jul 2009 15:55:25 +0200

Marcelo, Jun,
lenghty discussion .. I had to pick one mail to give my position. So be 
this one ...
marcelo bagnulo braun a écrit :
> The main problem with CPS is that it hard-codes underlying assumption 
> in the network architecture. What do i mean by this? Well, basically, 
> CPS assumes that in order to allow a host to send packets, it must 
> have been a prior DAD. While this is common, it is not required by the 
> current IPv6 architecture. But CPs hardcodes it in SAVI. The result is 
> that the fate sharing domain of the node is significantly increased. 
> If the SAVI device looses state, then the host is blocked. If the DAD 
> packet is lost, the host is blocked. The result is a significantly 
> less robust network architecture.
>
I think CPS has good potential. As opposed to FCFS. Being able to work 
at the control protocol level is absolutely key on switches which 
sometimes have tens of thousands of Gigabit ports. Creating binding 
entries off data traffic on these devices, as  well as logging anomalies 
, is going to do more harm than good, and opens avenues for DoS attacks.
We got to find a way to build a solid binding table out of the control 
traffic (DHCP, NDP, ...).Would be a lot easier if we had a declarative 
protocol (such as RFC3122) , but unfortunately it's not widely 
implemented. The DHCP case is quite easy, and well covered in the CPS 
draft. The SLACC case needs imrpovements and I think it's exactly what 
my draft is about (draft-levy-abegnoli-savi-plbt-00 
<https://datatracker.ietf.org/drafts/draft-levy-abegnoli-savi-plbt/>).
Basically, the issue that Marcelo raised can be solved:
- to deal with missing DAD packets, snoop other NDP packets. A node 
doing SLACC is going to send 1) DAD 2) unsolicited NA 3) NS prior to 
talk to anybody. None of these messages is required, but the odds of 
getting none of them are extremely low.
- As far as dealing with attackers connected to legacy switches, use the 
preference algorithm that I proposed. A binding coming from an attached 
host or received via a savi-device should be preferred over one coming 
from a non-savi device.
Eric