Re: [trill] ESADI draft change suggestion

Donald Eastlake <d3e3e3@gmail.com> Fri, 27 July 2012 15:24 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D525A21F87AB for <trill@ietfa.amsl.com>; Fri, 27 Jul 2012 08:24:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.511
X-Spam-Level:
X-Spam-Status: No, score=-103.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pm-tieVMuAR0 for <trill@ietfa.amsl.com>; Fri, 27 Jul 2012 08:24:02 -0700 (PDT)
Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 438B821F87A5 for <trill@ietf.org>; Fri, 27 Jul 2012 08:24:02 -0700 (PDT)
Received: by ggnc4 with SMTP id c4so3597676ggn.31 for <trill@ietf.org>; Fri, 27 Jul 2012 08:24:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=vOzmI+S0dcyrTlPIMjq+iwFduUMyIzaisr0HFydqkBU=; b=osrZ3PLdB2RfqaJTdvn3NWtUyp/e/KTURhoaUWsLPt60TQhSQX6QSNhD4r+NUANI3f FmKw5J2+RdPKuqDkR4mgrRif0zf54VNMWX524I3REuOjHPd1nzNj6R82AGC6DvtmOmTr 6595XKEOQORaXnnxPkib72LOZJBCxCqlJE4ByUUtPwroV/oefcJARo+OgXFTI7U+3/MD BTJeMgaugqcCuq5IKyB2XJ5L36wHNizu2jtcXAGmmrVCr9yZsO8ErK6NGUEXp4vJ4r4T a2lYijGbegkcL+kfACYd0zIHyCI23M4jq2m0To55Gqr1izeBFJ2Qb0VEbLLEwtrH0tgh XDmA==
Received: by 10.50.100.129 with SMTP id ey1mr2296307igb.35.1343402641254; Fri, 27 Jul 2012 08:24:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.70.227 with HTTP; Fri, 27 Jul 2012 08:23:40 -0700 (PDT)
In-Reply-To: <500CAA09.5070405@gmail.com>
References: <CAF4+nEFi=oTvtVJYczV8vS6+ni4UXS0CBSNTATk7aegXtbe4NQ@mail.gmail.com> <500CAA09.5070405@gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Fri, 27 Jul 2012 11:23:40 -0400
Message-ID: <CAF4+nEHjTKLNgkaOrHQ7Sk27A2uCj5p_XeGT+oTeGhDo9BvPXQ@mail.gmail.com>
To: Sujay Gupta <sujay.ietf@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: trill@ietf.org
Subject: Re: [trill] ESADI draft change suggestion
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trill>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Jul 2012 15:24:03 -0000

Hi,

On Sun, Jul 22, 2012 at 9:34 PM, Sujay Gupta <sujay.ietf@gmail.com> 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   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

> Best Regards,
> -Sujay