Re: [savi] Question for draft-levy-abegnoli-savi-plbt-01

[Eric Levy-Abegnoli <elevyabe at cisco.com>]

Hi Dong,
thanks for all the good points. See inline ...

Dong Zhang a écrit :
> Hi Eric,
> Please check inline.
>
[snip]
> I guess so. If this was not crystal clear in the current writing, it
> means I need to clarify. You got it allright though,
> so it must not have been too bad :)
> Maybe I'll add an example with some values ...
> Thanks
> eric
> [Dong] But It seems there is something different between Greg's
> understanding and your explanation. So agree to add
> some clarification as my last mail said.
will do in the next version

> [Dong] In addition, I'm worried about a possible security problem.
> *************
> The draft says:
> Therefore, a data packet should not be used to complete the
> binding entry, but only as a hint that it should seek for completion.
> Upon receiving a data packet carrying a source address not seen
> before, the switch should issue a DAD packet on the link (all ports
> of the vlan), including the one from which the data packet was
> received. The address owner is expected to respond with an NA,
> carrying CGA credentials if any. Upon receiving this response, the
> switch can complete the binding entry and start forwarding traffic
> from the source.
> ...
> For instance, upon receiving a data packet, the
> switch will issue a DAD NS and wait for an NA. Before receiving the
> NA, the entry is IMCOMPLETE. Then it moves to REACHABLE. Then to
> STALE unless the binding is confirmed by more NDP traffic.
> ************
> Thinking about an attacker sends data packets with different forged
> source addresses incessantly. Then these data packets lead
> the savi switch to send DAD and wait for NA response. In this case, a
> DoS attack arise. The security consideration should be added.
> And the entry bindings with IMCOMPLETE state cost the memory while
> waiting for the response. Maybe a state machine is need for
> the state transition. The behavior of savi switch might be something
> like this:
> Trigger Action
> Receive a data packet Create a IMCOMPLETE entry, send DAD NS
> If receive a NA within x(the exact seconds, e.g. 3s ) IMCOMPLETE moves
> to REACHABLE
> If receive no NA within x Eleminate the IMCOMPLETE entry
> ...
All this is very true. Actually, in the -00 of this draft, I had
included a state machine description, somewhat very close to what you
are describing. I removed it in this -01 version to focus on
the preference algorithm (problem statement and proposed solution) and
give a chance to people to review that bit.
From there it really depend on where this is going: if some of this
draft endup in the WG document (fcfs or with a different name as it was
suggested in Stockholm), then I would really like to
see a state machine there (I don't think there is one in fcfs).
If this is going to be a separate document, them I agree that I should
put back the state machine and clarify the security issues.
Eric

> ...
> Thank you.
> Dong