Re: [trill] ESADI draft change suggestion

[Donald Eastlake <[e-mail]>]

Hi,

On Sun, Jul 22, 2012 at 9:34 PM, Sujay Gupta <[e-mail]> wrote:
> Hi,
>
> 1)
> The ESADI protocol objectives as stated in the draft-04, IMO needs added
> statements.
> Section 1: "Introduction"
>>>
>
> The ESADI
>    protocol's potential advantages over data plane learning include the
>    following:
>
>    1. Security advantages:..
>    2. Fast update advantages:..
> <<
>
> w.r.t to Security advantages, albeit ESADI can make a authenticated entries
> an insecure ESADI increases
> the security vulnerability then without it. My recommendation is to

I don't see why that would be true. If you are just learning from the
data plane, a forged multi-destination broadcast frame, either native
or TRILL Data, can cause bad MAC learning entries pretty easily
throughout the VLAN of the frame. Even an insecure ESADI is a little
better. To forge an ESADI frame that would be accepted, an adversary
would have to participate in the ESADI instance, create an acceptable
ESADI-LSP, make sure it didn't get back to the claimed originator so
the claimed originator does not send out a new one with incremented
sequence number to overwrite the forged ESADI information, etc. Of
course, I'm not claiming that "insecure ESADI" is secure; I'm just
saying it seems to me to be a little harder for an adversary to cause
bad MAC learning with ESADI than with data plane learning.

> recommend a SHOULD clause to implement
> security features. A secured deployment of TRILL may choose to live with a

Given that, as far as I can recall, there is no "SHOULD" in TRILL to
use any IS-IS authentication, although it is mentioned as a facility
available as a countermeasure against some threats, I don't see how it
makes sense to just put in a "SHOULD" for ESADI authentication. On the
other hand, it might make sense to say that if IS-IS authentication is
in use for IS-IS LSPs, then the default would be to use authentication
for ESADI. This would be similar to the provisions in the BFD over
TRILL draft.

> unsecured ESADI ( & therefore
> possibly a more efficient/lighter ESADI); whilst a TRILL plane bridging 3rd
> party aggregation and application
> layers may choose for trusted/secured model.
>
> 2)
>
> This is w.r.t to learning of ESADI entries and timing them out. As per RFC
> 6325, the entries are expected
> to be removed only by the originating RBridge.
>>>
> Section 4.8.3
> “The situation is different for end-station address information acquired via
> the TRILL ESADI protocol.
> It is up to the originating RBridge to decide when to remove such
> information from its ESADI LSPs
> (or up to ESADI protocol timeouts if the originating RBridge becomes
> inaccessible).”
> <<
>  For robust behavior it would be better to timeout the entries without
> depending on ESADI, the reason
> is a (wrong)ESADI directed forwarding can cause persistent traffic loss,
> unlike a best effort flood everywhere
> situation. Therefore my recommendation is the specs should not 'mandate' the
> timing out behavior.

That's not how link state works. In general, you have to retain the
link state information from a remote router until you get an update or
until that remote router leaves the topology. And in the later case,
you still generally want to keep it around for a while (but not
actually use it) to minimize the effort to get the link state
synchronized if the remote router re-joins the topology.

Assume, for example, you have disabled data plane learning and are
depending on ESADI. How does it make any sense to "timeout" ESADI data
from a remote RBridge and suddenly have to send as unknown location
unicast the frames destined for MAC addresses attached to that remote
RBridge, which you had been informed about through ESADI?

Perhaps the wording could be clarified, but I don't see how it makes
any sense to "timeout" ESADI state from a remove RBridge as long as
that RBridge is still reachable and participating in ESADI, etc. And I
don't see how it makes any sense, assuming you are retaining the ESADI
state from such a remote RBridge, to "timeout" making use of that
state.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> Best Regards,
> -Sujay