Subject: [savi] FW: One minor comments on "Analysis of Open Issues in SAVI "

From: "Guang Yao" <[email-masked]>
Date: Mon, 12 Apr 2010 16:14:18 +0800

> This means that the  SLAAC Savi device will trigger the procedure to
create a
> binding the first
> time it sees a host using a given address.

[Guang Yao] 
Although I agree with this sentence, the result is that an attacker can send
packets with the source addresses of other nodes, and the savi device cannot
drop them, instead, it must perform trigger procedure for each address to
check if the address satisfies binding requirements. 

This actually means, if savi wants to drop a packet, it must send 2 or more
packets first. 

And I don't think the movement and layer 2 path change problem is solved.
The node sharing same former anchor with the moving node can answer the
probe, and prevent the binding.

BR,
Guang

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 12 Apr 2010 14:22:31 +0200

> This actually means, if savi wants to drop a packet, it must send 2 or more
Right, this si why this must be rate limited, in order to prevent this 
to become a DoS attack gainst the switch.

> probe, and prevent the binding.
Sure, but that is inherent to the nature of the first come first serve 
primciple of ownership. IMHO, this is the best you can accomplish in 
this space

Regards, marcelo

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 12 Apr 2010 10:38:16 -0400

With a little work by us, and a little flexibility in the wording we 
choose, we can allow for a reasoanble behavior in a pure SLAAC-DAD 
environment.

First, a caveat.  The result will not be perfect.  Some communication 
may take longer to establish than it should.  In some corner cases, the 
SAVE device might pick the wrong winner.  Given the constraints of 
SLAAC, we have to live with that.

Suppose we write that SAVI devices will recognize the first successful 
claimant of an address.  We then note that a properly received DAD is 
the most effective form of claim.  Since DAD messages may be lost, SAVI 
devices MUST use additional measures to ensure that a properly 
functioning client is not permanently blocked from valid communication.

We need to also note that SAVI devices must ensure that they are robust 
in the presence of denial of service events, since having one user 
prevent communication from all other users on a SAVI device would be 
unacceptable.

With that much, we can then describe somewhere techniques that can be 
used for this additional robustness.

The big difference is that we do not pretend that a SAVI device is 
required to allocate an address on the first data packet, since it 
sometimes won't be able to.  But we still allow communication to occur, 
possibly with loss of a few packets.  (And it is clearly legitimate to 
simply block a particular port if that port is performing a denial of 
service attack on the SAVI device.)

Yours,
Joel M. Halpern

---

From: "Guang Yao" <[email-masked]>
Date: Tue, 13 Apr 2010 16:34:44 +0800

> functioning client is not permanently blocked from valid communication.
[Guang Yao] 
I want to make sure if I fully understand your comments. The following is
actually my proposal.

1. DAD snooping is premier as a basis;

2. To handle DAD loss and avoid permanently blocking, at least one of
additional measures MUST be used, but not limited to data trigger.
	The possible measures include:
	(a) rate limited data trigger
	(b) counter trigger
	(c) still control plane focused, snoop other control packets,
including address resolution NS, NA, MLD, NUD, etc, to trigger binding
procedure.
	(d) other possible solutions that can avoid permanently blocking.

	As no measure is perfect (at least no experiment has shown the
reality), the possible security problem and limitation of each measure must
be clarified. Experimental draft(s) may be written in the future to evaluate
the measures.

I hope this proposal can be agreed in the group.

BR,
Guang

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 13 Apr 2010 08:14:01 -0400

I mostly agree with this.
The requirement for point 2 is that the SAVI device MUST robustly 
recover from a series of known error conditions.

I think that for the second bullet you list, we should list the set of 
conditions that must be covered, and a set of techniques that MAY be used.
At this level of granularity, rate limited data trigger and counter 
trigger are indistinguishable.
And we need some analysis before we can say that use of some other 
control plane mechanism is acceptable, as I do not know of a combination 
of other control mechanisms that provide sufficient robustness.

Yours,
Joel