Subject: [savi] A different trade off for SAVI

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 07 Jun 2009 20:59:07 +0200

Over the last few weeks, we have been discussing different approaches
for SAVI to be used in conjunction IPv6 stateless address autconfiguration.
the different proposed approaches have different pros and cons, due to
different tradeoffs being made.
In this email, i describe an intermediate approach that may be worth
to be considered.

So, i will first try to summarize the design questions that we have
been considering.
The first question is whether we create bindings using only DAD packets
or we also create bindings using data packet.
Creating bindings only with DAD packets, imposes the questions about
what can be done when a packets with a source address for which there
is no binding.
One option would be discard the packet. The problem with this approach
is that legitimate packets can be drop. In particular, DAD is not a
reliable protocol, so it is possible that DAD packets are lost and
do not reach the SAVI device. Similarly, it is also possible that a
SAVI device reboots, which would imply that the bindings are lost and
since the host may not perform the DAD again, legitimate packets would
be lost.
It is important to quantify this risk. In my personal opinion, the risk
is high enough that i am not comfortable designing a SAVI solution
that will discard legitimate packets. OTOH, it is likely that in an
important number of cases, the DAD messages are actually delivered and
the SAVI device creates the binding using them.

So, we return to the initial question about what do we do with data
packets containing a source address for which there is no binding.
As i mentioned, the other option is to create a binding. The drawback of
that approach is that we need to distribute the binding information
to the other SAVI devices, so that the configure the binding. (I am
here assuming that the DAD messages are in general distributed to all
the SAVI devices in the link. In order to do so, we need to require
that the SAVI devices receive the packets for all solicited nodes
multicast groups, but i understand this is feasible). So, it seems
than that in order to distribute the bindings created by the corner case
that the DAD packet is lost, we need to require the usage of a SAVI
protocol to exchange binding data.

If we don't think that discarding them is acceptable and we
think that creating a SAVI protocol is an overkill for supporting the
case where the DAD packets were lost, we may want to consider a middle
ground option.

An intermediate option would be to simply forward (and eventually log)
data packets with source address for which there is no binding.

So, let me expand on this. The behaviour of this approach would be:
If DAD exchange is detected by the SAVI device, a binding is created.

If a data packet containing a source address for which a binding exists
and the same lower layer anchor is received, then the packet is forwarded.

If a data packet containing a source address for which a binding exists
and a different lower layer anchor is received, then the packet is drop.

If a data packet containing a source address for which no binding exists
the data packet is forwarded and optionally logged.

So what are the security properties of such a solution?

If a host starts using an address and performs the DAD procedure, then
no other host can use its address as a source address in data packets.

An attacker can start using an address for which there is no binding.
In order for this address to be the address of another host, this
can only happen if the DAD packet was lost. I am not sure how concerned
should we be about preventing this from attackers that have the
capability of disturbing DAD, I mean, if they are able to do that,
i guess they can launch worse attacks than spoof a source address.
An attacker can use a given address from different lower layer anchors.
I am not sure why this would be an attack though. As i said earlier
it would be possible for the SAVI device to log the occurrence of these
packets and allow to trace back to the lower layer anchor.

So, this option seems like a middle ground option with a somehow reduced
level of security but with a low level of complexity and without
the possibility of disturbing the network behaviour by discarding
legitimate packets.

Comments?

Regards, marcelo

---

From: ZhangDong <[email-masked]>
Date: Mon, 08 Jun 2009 10:35:15 +0800

>  the data packet is forwarded and optionally logged.
Agree. The basic principle is not to disturb the legitimat packets. So forwarding is the reasonable choice. However, it seems that there is something different with my view. I already have stated my view in the last mail. The difference is that for the data packet with no binding exists, whether the savi device creats binding with a special mark first, then forwards and logs.
I think in this way, we could look at this kind of the data packet binding with mark as a temporary binding. If the source address in the data packet is really used by a legitimate user, we could eliminate the special mark of the binding under some conditions (the conditions need to be considered.). Then it become the normal binding in the table.
Imho, it seems that it is better than just forwarding without a binding. Because for the legitimate use of a source, it can not be disbelieved forever. Is that feasible?

Thank you.

Dong Zhang

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 08 Jun 2009 09:25:27 +0200

> Agree. The basic principle is not to disturb the legitimat packets. So forwarding is the reasonable choice. However, it seems that there is something different with my view. I already have stated m…
As i mentioned in the previous email, you can certainly log info about 
these packets in order to allow traceability. This is a tradeoff between 
memory and security.

> I think in this way, we could look at this kind of the data packet binding with mark as a temporary binding. If the source address in the data packet is really used by a legitimate user, we could e…

the problem with that is that the binding would only exist in the 
devices that have forwarded this packet and not the others. So, we could 
create a binding, even from the first packet and also discard packets 
based on this binding. The difference is that this particular binding is 
likely not the be in all the savi devices, so the degree of security for 
this binding is lower than the ones created by DAD.

So, one option would be to create the bindings as normal bindings and 
discard the packets that come with a different lower layer anchor. the 
basic difference is the scope of the protection. DAD created bindings 
are protected by all the SAVI devices, while data packet created 
bindings are only protected by the SAVI devices that forwarded the packet.
The potential problem with this is inconsistent bindings. I.e. a SAVI 
device creates one binding using a data packet, and another savi device 
creates a different binding with a different data packet. This may 
create problems. In particular, with respect to mobility.
> Imho, it seems that it is better than just forwarding without a binding. Because for the legitimate use of a source, it can not be disbelieved forever.
it is not a problem of believing or not. It is a problem of the scope of 
the protection.

Regards, marcelo

>  Is that feasible?

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Mon, 08 Jun 2009 16:37:21 +0200

> or we also create bindings using data packet.
There is something "in-between" DAD and data: other NDP messages. If the 
savi device misses the DAD packet, chances are that the binding owner 
will soon send another NDP message. Typically, it will send an NA to 
all-nodes. It will also at some point have to resolve its neighbors 
addresses. Those messages are not "required" by the protocol, or they 
could happen prior to DAD for a given address. However, snooping them 
(and using them for build the binding table) will greatly  lower the 
chances that the binding  was missed..

For end-nodes attached to the savi switch via an access port, it is not 
un-reasonnable to assume that the switch should have learn a binding 
prior to see a data packet carrying it.
However, when the end-node is attached to the savi switch_A via another 
switch_B (trunk port), this maybe  problematic. Because the savi 
switch_A could typically come up long after switch_B and all nodes 
attached to switch_B have already done DAD etc. Chances that switch_A 
missed the bindings are much higher than the one of a DAD packet getting 
lost.
One policy for switch_A could be to not_drop anything coming over a 
"savi-trunk", a trunk connected to a savi-device, relying on switch_B to 
drop traffic from the node "directly-attached" to it (if no binding is 
available). That way you don't really need to have the switches 
synchronysing their binding table.
The scenario where switch_B is not a savi-device does not fit at all 
there though.
> since the host may not perform the DAD again, legitimate packets would
If the SAVI device is the switch that attaches the end-nodes, the 
interface will go down, and the DAD will happen again.
In addition, I think we should assume that is it the responsability of 
the implementation to preserve its states during a reboot. There are 
countless techniques to do that, and accepting this is an implementation 
problem would greatly simplify the problem.
> the possibility of disturbing the network behaviour by discarding
Logging is useful, but not practical in case of an attack; Especially 
logging on data-packet events. Switches/routers are usually very 
efficient at droping, and very in-efficient at logging, as the latter 
requires to go very high in the software stack. So you would actually 
help the attacker there.

I think relying on NDP snooping (DAD+other NDP) is a viable short-term 
solution. And droping traffic when no binding is recorded is the core of 
what we are trying to achieve, isn't it?
On the longer term, a pro-active scheme that would have the hosts 
announcing their binding would be safer. I'd suggest to re-use something 
like draft-thubert-3122bis-01.txt (InverseND+) rather than re-inventing 
something new.
Another aspect that would be worth discussing the binding table 
replacement algorithm, or which biding should be preferred in case of 
collision.  First-come first serve does not work well in a number of 
basic scenarios (movement, multiple switches, etc.).  I proposed a 
different algorthm (draft-levy-abegnoli-savi-plbt-00.txt). Feel free to 
comment.
Eric
>
> Regards, marcelo
>
>
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 08 Jun 2009 16:59:05 +0200

Eric Levy-Abegnoli escribió:
> There is something "in-between" DAD and data: other NDP messages. If 
> the savi device misses the DAD packet, chances are that the binding 
> owner will soon send another NDP message. 
you could go down the paht the SAVI device looks into every ND packet 
and interprets them and based on that it infers who is the owner of each 
address. The problem here is that we will need to make inferences from 
different ND packets, depending on how they are dsitributed (i.e. 
depending if they are send to all nodes, to a multicast group or to a 
node). That would essentially imply that any change in the ND spec would 
potentially have an impact on the SAVI spec and it would result in 
hardcoding the current ND behaviour. BEsides, the complexity increases 
since each ND exchange need to be tracked uan understood by the SAVI 
device to properly infer the resulting binding.
> Typically, it will send an NA to all-nodes. 
what NA would that be?

> It will also at some point have to resolve its neighbors addresses. 
> Those messages are not "required" by the protocol, or they could 
> happen prior to DAD for a given address. However, snooping them (and 
> using them for build the binding table) will greatly  lower the 
> For end-nodes attached to the savi switch via an access port, it is 
> not un-reasonnable to assume that the switch should have learn a 
> binding prior to see a data packet carrying it.
> However, when the end-node is attached to the savi switch_A via 
> another switch_B (trunk port), this maybe  problematic. Because the 
> savi switch_A could typically come up long after switch_B and all 
> nodes attached to switch_B have already done DAD etc. Chances that 
> switch_A missed the bindings are much higher than the one of a DAD 
> packet getting lost.
right, so are you arguing that a solution that solely relies on DAD is 
not enough in your opinion?

> "savi-trunk", a trunk connected to a savi-device, relying on switch_B 
> to drop traffic from the node "directly-attached" to it (if no binding 
> is available). That way you don't really need to have the switches 
but it would imply that you need to configure which ports are connected 
to hosts and which ones are connected to other savi devices, right?
and that is likely to be a manual configuration, right?
and if the topology changes you would need to update that, correct?

> interface will go down, and the DAD will happen again.
this is not required by rfc4862 (but i agree that normally happens)

> countless techniques to do that, and accepting this is an 
> implementation problem would greatly simplify the problem.
i don't think it is acceptable to rely on this for not blocking 
legitimate users from sending traffic.

> requires to go very high in the software stack. So you would actually 
i think logging is an essential part of SAVI actually
I think that the main benefit of SAVI is to know which port was 
associated to a given source address at some point in time, so that 
attackers can be traced back.

I mean, SAVI does not define any restriction for getting access to an 
unused address. The main point is to prevent the use of somebody elses 
address and to use addresses in an anonymous fashion

> solution. And droping traffic when no binding is recorded is the core 
> of what we are trying to achieve, isn't it?
i don't think so.... what attack you would be preventing in that case?
Dropping packets coming from a different lower layer anchor is in the 
core of savi, but dropping packets with no bindings, it is not obvious 
to me what is provided by that... i mean, the attacker only needs to 
create a binding and send the packet, so what is the benefit?

> announcing their binding would be safer. I'd suggest to re-use 
> something like draft-thubert-3122bis-01.txt (InverseND+) rather than 
> re-inventing something new.
> basic scenarios (movement, multiple switches, etc.).

how come FCFS doesn't work well in movement? (in multiple switches, the 
fcfs behaviour is what we are currently discussing, but it can work, we 
just need to agree on the tradeoffs)

Regards, marcelo

>   I proposed a different algorthm 
> (draft-levy-abegnoli-savi-plbt-00.txt). Feel free to comment.
> Eric
>>
>> Regards, marcelo
>>
>>

---

From: Christian Vogt <[email-masked]>
Date: Tue, 9 Jun 2009 19:50:01 -0700

On Jun 7, 2009, marcelo bagnulo braun wrote:

> for SAVI to be used in conjunction IPv6 stateless address
> autconfiguration. the different proposed approaches have different  
> pros
> and cons, due to different tradeoffs being made. In this email, i
> describe an intermediate approach that may be worth to be  
> considered...

Marcelo -

Thanks for proposing this compromise between DAD-only binding
establishment and DAD-plus-data binding establishment.  This is very
interesting, as it may take us out of the dilemma of either having to
cause false packet drops occasionally, or having to specify a binding
distribution protocol.

Thanks also for the analysis on your proposal.  It is clear that, as you
say, the security level of your proposed compromise will be lower than
the security of both the current FCFS variant (DAD-plus-data binding
establishment) and CPS (DAD-only binding establishment).  But it
certainly is in line with the original idea for SAVI, which was to
create a simple security improvement that "does no harm".  In fact,
your proposed compromise is even more in line with this original idea
than the current FCFS variant and CPS are, because (a) it is simpler
than the current FCFS variant due to the latter's reliance on a binding
distribution protocol, and (b) it does less harm than CPS due to CPS's
occasional false packet drops.

Of course, more analysis would be useful.  Dong Zhang and Eric already
contributed their useful thoughts; I'd encourage also others to share
their opinion.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Tue, 9 Jun 2009 20:06:20 -0700

On Jun 9, 2009, Christian Vogt wrote:

> contributed their useful thoughts [...]

Sorry, I should have said:  "Dong Zhang, Eric, /and Fred/ already
contributed their useful thoughts..."

- Christian

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Wed, 10 Jun 2009 13:51:05 +0200

marcelo bagnulo braun a écrit :
>>> autconfiguration.
> and interprets them and based on that it infers who is the owner of 
> each address. The problem here is that we will need to make inferences 
> from different ND packets, depending on how they are dsitributed (i.e. 
> node). That would essentially imply that any change in the ND spec 
> would potentially have an impact on the SAVI spec and it would result 
> in hardcoding the current ND behaviour. BEsides, the complexity 
> increases since each ND exchange need to be tracked uan understood by 
> the SAVI device to properly infer the resulting binding.
Not every packets. packets carrying binding information. And credentials 
(CGA, ...). Relying on the sole L2 information of DAD packets is going 
to lead to approximations that will then lead to loose decisions.
>> Typically, it will send an NA to all-nodes. 
7.2.6.  Sending Unsolicited Neighbor Advertisements

It's not "required". However, pretty much all IPv6 implementations are sending NA to "all nodes" with override nit on, when the interface goes up.

> not enough in your opinion?
I am arguing that if we look at more than DAD packets, we decrease the 
already low chances that the information is missed.  Making sure the L2 
and L3/LLA are consistent has also some value.
>> to drop traffic from the node "directly-attached" to it (if no 
>> binding is available). That way you don't really need to have the 
>> switches synchronysing their binding table.
> but it would imply that you need to configure which ports are 
> connected to hosts and which ones are connected to other savi devices, 
> right?
Indeed. But configuration recommendation is not excluded from 
specification, is it? Can have defaults. In the absence of such 
configuration, we either need a protocol to signal the type of device 
connected, or assume the worse case. In that case, the two switches 
scenario is very broken.
> this is not required by rfc4862 (but i agree that normally happens)
Because it would be broken otherwise.
>
>>
>> In addition, I think we should assume that is it the responsability 
>> of the implementation to preserve its states during a reboot. There 
>> are countless techniques to do that, and accepting this is an 
There are many stateful protocols that just cannot afford to loose their 
state on box failure. Assuming this is outside the scope of the 
specification will give us a chance to specify something useful.
Note that I don't however suggest to block traffic if we don't have a 
binding (for instance because the box lost its state).
> address and to use addresses in an anonymous fashion
Logging does not prevent the use of somebody else address. In some real 
life scenarios, we will be logging dozen of thousands messages per 
second. They won't be human readable in real-time.
And logging can be easily attacked, and rendered un-usable. So it's 
certainly part of the solution, but is not enough in my opinion.  
>
>> I think relying on NDP snooping (DAD+other NDP) is a viable 
>> short-term solution. And droping traffic when no binding is recorded 
>> is the core of what we are trying to achieve, isn't it?
I meant conflicting bindings.Not no bindings. My mistake
> how come FCFS doesn't work well in movement? (in multiple switches, 
> the fcfs behaviour is what we are currently discussing, but it can 
> work, we just need to agree on the tradeoffs)
What tradeoffs?  I think tradeoffs means moving away from fcfs. If there 
are cases where the "second come" should replace the binding, and I 
think there are many such cases, then it's no longer 
first-come-first-serve. And we should describe this in various 
scenarios, because the devil is in the details.
Eric

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 11 Jun 2009 06:05:01 -0400

Eric Levy-Abegnoli escribió:
>> each address. The problem here is that we will need to make 
>> inferences from different ND packets, depending on how they are 
>> dsitributed (i.e. depending if they are send to all nodes, to a 
>> multicast group or to a node). That would essentially imply that any 
>> change in the ND spec would potentially have an impact on the SAVI 
>> spec and it would result in hardcoding the current ND behaviour. 
>> BEsides, the complexity increases since each ND exchange need to be 
>> tracked uan understood by the SAVI device to properly infer the 
>> resulting binding.
> Not every packets. packets carrying binding information. And 
> credentials (CGA, ...). Relying on the sole L2 information of DAD 
> packets is going to lead to approximations that will then lead to 
> loose decisions.

mmm, i think we will always end up in somehow loose decisions... I mean, 
SAVI is guessing and infering from the traffic it sees, It is likely 
that it will guess wrong sometimes.
So, for me the question is not whether we will have loose decision, but:
- What is the tradeoff between complexity of tracking the different 
packets for infer bindings and how accurate the guess will be
- towards which side do we err i.e. we discard too much or we let too 
many packets pass

> It's not "required". However, pretty much all IPv6 implementations are 
> sending NA to "all nodes" with override nit on, when the interface 
> goes up.
>
mmm, what would happen if an attacker sends one of these packets for a 
target address that it is not his own?
>> right, so are you arguing that a solution that solely relies on DAD 
>> is not enough in your opinion?
> already low chances that the information is missed.  Making sure the 
> L2 and L3/LLA are consistent has also some value.

right, that is certianly true. My question is how much complexity are we 
willing to accept and how much gain do we get from this
>>> "savi-trunk", a trunk connected to a savi-device, relying on 
>>> switch_B to drop traffic from the node "directly-attached" to it (if 
>>> no binding is available). That way you don't really need to have the 
>> connected to hosts and which ones are connected to other savi 
>> devices, right?
> specification, is it?
no, it is not excluded.
I personally think it is important to keep it to a maximum if we want to 
see this deployed, but it is certainly up for discussion

> Can have defaults. In the absence of such configuration, we either 
> need a protocol to signal the type of device connected, 
how do you secure such a protocol?
Probably any acceptable security will require some confuguration afaics

> or assume the worse case. In that case, the two switches scenario is 
> very broken.
>>
>>>
why do you say so?
AFAIK, rfc4862 is on purpose vague on this case, in order to allow not 
doing DAD in this case

> There are many stateful protocols that just cannot afford to loose 
> their state on box failure. Assuming this is outside the scope of the 

So this basically imply that if we receive a data packet for which we 
don't have a binding for, then we cannot discard it, right?
So what do we do with this data packet?
>>> Logging is useful, but not practical in case of an attack; 
>>> Especially logging on data-packet events. Switches/routers are 
>>> usually very efficient at droping, and very in-efficient at logging, 
>>> as the latter requires to go very high in the software stack. So you 
>>> would actually help the attacker there.
>>>
>> unused address. The main point is to prevent the use of somebody 
>> elses address and to use addresses in an anonymous fashion
> Logging does not prevent the use of somebody else address.
right, logging helps with the second part, using an address in an 
anonymous fashion

> In some real life scenarios, we will be logging dozen of thousands 
> messages per second. They won't be human readable in real-time.
that is true if you don't know what you are looking for.
In this case, if an attack has occur using a given address, you would be 
looking the L2 anchor bound to the source address used in the attack at 
a given moment. That information should be easy to get from a log, even 
a very large one

> certainly part of the solution, but is not enough in my opinion.  

enough for what?
I think this is probably the best we can do for preventing anonymous use 
of an address...  what else can we do?
>> core of savi, but dropping packets with no bindings, it is not 
>> obvious to me what is provided by that... i mean, the attacker only 
>> needs to create a binding and send the packet, so what is the benefit?
ok

>>> replacement algorithm, or which biding should be preferred in case 
>>> of collision.  First-come first serve does not work well in a number 
>>> of basic scenarios (movement, multiple switches, etc.).
>>
> What tradeoffs?  I think tradeoffs means moving away from fcfs. If 
> there are cases where the "second come" should replace the binding, 
mmm, in the case of movement, this is only true when there is nobody 
replying in the first binding, right?
or, do you have other cases in mind?

> and I think there are many such cases, then it's no longer 
right, could you describe the scenarios you have in mind?

Regards, marcelo

---

From: Christian Vogt <[email-masked]>
Date: Thu, 11 Jun 2009 14:23:27 -0700

Eric and Marcelo -

Reading the email exchange between you two, I am making the following
conclusions:  Using control packets other than DAD to infer address
ownership could indeed help reducing the probability of false packet
drops.  But what should be carefully evaluated is:

- How much complexity would this add to the SAVI protocol?

- Would this introduce new vulnerabilities?

In particular the latter seems problematic to me.  If we were to use
control packets other than DAD to infer address ownership, how would we
prevent spoofing of those control packets?  Keep in mind that, unlike
many other control packets, DAD has the nice property that it gives
the victim of a spoofing attack a chance to speak up.  This increases
the bar for spoofing DAD packets.

- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 13 Jun 2009 12:05:28 +0200

> the bar for spoofing DAD packets.

right
it _may_ be worth considering a few other packets. For instance, the 
unsolicited NAdv Eric was mentioning may be worth considering, but 
again, a detailed analyis as the one we have been doing for DAD is needed.
Eric, do you have other msgs that you think would be worth considering?

Regards, marcelo

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Mon, 15 Jun 2009 08:40:46 +0200

Christian ,
> the bar for spoofing DAD packets.
I am a bit confused here, or maybe I lack some background of previous 
discussions. Look to me there is a tradeoff; almost an antagonism 
between prefering the first binding (hence the first packet carrying 
this binding) and allowing nodes to defend their address. It's pretty 
trivial for the attacker to listen to the DAD from his victim, and 
answer as soon as he sees it. And then take ownership of the binding if 
I read you correctly.
Note that many switches won't do mld snooping and simply (hardware) 
broadcast messages to solicited node multcast addresses to all nodes.
So did this group agree that the DAD responder should have his binding 
preferred over the DAD sender? If so, how can this be an anti-spoofing 
protection mechanism?
And of course, if not, DAD is broken. Unless, we assume the switch 
should have seen the DAD responder own DAD message earlier on (to the 
exception where it could have been lost).But then its the swich dending 
the address, not the node. .
It all come back to what I described in PLBT, that is a preference 
algorithm for managing collisions: sometimes collision are real one, 
sometime they are attacks, and it's true for DAD and any other NDP messages.
When receiving a DAD response carrying a different binding that the DAD 
request, should the switch
- prefer it, and expose itself to simple DAD attack
- prefer the binding of the DAD request, and expose itself to break DAD, 
if it missed an hypothetical  earlier DAD request from this DAD responder
I would strongly prefer the latter, except that the DAD responder could 
be behind a second switch booted long time before. Hence my proposal to 
prefer binding carried by DAD sender when they are directly atachedn but 
binding carried by DAD responder when they are attached via a second switch.
Eric

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 15 Jun 2009 09:31:58 +0200

Eric Levy-Abegnoli escribió:
> answer as soon as he sees it. And then take ownership of the binding 
> if I read you correctly.
this is an attack against DAD and not against savi
I mean, if the attacker replies, what will happen is that the node will 
try another address and perform DAD again.
In that sense, the attacker is not stealing the node's addresses since 
the node has not configured the address yet.

right

> preferred over the DAD sender? If so, how can this be an anti-spoofing 
i guess this was agreed when DAD was defined. I mean, DAD states that if 
a node replies the NSOL during DAD, the node performing DAD will try a 
different address

> exception where it could have been lost).But then its the swich 
> dending the address, not the node. .
> When receiving a DAD response carrying a different binding that the 
> DAD request, should the switch
> - prefer the binding of the DAD request, and expose itself to break 
> DAD, if it missed an hypothetical  earlier DAD request from this DAD 
> responder
but that would imply that DAD does no longer work, right? I mean, if the 
SAVI always preffer the initial NSOL of the DAD, then, if there is a 
colision, we are not honoring the node that originally got the address

Regards, marcelo

>
> I would strongly prefer the latter, except that the DAD responder 
> could be behind a second switch booted long time before. Hence my 
> proposal to prefer binding carried by DAD sender when they are 
> directly atachedn but binding carried by DAD responder when they are 
> attached via a second switch.
> Eric
>>
>> - Christian
>>
>>
>>
>
>

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Mon, 15 Jun 2009 10:05:50 +0200

marcelo bagnulo braun a écrit :
> I mean, if the attacker replies, what will happen is that the node 
> will try another address and perform DAD again.
This is a fairly subtil distinction that attacker will certainly 
exploit. Most nodes will do DAD everytime the interface got down/up, 
even though that is not absolutely required by the protocol. And 
interface go down/up pretty commonly these days, with notebooks moving 
around. So the switch will blindly replace its "old" binding by the one 
of the DAD responder?  Then it will endup with an illegitimate binding. 
So it is also a victim, not just the end-node.
>> So did this group agree that the DAD responder should have his 
>> binding preferred over the DAD sender? If so, how can this be an 
>> anti-spoofing protection mechanism?
> i guess this was agreed when DAD was defined. I mean, DAD states that 
> if a node replies the NSOL during DAD, the node performing DAD will 
> try a different address
>
>>
> but that would imply that DAD does no longer work, right? I mean, if 
> the SAVI always preffer the initial NSOL of the DAD, then, if there is 
> a colision, we are not honoring the node that originally got the address
If we don't drop, we haven't changed DAD. If we log, we log the 
attacker, not the original owner.
Regards,
Eric

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 15 Jun 2009 16:40:17 +0200

Eric Levy-Abegnoli escribió:
>>> I am a bit confused here, or maybe I lack some background of 
>>> previous discussions. Look to me there is a tradeoff; almost an 
>>> antagonism between prefering the first binding (hence the first 
>>> packet carrying this binding) and allowing nodes to defend their 
>>> address. It's pretty trivial for the attacker to listen to the DAD 
>>> from his victim, and answer as soon as he sees it. And then take 
>>> ownership of the binding if I read you correctly.
>> In that sense, the attacker is not stealing the node's addresses 
>> since the node has not configured the address yet.
> even though that is not absolutely required by the protocol.
but again, this is not an attack against SAVI, but an attack against DAD 
itself. this is not introduced nor amplified by SAVI.
So, one could ask the question whether SAVI could/should do something 
about it.
I would say that this vulnerability is well know and documented and the 
solution to this already exists and it is SEND

> And interface go down/up pretty commonly these days, with notebooks 
> moving around. So the switch will blindly replace its "old" binding by 
> the one of the DAD responder?  Then it will endup with an illegitimate 
> binding. So it is also a victim, not just the end-node.
So, first of all, would it make sense to keep the old binding?
I mean, the host that is performing DAD will not keep on using the 
address, cause the DAD has failed, right? So why is it useful to keep 
the old binding?

The SAVI device could have memroy and if the binding was initially 
created through DAD and if now DAD fails for the same lower layer 
anchor, it may be likely that an attacker is attacking DAD and SAVI 
could react to that, but i am not sure how useful would that, since the 
host will not configure the address cause DAD have failed.

Regards, marcelo

>>> should have seen the DAD responder own DAD message earlier on (to 
>>> the exception where it could have been lost).But then its the swich 
>> the SAVI always preffer the initial NSOL of the DAD, then, if there 
>> is a colision, we are not honoring the node that originally got the 
>> address

---

From: Frank Xia <[email-masked]>
Date: Mon, 15 Jun 2009 10:41:39 -0500

Hi Marcelo

Please check my inline comments.

BR
Frank

----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "SAVI Mailing List" <[email-masked]>
Sent: Sunday, June 07, 2009 1:59 PM
Subject: [savi] A different trade off for SAVI

> the SAVI device creates the binding using them.

Frank=>IMHO, DAD only is not feasible.  DAD procedure in IPv6
operation is only a SHOULD, not a MUST.

> packets containing a source address for which there is no binding.

Frank=>I propose that  SAVI devices manipulate  ND protocol
to establish a binding  triggered by the data packets.

> protocol to exchange binding data.
Frank=>Distributing of SAVI states among switches
seems to introduce extra complexity to switchs. However, if we try to
do so, probably we can consider that rotuers distribute
the information to switchs.  I assume  routers have authorative
binding information.

> data packets with source address for which there is no binding.
Frank=>This is not helpful.  Operators are now in the middle of alarm sea.
There are too many alarms to handle.  We just offload our due work to our
miserable maintenance colleagues :-)

> So what are the security properties of such a solution?
Frank=>Logging flood  could be exploited by malicious people
for attacking.

> can only happen if the DAD packet was lost. I am not sure how concerned
Frank=>Rogue hosts could deliberately ignor DAD procedure.

> i guess they can launch worse attacks than spoof a source address.
Frank=>I agree this philosophy.  It is not necessary for us to have a
perfect SAVI solution to deal with all the threats.  At the same time,
I prefer letting packet pass if we could not decide if it is a legitimate
packet.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 15 Jun 2009 18:01:49 +0200

Frank Xia escribió:
> ----- Original Message ----- From: "marcelo bagnulo braun" 
> <[email-masked]>
I am kind of confused here.
DAD is a MUST for stateless address autoconf
My problem is that DAD packet may get lost, are we talking about the 
same thing here or not?

> to establish a binding  triggered by the data packets.
you mean other ND msgs than DAD? which ones?

> the information to switchs.  I assume  routers have authorative
how come the routers have the auhtoritative information?

> There are too many alarms to handle.
the goal of this would not be to trigger an alram but to allow to trace 
back the lower layer anchor in case the packet was used in an attack.

>   We just offload our due work to our
sure, but i am not sure i see any other way to allow tracking back 
attacks...

> Frank=>Rogue hosts could deliberately ignor DAD procedure.
so? what woudl the impact of this?

> I prefer letting packet pass if we could not decide if it is a legitimate
good

regards, marcelo

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Mon, 15 Jun 2009 18:32:33 +0200

marcelo bagnulo braun a écrit :
> but again, this is not an attack against SAVI, but an attack against 
> DAD itself. this is not introduced nor amplified by SAVI.
> I would say that this vulnerability is well know and documented and 
> the solution to this already exists and it is SEND
I think SAVI has the opportunity to provide some benefits (SeND based 
whenever applicable) comparable to SeND, but protecting the entire 
community of nodes on the link at once.
Including those with no SeND.
>> moving around. So the switch will blindly replace its "old" binding 
>> by the one of the DAD responder?  Then it will endup with an 
>> illegitimate binding. So it is also a victim, not just the end-node.
If an attacker can so easlily put its own binding into the table (for 
instance sending a DAD message every X seconds until one is installed 
because the original owner has gone), then the switch become no more 
than a registration chamber. With nothing to say about who is good and 
who is bad.
I think we have a fundamental difference on the goals. I think that the 
switch should make decisions on what gets in (the binding table) and 
what does not, as well as how long it stays there, not fully coupled 
with end-nodes view. (I don't mean not_coupled).
regards
Eric
> could react to that, but i am not sure how useful would that, since 
> the host will not configure the address cause DAD have failed.
>
> Regards, marcelo
>
>
>>>
>>> i guess this was agreed when DAD was defined. I mean, DAD states 
>>> that if a node replies the NSOL during DAD, the node performing DAD 
>>> will try a different address
>>>
>>>>
>>>> algorithm for managing collisions: sometimes collision are real 
>>>> one, sometime they are attacks, and it's true for DAD and any other 
>>>> NDP messages.
>>>> DAD, if it missed an hypothetical  earlier DAD request from this 
>>>> DAD responder
>>>> directly atachedn but binding carried by DAD responder when they 
>>>> are attached via a second switch.
>>>> Eric
>>>>>
>>>>> - Christian
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

---

From: Frank Xia <[email-masked]>
Date: Mon, 15 Jun 2009 12:01:54 -0500

Hi Marcelo

Please check again...

BR
Frank
----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>
Sent: Monday, June 15, 2009 11:01 AM
Subject: Re: [savi] A different trade off for SAVI

Frank=>DAD is NOT a MUST for stateless address configuration.
RFC 4862 reads
"   By default, all addresses should be tested for uniqueness prior to
   their assignment to an interface for safety.  The test should
   individually be performed on all addresses obtained manually, via
   stateless address autoconfiguration, or via DHCPv6.  To accommodate
   sites that believe the overhead of performing Duplicate Address
   Detection outweighs its benefits, the use of Duplicate Address
   Detection can be disabled through the administrative setting of a
   per-interface configuration flag."

Frank=>DAD is not a message but a procedure which includes
NS and NA.   SAVI device acting as a host initiates  NS message for
the target host  to  build or verify  binding states which are built
by FCFS.   It seems to be complementary to FCFS.

how come the routers have the auhtoritative information?
Frank=>An access router is an edge between layer 2 network layer 3 network.
Access router is responsible for address configuration of host, and
relates the corresponding layer 2 information to the the host.
IMHO,  there is no any  necessary work  to do if we try to build
SAVI state in an access router.   ALL the DAD/DHCP snooping
work is on switchs not routers.

so? what woudl the impact of this?
Frank=>Just a deliberate attack.

good

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 15 Jun 2009 20:55:38 +0200

>   per-interface configuration flag."
so?
I think it is safe to assume that if we define a SAVI solution that 
relies on DAD, sites using the SAVI solution will not disable the DAD 
procedure.
I fail to see what is the problem here.

> by FCFS.   It seems to be complementary to FCFS.
FCFS as currently defined uses both DAD and data packets.
I am not sure if you are proposing to use other ND msgs than the ones 
involved in the DAD procedure

> Access router is responsible for address configuration of host,
how come? with stateless address autoconf, each host autoconfigures an 
address and the router is not aware of the addresses configured by each node

> and
you mean when it forwards the first data packet?

> SAVI state in an access router.
i am still not see what is the advatage of doing that
OTOH, it is clear that the security level is lower, since the intra 
subnetwork traffic may not flow through the access router
In any case, the proposed approach of relying on DAD packets works 
perfectly fine both wen SAVI is implemented in the router or in the switch

>    ALL the DAD/DHCP snooping
not sure why this is an issue

> Frank=>Just a deliberate attack.
and the question is what is the impact of this attack? I fail to see any 
problem that is introduced by an attacker ignoring DAD packets

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 15 Jun 2009 20:47:44 +0200

> Including those with no SeND.
it really depends on the amount of complexity this implies.
If a subproduct of SAVI is better ND protectiong, then great, but i 
wouldn't go for a more complex SAVI solution just to protect ND.
there are other tools for that, SEND is one of them, but other means to 
protect from rogue RA are also been adopted

> because the original owner has gone), 
what do you mean has gone?
If the owner has really gone, i.e. it is no longer using the address, 
then i don't see how this is an attack.

> then the switch become no more than a registration chamber. With 
> nothing to say about who is good and who is bad.
I think we do have proposed some ways to define if a binding is preferred.
The first node claiming an address, it is i the owner.
If a new node come and the original is still reachable, the first one 
still keep the address
If the initial node is no longer reachable, the new node gets the 
address (this is needed for mobility)

Do you see a problem with this?

>
> I think we have a fundamental difference on the goals. I think that 
> the switch should make decisions on what gets in (the binding table) 
> and what does not, as well as how long it stays there,
we certainly agree here, see the summary of the rules above

> not fully coupled with end-nodes view. (I don't mean not_coupled).

I am not sure i understnad this

Regards, marcelo

>>>>> Note that many switches won't do mld snooping and simply 
>>>>> (hardware) broadcast messages to solicited node multcast addresses 
>>>>> to all nodes.
>>>> right
>>>>
>>>>> the exception where it could have been lost).But then its the 
>>>>> swich dending the address, not the node. .
>>>>> one, sometime they are attacks, and it's true for DAD and any 
>>>>> other NDP messages.
>>>>> When receiving a DAD response carrying a different binding that 
>>>>> the DAD request, should the switch
>>>>> - prefer the binding of the DAD request, and expose itself to 
>>>>> break DAD, if it missed an hypothetical  earlier DAD request from 
>>>>> this DAD responder
>>>> but that would imply that DAD does no longer work, right? I mean, 
>>>> if the SAVI always preffer the initial NSOL of the DAD, then, if 
>>>> there is a colision, we are not honoring the node that originally 
>>>> got the address

---

From: Frank Xia <[email-masked]>
Date: Mon, 15 Jun 2009 15:23:16 -0500

Hi Marcelo

please see inline..

BR
Frank

----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>
Sent: Monday, June 15, 2009 1:55 PM
Subject: Re: [savi] A different trade off for SAVI

so?

Frank=>You say "DAD is a MUST for stateless address autoconf" while
I am saying "DAD is NOT a MUST ...".  Change of this basic assumption
should have some impact on the solution :-)

"sites using the SAVI solution will not disable the DAD
procedure" is not a good constraints which places extra burdens
to network management.  A maintenance engineer should be able
to know which OS the host is using, and which command
for enabling/disabling  DAD.  When he talks to a subscriber
about DAD operation, the subscriber probably really takes that
something is wrong with his Dad :-)

how come? with stateless address autoconf, each host autoconfigures an
address and the router is not aware of the addresses configured by each node
Frank=>Router fowarding is based on complete addresses of the hosts
whatever the address configuration mode the host is using. The router
is aware of the addresses.   ND protocol is run between the router and the
hosts.  In fact, the address legitimacy should be validated by the router.

Frank=>I mean currently access routers have already been able to
do binding check of a host regarding source address and layer 2.
The access router get all the information without  SAVI involvement.

not sure why this is an issue
Frank=>When we talk about snooping, it implies switch snooping.
When we propose solution based on snooping, it is  also implies
the solution is for switch.  IMHO,  purpose of SAVI  seems to
offload  source address validation work from an access router to
a layer 2 device.

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 15 Jun 2009 23:26:09 +0200

Frank Xia escribió:
> to network management.
I don't see too much of a constraint to require that a site that wants 
to use SAVI for statelessly configured addresses needs to enable DAD

>   A maintenance engineer should be able
that doesn't follow
By default DAD MUST be performed i.e. accoridng to RFC4862 in normative 
lenguage it reads:

   Duplicate Address Detection MUST be performed on all unicast
   addresses prior to assigning them to an interface, regardless of
   whether they are obtained through stateless autoconfiguration,
   DHCPv6, or manual configuration, with the following exceptions:

   -  An interface whose DupAddrDetectTransmits variable is set to zero
      does not perform Duplicate Address Detection.

   -  Duplicate Address Detection MUST NOT be performed on anycast
      addresses (note that anycast addresses cannot syntactically be
      distinguished from unicast addresses).

   -  Each individual unicast address SHOULD be tested for uniqueness.
      Note that there are implementations deployed that only perform
      Duplicate Address Detection for the link-local address and skip
      the test for the global address that uses the same interface
      identifier as that of the link-local address.  Whereas this
      document does not invalidate such implementations, this kind of

Thomson, et al.             Standards Track                    [Page 12]

RFC 4862        IPv6 Stateless Address Autoconfiguration  September 2007

      "optimization" is NOT RECOMMENDED, and new implementations MUST
      NOT do that optimization.  This optimization came from the
      assumption that all of an interface's addresses are generated from
      the same identifier.  However, the assumption does actually not
      stand; new types of addresses have been introduced where the
      interface identifiers are not necessarily the same for all unicast
      addresses on a single interface [RFC4941] [RFC3972].  Requiring
      that Duplicate Address Detection be performed for all unicast
      addresses will make the algorithm robust for the current and
      future special interface identifiers.

and the default value of the DupAddrDetectTransmits is one

So, in a non managed network, the OS will perform DAD and a user will 
need to manually deactivate it. So if the user knows enough to deactivte 
DAD, he should understnad the impact and should understnad that SAVI 
will not work in that environment.
In other words, a host that follows the specs will behave properly in a 
SAVi solution that uses DAD

> is aware of the addresses.   
but the router is aware of the address once it has forwarded a packet 
for that host, which may be later than the DAD procedure, this would 
open a vulnerabiluty window from the time DAD is perfromed and the first 
packet is forwarded, which the attacker canuse to create a fals binding 
in the router (by sending a data packet)

> ND protocol is run between the router and the
I certainly see SAVI enabled routers being one possible configuration, i 
fail to see why it should be the only one and i fail to see what is the 
benefitto move away from a DAD based scheme

> The access router get all the information without  SAVI involvement.
right and the problem is that currently routers forward packet with 
spoofed addresses and in order to solve that we need savi

> Frank=>When we talk about snooping, it implies switch snooping.
no, the router can also snoop packets

> the solution is for switch.
i disagree
the approach described in the origin of this threat can be equally be 
used in a switch or in a router

>   IMHO,  purpose of SAVI  seems to
no, imho, it should support both configurations (and it does afaict)

regards, marcelo

---

From: Frank Xia <[email-masked]>
Date: Mon, 15 Jun 2009 17:14:17 -0500

Hi Marcelo

Please check...

BR
Frank

----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>
Sent: Monday, June 15, 2009 4:26 PM
Subject: Re: [savi] A different trade off for SAVI

> I don't see too much of a constraint to require that a site that wants to 
> use SAVI for statelessly configured addresses needs to enable DAD
>
Frank=>The above means DAD is  a conditional MUST.

>
> So, in a non managed network, the OS will perform DAD and a user will need 
> to manually deactivate it. So if the user knows enough to deactivte DAD, 
> he should understnad the impact and should understnad that SAVI will not 
> work in that environment.

Frank=>What if the device is deactive in DAD by default, and the user has
no idea of how to activate it.   is it better to have  a solution without
user involvment?

> but the router is aware of the address once it has forwarded a packet for 
> that host, which may be later than the DAD procedure, this would open a 
> vulnerabiluty window from the time DAD is perfromed and the first packet 
> is forwarded, which the attacker canuse to create a fals binding in the 
> router (by sending a data packet)
Frank=>When a host implements RFC4429 Optimistic DAD,
this window is unavoidable.

> benefitto move away from a DAD based scheme
Frank=>AFAIK, BRAS as an access router for a host to access to internet
has built-in binding check funtion.   I just want to say that existing 
routers
enforce source address validation without our SAVI  which
certainly benefit switch to implement the function.

> the approach described in the origin of this threat can be equally be used 
> in a switch or in a router
Frank=>Access routers as ND/DHCP message terminators don't need
to SNOOP message.

---

From: Christian Vogt <[email-masked]>
Date: Tue, 23 Jun 2009 15:58:11 -0700

On June 14, 2009, Eric Levy-Abegnoli wrote:

> if

Eric -

Are you still talking about an attack that SAVI is trying to prevent?
You are talking about an attack that keeps a host from configuring a
particular IP address, not an attack in which this IP address is
spoofed.  This attack is inherent in DAD, as Marcelo mentioned.  But it
is not an attack that SAVI was chartered to prevent.

Now, I understand that your intention is to augment SAVI to also protect
DAD.  Can you clarify how your proposed mechanism would work?  And what
would be the cost in terms of extra implementation or administration
complexity?  (I think you should start a new discussion thread for this,
since it seems to be independent of the adoption of Marcelo's proposed
FCFS variant.)

> preferred over the DAD sender? If so, how can this be an anti-spoofing

I am unsure if I understand you.  DAD responses do not create SAVI
bindings.  They can only prevent another binding from being created, and
this only if they correspond to an existing binding themselves.  If they
do not correspond to an existing binding themselves, they are dropped by
a SAVI device.  The only way to create a SAVI binding is by sending a
DAD solicitation or by a DHCP address assignment.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Tue, 23 Jun 2009 19:05:36 -0700

On Jun 15, 2009, Frank Xia wrote:

> DAD is NOT a MUST for stateless address configuration. RFC 4862 reads
>
>    "By default, all addresses should be tested for uniqueness prior to

Isn't this just another reason to forward packets in the absence of a
binding, rather than discarding them?  I see this in support of the
proposed FCFS variant.

- Christian

---

From: Frank Xia <[email-masked]>
Date: Tue, 23 Jun 2009 21:55:03 -0500

Hi Christian

Yes.

My another observation is that people only talk about
DAD defined in RFC4862  while ignoring 
Optimistic DAD defined in RFC4429 which
let go data traffic preceding control message

BR
Frank

---

From: Fred Baker <[email-masked]>
Date: Tue, 23 Jun 2009 20:01:14 -0700

but letting traffic prior to DAD go means that an attack that is  
spoofing an address and sends it only once doesn't have to do DAD at  
all, and SAVI is ineffective in preventing it..

What part of "the purpose of SAVI is to prevent systems from sending  
datagrams from addresses that are not their own, and if under any  
circumstance they succeed in sending a datagram from such an address  
SAVI has failed" are we having trouble with here?

On Jun 23, 2009, at 7:55 PM, Frank Xia wrote:

> DAD defined in RFC4862  while ignoring Optimistic DAD defined in  
> RFC4429 which
> ----- Original Message ----- From: "Christian Vogt" <[email-masked] 
> >

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Wed, 24 Jun 2009 18:49:30 +0200

Christian,
> since it seems to be independent of the adoption of Marcelo's proposed
I am not trying to protect DAD per say. I am arguing that there are many 
caveats in fcfs, that would lead the switch to install attackers binding 
in its table instead of legitimate owners bindings. I certainly 
acknowledge that the switch binding table will indeed reflect the state 
of the network (attackers being over-represented in the binding table).  
But it defeats the purpose (if not the charter) of building a binding 
table that provides better security than no table.at all
One example:victim comes up, address is installed, victim goes away, 
address is removed, attackers do DAD for the same address, gets his 
address in the table, victim comes back and is rejected. So the binding 
table reflect the state of the network. And the victim is out.
I have a number of scenarios in mind on how the switch can make a better 
decision than the end-nodes, and others where fcfs will not lead to the 
best decision. However, as long as we have not agreed that the switch is 
a greater authority than end-nodes with regard to prefering a binding, 
then I don't think it's useful.
As far as the fcfs variant (is this the logging instead of droping 
proposal?) I think it's a bad idea. If the switch does not drop, it will 
endup with binding inconsistent with end-nodes (4861/4862 are not 
first-come first-serve based). This incosisyency will lead to a lot more 
logging than desirable. And on top of that, logging is often harmful and 
useless.
> DAD solicitation or by a DHCP address assignment.
Then this is me who mis-understood what you said:
[DAD] it gives the victim of a spoofing attack a chance to speak up.
The attacker would obviously not do DAD on the address he plans to 
spoof. So I took that you meant victim = DAD sender. Then I see two cases:
1) There was initially no owner for the address in the binding table, 
one is created on the NS DAD, and the NA (response), carrying a 
different binding should be rejected by the switch (or a least not 
change the binding entry). If not blocked, the DAD sender end up with no 
address. Binding table with bogus binding.
2) There  was initially a owner, the DAD NS should be sent to him (and 
nobody else in my opinion); response sent back to him, binding table not 
changed. This is not a spoofing scenario.
So in that case, what DAD gives you over the other NDP messages?  In my 
opinion, just an opportunity for the attacker to prevent the DAD sender 
to use an address.
So it's rather a caveat than a chance.
Eric

---

From: "Greg Daley" <[email-masked]>
Date: Thu, 25 Jun 2009 08:15:26 +1000

Hi Frank and Christian, 

Actually,  I see this rather as a case where the applicability of SAVI
operations
increases the usefulness of DAD.   In environments where manual,
administrative
settings to disable DAD are in use, a policy decision is being made.

It could be argued that this policy decision is incompatible with SAVI
(and turning on
SAVI is also likely to be a policy setting).

An up-front compatibility statement would cover the situations where DAD
is not to be done.

In reference to Frank's discussion of RFC 4429, there is indeed a race
condition between
packet transmission and DAD operation in Optimistic DAD.  There are
already explicit assumptions
in that document which outline that packet transmission from optimistic
addresses may be lost
before DAD is completed.

This is also the case for mobile devices which are not required to
always perform full DAD when
reattaching to the same LAN from a different switch port (for example
through a different WLAN AP).
Packets transmitted at that time would be lost until the binding is
updated.

Greg Daley
Security Consultant
NetStar Australia Pty Ltd

E-mail: [email-masked]
Mobile: +61 401 772 770
Direct: +61 3 8532 4042
Fax:    +61 3 8532 4032
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christian Vogt
Sent: Wednesday, 24 June 2009 12:06 PM
To: Frank Xia
Cc: SAVI Mailing List
Subject: Re: [savi] A different trade off for SAVI

- Christian

---

From: Frank Xia <[email-masked]>
Date: Wed, 24 Jun 2009 17:46:57 -0500

Hi Greg

Just as the title say "the trade off for SAVI", I prefer
letting a packet go even we are not  sure if it is
legitimate.

Please see my other inline comments...

BR
Frank

----- Original Message ----- 
From: "Greg Daley" <[email-masked]>
To: "Christian Vogt" <[email-masked]>; "Frank Xia" 
<[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>
Sent: Wednesday, June 24, 2009 5:15 PM
Subject: Re: [savi] A different trade off for SAVI

> in that document which outline that packet transmission from optimistic
Frank=>That means Optimistic DAD is not allowed.

> Packets transmitted at that time would be lost until the binding is
Frank=>IMHO, packet loss due to handover seem to be irrelevent
to packet filtering because of false soure address.

---

From: Christian Vogt <[email-masked]>
Date: Wed, 24 Jun 2009 10:02:06 -0700

On Jun 23, 2009, Frank Xia wrote:

> Yes.
>
> My another observation is that people only talk about DAD defined in
> RFC4862  while ignoring Optimistic DAD defined in RFC4429 which let go
> data traffic preceding control message

Right, Optimistic DAD must be considered.  And this again is a reason to
forward packets in the absence of a binding, rather than discarding  
them.

- Christian

---

From: "Greg Daley" <[email-masked]>
Date: Fri, 26 Jun 2009 08:47:32 +1000

Hi Frank, 

I have highlighted my points below, which are salient, even though the
title has not changed on the thread.

-----Original Message-----
From: Frank Xia [mailto:[email-masked]]
Sent: Thursday, 25 June 2009 8:47 AM
To: Greg Daley; Christian Vogt
Cc: SAVI Mailing List
Subject: Re: [savi] A different trade off for SAVI

Hi Greg

Just as the title say "the trade off for SAVI", I prefer letting a
packet go even we are not  sure if it is legitimate.

BR
Frank

condition between
> in that document which outline that packet transmission from
optimistic addresses may be lost

Actually, I'd like to clarify the behaviour of Optimistic DAD (RFC4429)
in this case:

There is no implied delay for the DAD NS delivery in Optimistic DAD:
 
(Section 3.3)
   * (modifies section 5.4.2) The host MUST join the all-nodes multicast
        address and the solicited-node multicast address of the
        Tentative address.  The host SHOULD NOT delay before sending
        Neighbor Solicitation messages.

The difference is that packets can be sent basically immediately in
Optimistic DAD.  This is valid behaviour, and the host knows that by
using an optimistic address there is the chance of delivery failure.
No existing Neighbour Discovery Binding is overwritten by RFC4429
operations,
so there is no problem with Optimistic DAD's impact on the network.  The

impact is specific to the host, which is the functional trade-off built
into optimistic DAD.
In summary: It does not mean that Optimistic DAD is not allowed.

updated.

The impact is functionally the same for false address use and for mobile
devices.  The binding
exists on one port, and then moves to another port without signalling. 

This is not packet loss due to mobility, the SAVI device would block any
such port movement
were DAD/MLD/DHCPv6 (take your pick for binding protocol) not to occur.
By default, the
moving device doesn't perform DAD, as it is in the same Link.

---

From: Frank Xia <[email-masked]>
Date: Thu, 25 Jun 2009 18:13:04 -0500

Hi Greg

"   Optimistic address - an address that is assigned to an interface and
        available for use, subject to restrictions, while its uniqueness
        on a link is being verified.  This memo introduces the
        Optimistic state and defines its behaviors and restrictions."

An address could be used for sending packets even DAD is ongoing.
That means there is not DAD state established.  It also means it could happen
sending a packet prior to  sending any DAD message(that is, NS).

Please check other inline responses...

BR
Frank
  ----- Original Message ----- 
  From: Greg Daley 
  To: Frank Xia ; Christian Vogt 
  Cc: SAVI Mailing List 
  Sent: Thursday, June 25, 2009 5:47 PM
  Subject: Re: [savi] A different trade off for SAVI

  Hi Frank, 

  I have highlighted my points below, which are salient, even though the title has not changed on the thread.

  -----Original Message-----
  From: Frank Xia [mailto:[email-masked]]
  Sent: Thursday, 25 June 2009 8:47 AM
  To: Greg Daley; Christian Vogt
  Cc: SAVI Mailing List
  Subject: Re: [savi] A different trade off for SAVI

  Hi Greg

  Just as the title say "the trade off for SAVI", I prefer letting a packet go even we are not  sure if it is legitimate.

  BR
  Frank

  >
  > In reference to Frank's discussion of RFC 4429, there is indeed a race condition between
  > packet transmission and DAD operation in Optimistic DAD.  There are already explicit assumptions
  > in that document which outline that packet transmission from optimistic addresses may be lost
  > before DAD is completed.

  Actually, I'd like to clarify the behaviour of Optimistic DAD (RFC4429) in this case:

  (Section 3.3)
   * (modifies section 5.4.2) The host MUST join the all-nodes multicast
        address and the solicited-node multicast address of the
        Tentative address.  The host SHOULD NOT delay before sending
        Neighbor Solicitation messages.
Frank=>"SHOULD NOT delay" does not mean "sending NS prior to any datapackets"
The difference is that packets can be sent basically immediately inOptimistic DAD.  This is valid behaviour, and the host knows that byusing an optimistic address there is the chance of delivery failure.No existing Neighbour Discovery Binding is overwritten by RFC4429 operations,so there is no problem with Optimistic DAD's impact on the network.  The impact is specific to the host, which is the functional trade-off builtinto optimistic DAD.In summary: It does not mean that Optimistic DAD is not allowed.> This is also the case for mobile devices which are not required to always perform full DAD when> reattaching to the same LAN from a different switch port (for example through a different WLAN AP).> Packets transmitted at that time would be lost until the binding is updated.Frank=>IMHO, packet loss due to handover seem to be irreleventto packet filtering because of false soure address.The impact is functionally the same for false address use and for mobile devices.  The bindin
 g
  exists on one port, and then moves to another port without signalling. 

  This is not packet loss due to mobility, the SAVI device would block any such port movement
  were DAD/MLD/DHCPv6 (take your pick for binding protocol) not to occur.  By default, the
  moving device doesn't perform DAD, as it is in the same Link.

------------------------------------------------------------------------------

---

From: "Greg Daley" <[email-masked]>
Date: Fri, 26 Jun 2009 09:32:30 +1000

Hi Frank, 
 
The point I make again and again is that packet loss is not an issue:
 
The interface is in Optimistic mode so you get what you pay for.
 
With regard to the binding state: If there is no existing binding in the
SAVI
switch, why not send the packets as soon as a DAD NS is sent?
 
That would also be optimistic!

Greg Daley
Security Consultant

________________________________

From: Frank Xia [mailto:[email-masked]] 
Sent: Friday, 26 June 2009 9:13 AM
To: Greg Daley; Christian Vogt
Cc: SAVI Mailing List
Subject: Re: [savi] A different trade off for SAVI

Hi Greg

An address could be used for sending packets even DAD is ongoing.
That means there is not DAD state established.  It also means it could
happen
sending a packet prior to  sending any DAD message(that is, NS).

BR
Frank

	----- Original Message ----- 
	From: Greg Daley <mailto:[email-masked]>  
	To: Frank Xia <mailto:[email-masked]>  ; Christian Vogt
<mailto:[email-masked]>  
	Cc: SAVI Mailing List <mailto:[email-masked]>  
	Sent: Thursday, June 25, 2009 5:47 PM
	Subject: Re: [savi] A different trade off for SAVI

	Hi Frank, 

	I have highlighted my points below, which are salient, even
though the title has not changed on the thread.

	-----Original Message-----
	From: Frank Xia [mailto:[email-masked]]
	Sent: Thursday, 25 June 2009 8:47 AM
	To: Greg Daley; Christian Vogt
	Cc: SAVI Mailing List
	Subject: Re: [savi] A different trade off for SAVI
	
	Hi Greg
	
	Just as the title say "the trade off for SAVI", I prefer letting
a packet go even we are not  sure if it is legitimate.

	BR
	Frank

	Actually, I'd like to clarify the behaviour of Optimistic DAD
(RFC4429) in this case:

	There is no implied delay for the DAD NS delivery in Optimistic
DAD:
	 
	(Section 3.3)
	   * (modifies section 5.4.2) The host MUST join the all-nodes
multicast
	        address and the solicited-node multicast address of the
	        Tentative address.  The host SHOULD NOT delay before
sending
	        Neighbor Solicitation messages.
	Frank=>"SHOULD NOT delay" does not mean "sending NS prior to any
data
	packets"
	The difference is that packets can be sent basically immediately
in
	Optimistic DAD.  This is valid behaviour, and the host knows
that by
	using an optimistic address there is the chance of delivery
failure.
	No existing Neighbour Discovery Binding is overwritten by
RFC4429 operations,
	so there is no problem with Optimistic DAD's impact on the
network.  The 
	impact is specific to the host, which is the functional
trade-off built
	into optimistic DAD.
	In summary: It does not mean that Optimistic DAD is not allowed.
	> This is also the case for mobile devices which are not
required to always perform full DAD when
	> reattaching to the same LAN from a different switch port (for
example through a different WLAN AP).
	> Packets transmitted at that time would be lost until the
binding is updated.

	The impact is functionally the same for false address use and
for mobile devices.  The binding
	exists on one port, and then moves to another port without
signalling. 

	This is not packet loss due to mobility, the SAVI device would
block any such port movement
	were DAD/MLD/DHCPv6 (take your pick for binding protocol) not to
occur.  By default, the
	moving device doesn't perform DAD, as it is in the same Link.

________________________________

---

From: Christian Vogt <[email-masked]>
Date: Thu, 25 Jun 2009 15:59:50 -0700

Eric -

> logging than desirable. And on top of that, logging is often harmful  

Can you clarify which binding inconsistencies you are concerned about in
FCFS?

> Then this is me who mis-understood what you said: [DAD] it gives the
> victim of a spoofing attack a chance to speak up. The attacker would
> obviously not do DAD on the address he plans to spoof. So I took that
> you meant victim = DAD sender. Then I see two cases:
>

But this is not how current SAVI solution proposals work.  All current
proposals would tentatively create a binding upon a DAD solicitation,
and remove this binding upon a DAD response.  Spoofed DAD responses are
discarded by a SAVI device.

> changed. This is not a spoofing scenario.

Right.  In this case, the DAD response is not discarded because it
corresponds to an existing binding.

> to use an address. So it's rather a caveat than a chance.

Can you clarify?  I can't see your point.

- Christian

---

From: "Greg Daley" <[email-masked]>
Date: Fri, 26 Jun 2009 11:44:52 +1000

Hi Christian,

I think that Eric points out that monitoring ports for any ND 
(in the same fashion that one could monitor ARP today) will identify
that the addresses are in use, independent of whether the DAD message
has
been sent.

This would allow the SAVI device to make bindings on unused addresses
once it sees
that the address is functionally in use, even if it doesn't see the DAD
NS.

Greg Daley
Security Consultant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christian Vogt
Sent: Friday, 26 June 2009 9:00 AM
To: Eric Levy-Abegnoli
Cc: SAVI Mailing List
Subject: Re: [savi] A different trade off for SAVI

Eric -

> proposal?) I think it's a bad idea. If the switch does not drop, it 
> will endup with binding inconsistent with end-nodes (4861/4862 are not

> first-come first-serve based). This incosisyency will lead to a lot 
> more logging than desirable. And on top of that, logging is often 
> harmful and useless.

> change the binding entry). If not blocked, the DAD sender end up with 
> no address. Binding table with bogus binding.

> nobody else in my opinion); response sent back to him, binding table 
> not changed. This is not a spoofing scenario.

> So in that case, what DAD gives you over the other NDP messages?  In 
> my opinion, just an opportunity for the attacker to prevent the DAD 
> sender to use an address. So it's rather a caveat than a chance.

- Christian

---

From: Frank Xia <[email-masked]>
Date: Thu, 25 Jun 2009 21:11:54 -0500

Hi Greg

>From my perspective,  legitimate packets loss IS an issue.

BR
Frank
  ----- Original Message ----- 
  From: Greg Daley 
  To: Frank Xia ; Christian Vogt 
  Cc: SAVI Mailing List 
  Sent: Thursday, June 25, 2009 6:32 PM
  Subject: Re: [savi] A different trade off for SAVI

  Hi Frank, 

  With regard to the binding state: If there is no existing binding in the SAVI
  switch, why not send the packets as soon as a DAD NS is sent?

  Greg Daley
  Security Consultant

  Hi Greg

  BR
  Frank
    ----- Original Message ----- 
    From: Greg Daley 
    To: Frank Xia ; Christian Vogt 
    Cc: SAVI Mailing List 
    Sent: Thursday, June 25, 2009 5:47 PM
    Subject: Re: [savi] A different trade off for SAVI

    Hi Frank, 

    -----Original Message-----
    From: Frank Xia [mailto:[email-masked]]
    Sent: Thursday, 25 June 2009 8:47 AM
    To: Greg Daley; Christian Vogt
    Cc: SAVI Mailing List
    Subject: Re: [savi] A different trade off for SAVI

    Hi Greg

    BR
    Frank

    (Section 3.3)
Frank=>"SHOULD NOT delay" does not mean "sending NS prior to any datapackets"The difference is that packets can be sent basically immediately inOptimistic DAD.  This is valid behaviour, and the host knows that byusing an optimistic address there is the chance of delivery failure.No existing Neighbour Discovery Binding is overwritten by RFC4429 operations,so there is no problem with Optimistic DAD's impact on the network.  The impact is specific to the host, which is the functional trade-off builtinto optimistic DAD.In summary: It does not mean that Optimistic DAD is not allowed.> This is also the case for mobile devices which are not required to always perform full DAD when> reattaching to the same LAN from a different switch port (for example through a different WLAN AP).> Packets transmitted at that time would be lost until the binding is updated.Frank=>IMHO, packet loss due to handover seem to be irreleventto packet filtering because of false soure address.The impact is functionally the same for false address use and for mobile devices.  The binding

----------------------------------------------------------------------------

---

From: "Greg Daley" <[email-masked]>
Date: Fri, 26 Jun 2009 12:43:27 +1000

Hi Frank, 
 
That's an upper layer issue though (for example TCP
will manage this loss as normal).
 
We are looking at Layer 3.

In any case, if people do not want to use Optimistic DAD, it is off by
default.

Then they don't get the interface for packet transmission until the DAD
completes.

The applicability statement for Optimistic DAD covers this:

_It is only a local (to that host) problem_

Greg

From: Frank Xia [mailto:[email-masked]] 
Sent: Friday, 26 June 2009 12:12 PM
To: Greg Daley; Christian Vogt
Cc: SAVI Mailing List
Subject: Re: [savi] A different trade off for SAVI

Hi Greg

BR
Frank

---

From: Christian Vogt <[email-masked]>
Date: Mon, 29 Jun 2009 16:55:02 -0700

Greg and Eric -

Thanks for explaining, Greg.  What you are saying was exactly my  
understanding of Eric's first message in this thread.  But I had  
thought that, in his latest message, he was getting at something  
different.

In any case:  Eric, can you clarify what is the benefit of your  
proposal over the current FCFS solution, which creates packets based  
on all packets, including data, DAD, and other ND packets?

- Christian

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Tue, 30 Jun 2009 16:18:51 +0200

Christian,
there are several alleys where I am proposing something "different", 
hence the confusion that I may have created in the thread. Apologies to 
the wg for that. "Unfortunately", these differences  are tight up 
together to some extend, and it's hard for me to extract one piece and 
describe the benefit as if it was standalone (hopefully, if I get a 
chance to present the proposal at ietf75, maybe it become clearer).
To this sepcific point, the reasons why I was proposing to look at other 
ND packets are of two folds:
- use them to maintain most accurate/up-to-date "state" of the binding 
entries, to make more accurate decisions (in case DAD was not seen, for 
movement, to poll entry owners, etc.)
- to exploit the content of the binding information provided in these ND 
packets, in particular the LLA.
 From a switch standpoint, I don't see much extra difficulty or burden 
to look at all NDP packets rather than "just" the DAD.
Eric

---

From: Christian Vogt <[email-masked]>
Date: Tue, 30 Jun 2009 10:51:00 -0700

Eric -

Thanks for clarifying.  Yet what I think you need to clarify even
further is why the benefits of snooping ND packets, which you identify
in your email below, cannot already be obtained with the current SAVI
solution, which snoops all packets.  Could you do this?

- Christian

On Jun 30, 2009, Eric Levy-Abegnoli wrote:

> From a switch standpoint, I don't see much extra difficulty or  
> burden to
> look at all NDP packets rather than "just" the DAD.
>
> Eric