Subject: [savi] DAD as a binding distribution protocol: why not

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 15 Apr 2009 15:03:56 +0200

About why DAD does not work as a SAVI binding distribution protocol.

Several people (including myself) have considered using the DAD
procedure to distribute SAVI binding information across all the SAVI
devices within a link (or broadcast domain).

In the last meeting, a couple of people (Greg and Suresh to be precise)
explained why this was not possible. I include their argument below,
as they explained it to me, since it is relevant for our discussions.

Consider the following scenario:

+--+    +--+   +--+       +--+  +--+
|HA|    |HB|   |HC|       |HD|  |HE|
+--+    +--+   +--+       +--+  +--+
 |       |      |          |     |
 |    +-------------+   +------------+
 +----|  SWITCHA    |---|  SWITCHB   |
      +-------------+   +------------+

Suppose Host HX has configured address IPX (i.e. HA has IPA, HB has IPB
and so on)

Suppose for this example that the lower 24 bits of all the hosts are
different (what is actually required is that there is no pair of nodes
H1 and H2 located in different switches that have the same lower 24
bits, but anyway)

Let's see how does this simple system works in IPv6.

Suppose all hosts are using stateless autconfiguration.

So, whenever a host HX gets configures its address, it performs the
procedure described in RFC4862. This procedure, essentially implies to
generate the tentative link local address, join the solicited-node
multicast address for that address, send a NSOL for that address to the
solicted-node multicast group for that address and wait and see. If
nobody replies, it configures the link local address. Using the prefix
information available in the RADV, it can then generate the global
addresses.

So, note that according to RFC2462, stateless address  Autoconfiguration
is performed only on multicast-capable links.
So, suppose that all nodes have configured theu address except for node
HA.
Node HA performs the DAD procedure to configure its address, the
question is who will receive the NSOL that it is issuing?

By the assumption we made before, that all the hosts had different lower
24 bits in their addresses, there is no other node that has joined the
solicited node multicast group for the candidate address of HA. In
particular, no hosts connected to SWITCHB has joined the group.

This means that SWITCHA will _not_ forward the NSOL message of HA's DAD
procedure to SWITCHB.

The implication for SAVI is that the DAD procedure cannot be trusted as
a way to distribute binding information accross the SAVI devices
connected to the same broadcast domain.

Now, this is a problem since we cannot rely on this to distribute the
SAVI information. However, it is actually a good thing, in the sense
that we can control much more the size of the binding tables in the SAVI
devices since we can design much more efficient SAVI verification
protocols (pull type of protocols).

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 15 Apr 2009 15:58:43 +0200

the point being made is that SWITCHB in the figure below, will not
receive the NSOL msg, so it won't be able to learn the binding between
the src address and the L2 anchor, so if we want SWITCHB to actually
defend that binding, we will need to make SWITCHB learn it though
another mean

Regards, marcelo

Guang Yao escribió:
> I think you have forgotten a very important thing: 
> if there is no collision, there is no need to deliver the NSOL to all the
> nodes.
>
> In another word, the NSOL must be delivered to the collision node, no matter
> other nodes receive it or not.
>
> In your scenario, no node pair has collision address, why should the NSOL be
> delivered to all of them?
>
> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 marcelo
> bagnulo braun
> 发送时间: 2009年4月15日 21:04
> 收件人: SAVI Mailing List; Suresh Krishnan; Greg Daley
> 主题: [savi] DAD as a binding distribution protocol: why not
>
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi
>
>
>

---

From: Fred Baker <[email-masked]>
Date: Wed, 15 Apr 2009 10:09:41 -0400

Have you considered my comments on why a Binding Distribution Protocol  
is a bad idea? Or are you arguing the next step - what protocol to use  
to implement the bad idea?

---

From: "Greg Daley" <[email-masked]>
Date: Thu, 16 Apr 2009 00:20:21 +1000

Regardless of whether a binding distribution protocol is worthwhile, DAD
isn't it. 

Greg Daley

-----Original Message-----
From: Fred Baker [mailto:[email-masked]] 
Sent: Thursday, 16 April 2009 12:10 AM
To: marcelo bagnulo braun
Cc: SAVI Mailing List; Suresh Krishnan; Greg Daley
Subject: Re: [savi] DAD as a binding distribution protocol: why not

On Apr 15, 2009, at 9:03 AM, marcelo bagnulo braun wrote:

> Suppose Host HX has configured address IPX (i.e. HA has IPA, HB has 
> IPB and so on)
>

> multicast address for that address, send a NSOL for that address to 
> the solicted-node multicast group for that address and wait and see. 
> If nobody replies, it configures the link local address. Using the 
> prefix information available in the RADV, it can then generate the 
> global addresses.
>
> So, suppose that all nodes have configured theu address except for 
> node HA.

> This means that SWITCHA will _not_ forward the NSOL message of HA's 
> DAD procedure to SWITCHB.
>
> The implication for SAVI is that the DAD procedure cannot be trusted 
> as a way to distribute binding information accross the SAVI devices 
> that we can control much more the size of the binding tables in the 
> SAVI devices since we can design much more efficient SAVI verification

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 15 Apr 2009 16:28:25 +0200

Fred,

My understanding is the following:
In the last meeting, there was rough consensus on the requirements that 
the protection domain of a SAVI solution should cover a whole link

In oher words, suppose we have the following topology

+--+    +--+   +--+       +--+  +--+
|HA|    |HB|   |HC|       |HD|  |HE|
+--+    +--+   +--+       +--+  +--+
|       |      |          |     |

suppose both SWITCHA and SWITCHB are SAVI devices

Now, a SAVI solution sould not only protect that HB and HC don't spoof 
HA address but also must prevent HD and HE to spoof HA source address

Do you agree on that or do you think it is ok to have a savi solution 
that only prevents HB and HC from spoofing HA address, but does not 
prevents HD nor HE to spoof HA address?

Now, if we want this extended protection domain, we need to coordinate 
between the SAVI devices that are in the same link

What i understood you stated in the last meeting is that having all savi 
devices storing all bindings for a whole link would render the solution 
economically non viable

that restriction makes perfect sense to me

I think it is possible to actually have the extended domain and not have 
all savi devices have all the bindings.
Instead of using a push approach we can use a pull approach
I think this is perfectly feasible. would that make sense to you?

Moreover, i think that whatever SAVI protocol we define, if we do so, 
shpould be optional. I mean, depending on the topology and the level of 
protection desired, it is perfectly possible that this is achieved 
without the SAVI protocol. So, i think that the SAVI protocol should be 
a separate component of the solution

About what i brought the description why DAD cannot be used, i thought 
it was worth describing this in detail cause i felt there was some 
people confused about the possibility of using DAD for this (in 
particular, i was confused since i thought is was possible to use it) so 
i thought it was worth clarifying it. Sorry if this caused more confusion.

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 15 Apr 2009 17:04:08 +0200

Guang Yao escribió:
> 1,  If the anchor is port, there is no need for the SWITCHB to protect the
> binding. Why doesn't SWITCHA protect it?
>   

In the figure below, HE can sppof HA addresses when talking to devices
tha are not conencted to SWITCHA (e.g. when talking to HD)

in order to protect this we need SWITCHB to be involved

this applies both when we use MAC addresses and ports as lower layer anchors

Regards, marcelo

> SWITCHB has little capability to protect the hosts far from it. I think SAVI
> device should only protect the host directly attached. This is a strong
> security.
> If we design a BDP just to enable it has the ability to perform a
> "ingress-filtering"-like check, it is not worthwhile. And there is no
> incentive for the deployer.
>
> 2, If the anchor is MAC, currently there is no secure MAC that can step
> across switch. 802.1ae/af can only work on directly attached switch.
>
> Regards, Guang
>
> -----邮件原件-----
> 发送时间: 2009年4月15日 21:59
> 收件人: Guang Yao
> 抄送: 'SAVI Mailing List'; 'Suresh Krishnan'; 'Greg Daley'
> 主题: Re: [savi] 答复: DAD as a binding distribution protocol: why not
>
>> In another word, the NSOL must be delivered to the collision node, no
>>     
> matter
>   
>> In your scenario, no node pair has collision address, why should the NSOL
>>     
> be
>

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Wed, 15 Apr 2009 17:33:15 +0200

Marcelo,
The function that would prevent SWITCHA to forward DAD packets to 
SWITCHB in this scenario is_not_dictated by RFC4862 or even RFC3810 
(MLD). The switches are L2 devices and not expected to limit the 
multicast forwarding to L3-devices who have joined the group. In theory, 
DAD multicast should be forwarded to trunks, regardless of who joined.
If switches perm MLD snooping, there could be a problem, however RFC4541 
is very cautious with regard to switch deciding not_to copy traffic to a 
port where no join was seen.
It looks to me that in this scenario, for switches doing mld snooping, 
it would not be un-reasonnable to have a configuration option on SWITCHA 
to enable copy of multicast traffic on its trunks regardless of snooped 
groups. SWITCHB could still decide not to deliver the traffic to any 
device if nobody joined the group.
That would enable DAD to be usable as a binding distribution protocol.
Eric

---

From: "Jun Bi" <[email-masked]>
Date: Thu, 16 Apr 2009 01:21:01 +0800

Here I don't want to use the term BDP (do we really need a BDP to achieve 
the anti-spoof-ability ?),
just see how we achieve the goals of anti-spoofing.

I think when Christian visting Tsinghua today, we discussed the samilar 
question.
If the solution is SAVI-CPS, then we didn't see any porblem to anti-spoof. 
(I don't want to say that SAVI-CPS uses DAD as a BDP, because in SAVI-CPS, 
no new protocol is designed, just snooping the existing control protocol).
If the solution is SAVI-FCFS, then it will be a problem without BDP.

IF the binding table is set up by SAVI-CPS, even if switch B dones't konw 
the binding table of switchA, HD, HE still could not spoof the source 
address of HA,HB,HC. The intial binding table of SwitchB is empty for HD and 
HE, the binding is set up based on the control protocol snooping. If HD is 
an attaker and tried to send packets use source address of HA, then BEFORE 
the binding, swtichB will will wait for the DAD-NS, then forward the DAD-NS 
to SwitchA (because the src addr of the DAD-NS wants used is within the same 
multicast group of HA. Then swtichB will see the confict (DAD-NA from HA), 
the drop HD's packets. (Please see the draft of SAVI-CPS).

Considering the incrementatl depolyment, the operator could configure three 
types of ports for the SAVI swtich: SAVI-HOST (savi switch to savi host), 
SAVI-SAVI (savi switch to savi switch), SAVI-Legacy  (savi switch to legacy 
switch). SAVI switch will trust packets from SAVI-SAVI port. SAVI switch 
will snoop control packets of SAVI-HOST port and setup the intial binding.

thanks,
Jun Bi

----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "Guang Yao" <[email-masked]>
Cc: "'SAVI Mailing List'" <[email-masked]>; "'Suresh Krishnan'" 
<[email-masked]>; "'Greg Daley'" <[email-masked]>
Sent: Wednesday, April 15, 2009 9:58 PM
Subject: Re: [savi] 答复: DAD as a binding distribution protocol: why not

---

From: "Jun Bi" <[email-masked]>
Date: Thu, 16 Apr 2009 01:29:04 +0800

Exactly, DAD is not a BDP.
A real BDP will be very complex, if we use SAVI-FCFS.

The question is: if we use SAVI-CPS (please see the draft we sent to the 
mailing list and IETF)
to setup the binding table, do we still need an additional complex BDP to 
distribute the binding table ? Currently, I see no need for a BDP. Maybe I 
am wrong, but we could discuss the potential issues and enhance the 
solution.

thanks,
Jun Bi

----- Original Message ----- 
From: "Greg Daley" <[email-masked]>
To: "Fred Baker" <[email-masked]>; "marcelo bagnulo braun" 
<[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>; "Suresh Krishnan" 
<[email-masked]>
Sent: Wednesday, April 15, 2009 10:20 PM
Subject: Re: [savi] DAD as a binding distribution protocol: why not

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 15 Apr 2009 19:39:24 +0200

Jun Bi escribió:
> Here I don't want to use the term BDP (do we really need a BDP to
> achieve the anti-spoof-ability ?),
> I think when Christian visting Tsinghua today, we discussed the
> samilar question.
> If the solution is SAVI-CPS, then we didn't see any porblem to
> anti-spoof. (I don't want to say that SAVI-CPS uses DAD as a BDP,
> because in SAVI-CPS, no new protocol is designed, just snooping the
> existing control protocol).
> IF the binding table is set up by SAVI-CPS, even if switch B dones't
> konw the binding table of switchA, HD, HE still could not spoof the
> source address of HA,HB,HC. The intial binding table of SwitchB is
> empty for HD and HE, the binding is set up based on the control
> protocol snooping. If HD is an attaker and tried to send packets use
> source address of HA, then BEFORE the binding, swtichB will will wait
> for the DAD-NS, then forward the DAD-NS to SwitchA (because the src
> addr of the DAD-NS wants used is within the same multicast group of
> HA. Then swtichB will see the confict (DAD-NA from HA), the drop HD's
> packets. (Please see the draft of SAVI-CPS).

So, if i understand it correctly, the default action is in the SAVI CPS
is to drop packets i.e. if the savi device has not seen a signalling
packet before, it will drop the packet.

I am not very comfortable with that approach.

consider the following situations:

- what happens if the switch is rebooted? I mean, suppose that you have
a bunch or computers connected to a savi switch. They all have performed
the DAD and the SAVI data base is populated. Now the switch is rebooted
and the data base information is lost. what happens? AFAIU, the SAVI
device will start dropping all the packets, right?
- what happens if the DAD packet is lost? DAD is by definition an
unreliable procedure, so it may happen. Moreover, since the DAD is the
first packet an interface sends, whenever technology takes some time to
move to up state, the first packet is the one with most probabilities to
get lost.
- are you planning to do some garbage collection? I mean, as Fred has
been saying, we need to keep the tables small. So, at some point the
SAVI device will need to perform some form of garbage collection, what
happens when the entry of a host is deleted by the garbage collection
process? the hsot will not perform the DAD process again, so what
happens? (and i am not even considering the case where an attacker is
creating savi entries in a bulk manner)

So, imho, having a default behaviour of dropping packets seems like the
wrong approach.

The savi device must learn and be able to recover state when it is lost
while still being able to tell if this is an attacker or not

>
> Considering the incrementatl depolyment, the operator could configure
> three types of ports for the SAVI swtich: SAVI-HOST (savi switch to
> savi host), SAVI-SAVI (savi switch to savi switch), SAVI-Legacy (savi
> switch to legacy switch). SAVI switch will trust packets from
> SAVI-SAVI port. SAVI switch will snoop control packets of SAVI-HOST
> port and setup the intial binding.
>
sure, this sounds the reasonable thing to secure any SAVI protocol

Regards, marcelo

> thanks,
> Jun Bi
>
> ----- Original Message ----- From: "marcelo bagnulo braun"
> <[email-masked]>
>>> SAVI

---

From: "Jun Bi" <[email-masked]>
Date: Thu, 16 Apr 2009 01:57:49 +0800

I agree all of your points, thanks a lot!
I would like to propose change the expression of the following sentence
"That would enable DAD to be usable as a binding distribution protocol."
to
"That would enable DAD to be usable for setting up the initial binding 
table".

I know your really meant DAD is good to be used to ant-spoof, yes, thanks. 
But conceptually, DAD is not a BDP I think.
Because, BDP means "Binding table distribution in SAVI switch", DAD indeed 
doesn't distribute any table in SAVI switch. So conceptually, DAD is not a 
BDP.

DAD is the duplicate detection, but we could make full use of it to achieve 
the goal of anti-spoofing
(by correctly set up the binding table).

By the way, the charter doesn't say we have to design a BDP.

----- Original Message ----- 
From: "Eric Levy-Abegnoli" <[email-masked]>
To: "marcelo bagnulo braun" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>; "Suresh Krishnan" 
<[email-masked]>; "Greg Daley" <[email-masked]>
Sent: Wednesday, April 15, 2009 11:33 PM
Subject: Re: [savi] DAD as a binding distribution protocol: why not

Marcelo,
device if nobody joined the group.concept

---

From: "Jun Bi" <[email-masked]>
Date: Thu, 16 Apr 2009 01:58:37 +0800

> device will start dropping all the packets, right?

We did some test and showed a demo to Chrtion today, we the link is down and 
up,
(you plug the calbe out and intert it again. The switch rebooting is 
samilar)
the host will try to get new address. It's also good for the changing port 
case.
We are writting a SAV experimental draft based on Christian's suggestin.
You resonable question are always welcome, because that would be the inputs
of our experimental draft. We will do more test to answer those questions 
and make a report.
So you could ask more. If will helpful to make the solution more perfect.

> move to up state, the first packet is the one with most probabilities to

Actually, we discussed with Christian during this afternoon's meeting.
The Operating systems should send redundancy detection packets. We could 
make use of the RFCs.
IPv4: 3 detection packets.[RFC5227]
IPv6: Not specified but it's configurable.[RFC4862]

> happens?

Before clean the entry, the SAVI switch could send out some prob packets to 
see if the host is still alive.

>(and i am not even considering the case where an attacker is

If the attack is under SAVI switch, if a host is trying to get too many 
addresses, the SAVI switch has the ability to contol the suspicious host.

> while still being able to tell if this is an attacker or not

Please give more explaination on your points, we will answer (if we could 
answer by analysis, then we will answer it soon,
otherwise, we will do the experients). Again, you inputs are welcome.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 15 Apr 2009 20:29:35 +0200

Jun Bi escribió:
> When the host wants to use a new address, it has to pass the duplicate
> address detection
> (please note that SAVI-CPS also works on DHCPv6 and DHCPv4 case for
> the duplicate address detection),
> otherwise it could not send packets. It is a reasonable logic for
> normal users.

right, but if something goes wrong, like the DAD packet is lost or the
switch state is lost, the host is disconnected from the network, and
there doesn't seem to be an easy way to recover, other than rebooting
the interface
So my concern is that a failure mode of SAVI CPS can have a very serious
impact in the network.

Regards, marcelo

>>>>> node

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 15 Apr 2009 20:29:39 +0200

Jun Bi escribió:
> We did some test and showed a demo to Chrtion today, we the link is
> down and up,
> the host will try to get new address. 

according to rfc4862

5.3. Creation of Link-Local Addresses

A node forms a link-local address whenever an interface becomes
enabled. An interface may become enabled after any of the following
events:

- The interface is initialized at system startup time.

- The interface is reinitialized after a temporary interface failure
or after being temporarily disabled by system management.

- The interface attaches to a link for the first time. This
includes the case where the attached link is dynamically changed
due to a change of the access point of wireless networks.

- The interface becomes enabled by system management after having
been administratively disabled.

So it is not obvious to me that you can rely on all the implementations
performing the DAD procedure when the switch is rebooted

besides, there are several failure modes in a switch, that may result in
different behaviour, i guess

> It's also good for the changing port case.
> of our experimental draft. We will do more test to answer those
> questions and make a report.
> The Operating systems should send redundancy detection packets. We
> could make use of the RFCs.

yes, but the default value is 1

from rfc4862:

DupAddrDetectTransmits The number of consecutive Neighbor
Solicitation messages sent while performing Duplicate Address
Detection on a tentative address. A value of zero indicates that
Duplicate Address Detection is not performed on tentative
addresses. A value of one indicates a single transmission with no
follow-up retransmissions.

Default: 1, but may be overridden by a link-type specific value in
the document that covers issues related to the transmission of IP
over a particular link type (e.g., [RFC2464]).

so loosing that packet would make the host to be disconnected from the
network

> Before clean the entry, the SAVI switch could send out some prob
> packets to see if the host is still alive.
>
makes sense to me

> If the attack is under SAVI switch, if a host is trying to get too
> many addresses, the SAVI switch has the ability to contol the
> suspicious host.
>

but that is far from obvious how to do it, especially when you have a
legacy switch connected to the savi device. I mean, if you have a host,
maybe, you need to consider the impact of privacy addresses and his type
of things, but still, but when you have a switch connected, i am not
sure what number should be reaosnable to have that is compatible with
having small tables

regards, marcelo

> Please give more explaination on your points, we will answer (if we
> could answer by analysis, then we will answer it soon,

---

From: Fred Baker <[email-masked]>
Date: Wed, 15 Apr 2009 14:47:24 -0400

> So my concern is that a failure mode of SAVI CPS can have a very  

May I balance that statement a little?

Yes, failure modes create issues. I can think of some interesting, and  
related, failure modes in FCFS as well - if a datagram that was in  
fact the first user of an address is lost, someone else might  
accidentally concoct the same address and try to use it.

I will point out, however, that ALL of today's fielded proto-savi  
equipment (Cisco, Extreme, and I think others) depend on DHCP  
snooping, which is one instance of CPS. I'm sure that there is an  
occasional glitch, but as near as we can tell they all in fact work to  
their administrator's satisfaction.

The reason we have DHCPv6 address assignment is that operators have  
told us they would like that to be among their options...

---

From: "Jun Bi" <[email-masked]>
Date: Thu, 16 Apr 2009 08:56:01 +0800

In 802.1x access, the defaul is dropping packets.
it has been widely deployed, after the password checking (also stored some 
states for hosts), the user could communicated.
I didn't see any problem from 802.1x.
SAVI-CPS' requirement is less than 802.1x, so I think it won't be a problem.
thanks,
Jun Bi
----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "Jun Bi" <[email-masked]>
Cc: "Guang Yao" <[email-masked]>; "'SAVI Mailing List'" 
<[email-masked]>; "'Suresh Krishnan'" <[email-masked]>; "'Greg 
Daley'" <[email-masked]>
Sent: Thursday, April 16, 2009 2:29 AM
Subject: Re: [savi] 答复: DAD as a binding distribution protocol: why not

---

From: "Jun Bi" <[email-masked]>
Date: Thu, 16 Apr 2009 08:58:16 +0800

----- Original Message ----- 
From: "Fred Baker" <[email-masked]>
To: "marcelo bagnulo braun" <[email-masked]>
Cc: "Jun Bi" <[email-masked]>; "Guang Yao" 
<[email-masked]>; "'SAVI Mailing List'" <[email-masked]>; 
"'Suresh Krishnan'" <[email-masked]>; "'Greg Daley'" 
<[email-masked]>
Sent: Thursday, April 16, 2009 2:47 AM
Subject: Re: [savi] 答复: DAD as a binding distribution protocol: why not

> related, failure modes in FCFS as well - if a datagram that was in  fact 
> the first user of an address is lost, someone else might  accidentally 
> concoct the same address and try to use it.
>
> equipment (Cisco, Extreme, and I think others) depend on DHCP  snooping, 
> which is one instance of CPS. I'm sure that there is an  occasional 
> glitch, but as near as we can tell they all in fact work to  their 
> administrator's satisfaction.

Agree!

>
> The reason we have DHCPv6 address assignment is that operators have  told 
> us they would like that to be among their options...

Yes, tasteful address assignment is better.

---

From: "Jun Bi" <[email-masked]>
Date: Thu, 16 Apr 2009 09:12:27 +0800

----- Original Message ----- 
From: "Fred Baker" <[email-masked]>
To: "marcelo bagnulo braun" <[email-masked]>
Cc: "Jun Bi" <[email-masked]>; "Guang Yao" 

> concoct the same address and try to use it.

I agree. Currently at least there 2 RFCs to support redundent duplicate 
address detections.
(it's reasonable). If we let the hosts to send the same data packets several 
times,
the operating system vednors may feel strange. And how you define the 
"first" packet?
So you may also need a state for data packets, otherwise, the host has to 
send deplicate packets
for all data packets many times. Is the state of SAVI switch of the "first" 
packet always equal to
the host's state? In control protocol, it is easy to define the state with 
clear concepts, it conforms to RFCs.
But the FCFS may affect the nature of data packets. So I think SAVI-CPS is 
in a better situation.

Certainly, the major problem of SAVI-FCFS is not only the first packet lost. 
Even the first packet is not lost,
FCFS still need a BDP, and it might be complex when we have multiple 
SAVI-swtiches
(the real-time sync requirements), we even didn't see a prototype of BDP 
yet.
But SAVI-CPS doesn't need the BDP, just need some enhancement.

thanks,
Jun Bi

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 16 Apr 2009 10:40:34 +0200

> accidentally concoct the same address and try to use it.

SAVI FCFS uses both data packets as well as ND packet for the creation 
of the binding.
In case the first packet is lost (which is probably the DAD NSOL), both 
solutions don't create a binding (cause the packet is lost). the 
different is that from then on, SAVI FCFS can create binding using data 
packets ,while SAVI CPS will simply drop all the following packets.

About the case you mention, you mean that the first packet is lost and i 
guess this would be the NSOL packet. At that moment another node sends a 
packet with that source address. If it is legitimate node, this packet 
will be the NSOL of the DAD procedure of the otgher node. The first node 
will receive that packet and reply with NADV defending its address. The 
FCFS SAVI is designed to track the whole DAD procedure, so it wouldn't 
create a binding for the new node, but will honour the first node.

If the first packet is a data packet, this is likely to be an attack. 
The problem here is that the attacker needs to be able to intercept the 
first packet and drop it (doesn't seem tto be a very useful attack to me 
to simply wait and see if the first packet is lost, i guess). So, if an 
attacker is able to intercept packet, then i guess it can launch any 
kind of attacks that i guess are out of the scope of the protection we 
designing savi for.
> told us they would like that to be among their options...

Right
I all for having a DHCP based solution (if you remember, in the last 
meeting i actually asked for that)
DHCP based snooping seems different to me. First of all, dhcp packet 
exchange is reliable, in the sense that ACK are used for the assignment. 
In case one packet is lost, there will be retrial until the packet is 
acked. So, since it is inherently more reliabel than DAD procedure, i 
believe it is much more safer to trust in dhcp snooping than in DAD 
snooping.

makes sense?

Regards, marcelo

---

From: Fred Baker <[email-masked]>
Date: Thu, 16 Apr 2009 05:40:06 -0400

On Apr 16, 2009, at 4:40 AM, marcelo bagnulo braun wrote:

> exchange is reliable, in the sense that ACK are used for the  
> assignment. In case one packet is lost, there will be retrial until  
> the packet is acked. So, since it is inherently more reliabel than  
> DAD procedure, i believe it is much more safer to trust in dhcp  
> snooping than in DAD snooping.

Well, they are both snooping on an exchange that the switch is not a  
party to, so while it may be reliable for the endpoints, it is not  
necessarily reliable for the third party.

But you are looking at different cases. With DHCP snooping, a central  
controller assigns an address to a system; with the DAD procedure, the  
assumption is that the system that originated the datagram simply sent  
it (which would happen if it had been manually configured and you were  
running FCFS), and you are dealing with what may be a configuration  
error.

If DHCP is in use, or any of the other protocols that CPS applies to,  
so be it. The address is assigned and the switch refuses any other  
source addresses. Done.

If FCFS is in use, one of three things is happening:
   - SLAAC, which implies DAD
   - Manual configuration
   - Attacks

DAD for SLAAC is intended to deal with the issue in the end system,  
which is of course the preferred option. SAVI is intended to isolate  
attacks and manual misconfigurations.

The question before the house has been what to do in a multi-switch  
network. I assert that having every SAVI switch have knowledge of  
every IPv6 address in the LAN imposes an undue burden (and therefore  
monetary cost in a market that is very cost-sensitive) on the  
switches; they do need to know about their own client systems, but not  
the clients of other switches. And they have no way of knowing the IP  
or MAC address of the switch that forwarded the conflicting datagram.  
Hence, they cannot send an error response to the specific switch in  
question.

So we have two options for dealing with attacks and manual  
misconfigurations via neighboring switches. We design a protocol and  
have the switch that detects the conflict multicast to "all SAVI  
switches" that {IPv6 Address, MAC Address} is an inappropriate  
combination, or we use some existing protocol that is intended to say  
the same thing. DAD is such a protocol, and it seems like we should be  
able to use it. Yes, the solution is not perfect. However, there is an  
attack in using multicast error responses as well - a system that  
wants to attack the network generates a long stream of erroneous  
messages, knowing that the various switches will pummel each other  
with multicasts. So that is not perfect either.

Between two imperfect solutions, I'm in favor of the unicast one that  
has a high probability of success.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 16 Apr 2009 12:22:40 +0200

> necessarily reliable for the third party.
right, but the packets are only delivered is they pass through the 
switch, so if we have two endpoints that have reliable exchange, the 
only way it can be succesfully completed, is if and only if the switch 
in the middle has forwarded the packet, hence it is also reliable for 
the middle device.

> running FCFS), and you are dealing with what may be a configuration 
right
as i said, i don't have a problem with using snooping for dhcp

> so be it. The address is assigned and the switch refuses any other 
not done
if the packet is lost, which is possible is the transport iof the packet 
is unreliable, the host is disconnected from the network, and the only 
clear way to make it work is to restart the host interface

My concren here is that if this solution is dpeloyed, the solution 
itslef will be a source of attacks to the network.

> monetary cost in a market that is very cost-sensitive) on the switches; 
i agree with that
but as i said beofre there is no need for that, you can use, as you call 
it a binding verification protocol
moreover, in simple topologies this is no needed

> they do need to know about their own client systems, but not the 
> clients of other switches. And they have no way of knowing the IP or 
> MAC address of the switch that forwarded the conflicting datagram. 

but they not need to know the mac address of the end host that has the 
source address
If i am switch a, i can ask to switch b if it knows a given source 
address. If switch b knows it, switch b only needs to know that this 
address can only come from the port connected to switch b
no need to know the mac address of the node that has this address

> able to use it.
i am lst here
are you propsoing the switches to issue DAD packets?
or simply snoop the DAD performed by the hosts?

> Yes, the solution is not perfect. However, there is an attack in using 
> multicast error responses as well - a system that wants to attack the 
> network generates a long stream of erroneous messages, knowing that 
> the various switches will pummel each other with multicasts. So that 
> is not perfect either.
>
but the analysis is not as simple as both are imperfect, but we need to 
understand what are the consequences of the failure modes
my worry is that the consequence of SAV CPS failure modes are serious

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 16 Apr 2009 12:29:11 +0200

Jun Bi escribió:
> 1 the packet loss rate in a local link scope might be very low.
Depends on what type of environment you are i guess.
and the problem, is that the consequences of loosing this first packet,
are very serious, i.e. the host gets disconnected from the network.

> 2 if a SAVI swtich is deployed, the operator could ask the user of
> host to configure a little.
I am not sure what you mean by that, but we are supposed to define a
solution that doesn't require to touch the hosts.
If host configuration is required, i think the deployability of the
solution would be greatly reduced
> 3 by experiements, we did see no problem when link is up and down.

+-------+
|HOST |
+-------+
|
+------------------+
|LEGACY SWITCH |
+------------------+
|
+------------------+
|SAVI CPS DEVICE |
+------------------+
|
+----------------+
|REST of WORLD |
+----------------+

I understand this can be a very common configuration, for instance when
the SAVI fucntion i located in the router rahter 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

Regards, marcelo

> Jun
> Cc: "Guang Yao" <[email-masked]>; "'SAVI Mailing
> List'" <[email-masked]>; "'Suresh Krishnan'"
>>>>>>> In your scenario, no node pair has collision address, why should
>>>>>>> the
>>>>>>> NSOL be

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 16 Apr 2009 12:39:53 +0200

Jun Bi escribió:
>
> ----- Original Message ----- From: "Fred Baker" <[email-masked]>
> <[email-masked]>; "'SAVI Mailing List'" 
> <[email-masked]>; "'Suresh Krishnan'" <[email-masked]>; 
> "'Greg Daley'" <[email-masked]>
>> Yes, failure modes create issues. I can think of some interesting, 
>> and related, failure modes in FCFS as well - if a datagram that was 
>> in  fact the first user of an address is lost, someone else might  
> I agree. Currently at least there 2 RFCs to support redundent 
> duplicate address detections.
as i said earlier, the default value of rfc4862 is 1 NSOL for DAD

> (it's reasonable). If we let the hosts to send the same data packets 
> several times,
SAVI FCFS don't need to send the msae4 packet multiple times
If a packet is lost, it will create the state using the next packet, 
doesn't have to be the same one

> the operating system vednors may feel strange. And how you define the 
it is the first packet the savi device sees

> So you may also need a state for data packets, otherwise, the host has 
> to send deplicate packets
> for all data packets many times. Is the state of SAVI switch of the 
> "first" packet always equal to
> the host's state?
no, hosts don't change anything
if the first apcket is lost, savi creates state witht he next packet

> In control protocol, it is easy to define the state with clear 
> concepts, it conforms to RFCs.
> But the FCFS may affect the nature of data packets. So I think 
> SAVI-CPS is in a better situation.
>
no, SAVI FCFS doens't change the nature of data packets

> Certainly, the major problem of SAVI-FCFS is not only the first packet 
> lost. Even the first packet is not lost,
i agree that needing a BDP is painful, no questions about that
OTOH, switches already run protocols, such as STP, or trill

the question is whether we can avoid that complexity and still have a 
reasonably safe solution
I don't think this is the case

> (the real-time sync requirements), we even didn't see a prototype of 
> BDP yet.
check the other email i sent you with a different failure mode affecting 
one of main SAVI targetted scenario,

regards, marcelo

---

From: Christian Vogt <[email-masked]>
Date: Wed, 22 Apr 2009 21:39:33 -0700

On Apr 15, 2009, Jun Bi wrote:

> lost. Even the first packet is not lost, FCFS still need a BDP, and it
> might be complex when we have multiple SAVI-swtiches (the real-time  
> sync
> requirements), we even didn't see a prototype of BDP yet. But SAVI-CPS
> doesn't need the BDP, just need some enhancement.

Jun and all -

When comparing FCFS and SAVI-CPS, we should be careful not to mix
DHCP-based and SLAAC-based address configuration.

It is true that SAVI-CPS, or control-packet-only snooping in general,
may not need a BDP in the case of DHCP-assigned addresses.  Thanks to
the acknowledged address assignment exchange, the lack of an address
binding in a SAVI device then implies with high reliability that packets
locally originating from this address should be dropped.

But in the case of addresses auto-configured via SLAAC, snooping only
control packets doesn't have the same effect.  Since there is no
acknowledged address assignment exchange, the lack of an address binding
in a SAVI device does NOT imply that packets locally originating from
this address should be dropped.  I.e., the best a SAVI device can do in
this case is let such packets through.  And the scenario that Marcelo
had illustrated earlier shows that this may lead to a vulnerability.
  Hence, control-packet-only snooping in SLAAC could in some cases
benefit from a BDP, independent of whether you use FCFS or SAVI-CPS.

So the issue with SLAAC-based address configuration is the same whether
we use FCFS or SAVI-CPS -- independent of whether we believe that this
issue justifies the development of a BDP.

- Christian

---

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

Christian Vogt escribió:
>> might be complex when we have multiple SAVI-swtiches (the real-time sync
Right

> benefit from a BDP, independent of whether you use FCFS or SAVI-CPS.
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 |
+----------------+

the SAVI function is located in the router rahter than in the switch(this

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)

---

From: Christian Vogt <[email-masked]>
Date: Thu, 23 Apr 2009 09:23:25 -0700

On Apr 23, 2009, marcelo bagnulo braun wrote:

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

Yes, this is an issue.

It might be worthwhile to check if the Multicast Listener Discovery
protocol can be used by a rebooting SAVI device to rebuild its previous
state.  We might find MLD General Queries useful for this purpose.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Thu, 23 Apr 2009 20:38:47 -0700

Eric -

You have a very good point.  Since we are changing switches anyway,
changing also the way they forward Neighbor Solicitation messages for
DAD should be feasible.

This said, a disadvantage of a DAD-based binding distribution or
verification protocol, if you use the Neighbor Solicitation messages,
is that it becomes a push protocol.  This has the issue that it may
require a lot of state in SAVI devices.  Fred explained several good
reasons why this is problematic.

- Christian

On Apr 15, 2009, Eric Levy-Abegnoli wrote:

> Marcelo, The function that would prevent SWITCHA to forward DAD  
> packets
> to SWITCHB in this scenario is_not_dictated by RFC4862 or even RFC3810
> port where no join was seen. It looks to me that in this scenario, for
> switches doing mld snooping, it would not be un-reasonnable to have a
> configuration option on SWITCHA to enable copy of multicast traffic on
> its trunks regardless of snooped groups. SWITCHB could still decide  
> not
> to deliver the traffic to any device if nobody joined the group. That
> would enable DAD to be usable as a binding distribution protocol. Eric