[rbridge] [Fwd: A Review of TRILL architecture document]

[Erik Nordmark]

This didn't appear to make it to the list.

    Erik


-------- Original Message --------
Subject: A Review of TRILL architecture document
Date: Mon, 19 May 2008 14:58:47 +0300 (EEST)
From: Pekka Savola <pekkas at netcore.fi>
To: rbridge at postel.org
CC: trill-chairs at tools.ietf.org, "W. Mark Townsley" <townsley at cisco.com>
References: <4819E5FA.8080708 at sun.com>

(Let's hope this gets through to the list.)

In Philly meeting, I was volunteered to review the
trill-rbridge-arch-05 document. Here are my comments on it.

substantial
-----------

1) the role and the timing of the document is not clear to me.  I like
architecture documents that also serve as a shorter overview on the
technology.  This document accomplishes this goal only partially but
maybe its role is meant to be different.  The reason is that very many
fundamental technical choices are left open in this document, to be
defined in the protocol specification(s).

This raises the question, what purpose is being served by publishing
the architecture document now, in the form of "these are the options
we're thinking of right now, we'll decide something later, or do
something else completely"?  Would the document be clearer and more
useful if we waited at least for the base protocol to finish (so we
could nail down most of the uncertainties) before pushing this out?

2) there are two aspects of security which haven't been very well
addressed (not in the protocol document either):

  a) zero-configuration deployment vs hijacks from hosts.  If I
understand correctly, and end station could download an rbridge
implementation, run it, and participate in campus IS-IS routing, get
elected as root rbridge and redirect all traffic to itself.  This
seems like a new threat, and seems worse than somewhat similar STP
root bridge attack. (You can also deploy switches with STP disabled
depending on topology but here that would not suffice.)

  b) flooding attacks.  Currently a host may 1) send frames with
destination addresses that no end station has in order to flood all
the switches with traffic, or 2) send frames with lots of source
addresses in order to overload the filtering database of bridge(s).

The architecture describes an option that IS-IS routing could be used
(in suggested non-default mode) to carry end-station MAC addresses
within the campus.  This implies a new threat because previously the
MAC address information was not signalled between switches using a
control plane protocol, it was part of data.  It is not clear how the
IS-IS protocol and its SPF machinery is capable of dealing with this
issue.  I recall that SPF computation can be CPU-intensive while it
runs, and if the network topology / MAC addresses never converge, this
could be bad.

editorial
---------

s/desitnation/destination/

In S 5.2:

         In the DRB example, if the destination MAC address of a received
         frame does not correspond to a learned MAC destination address
         at an egress interface, it will forward the frame on all
         interfaces for which it is either the designated RBridge.

Difficulties in parsing.  Should "either" be removed?

Section 5.3.1.[123] are listed as such in TOC yet the notation in the
body is 5.3.1-[123].  I suspect the former is more appropriate.

In S 5.5.1:

         The link between (802.1D) bridges B-1 and B-2 is meant to be
         disabled by STP.  In the RBridge case, however, there is no
         indication (from STP) that this link is redundant.  Moreover, in
         order to avoid breaking bridge learning, either RB-a or RB-b
         will be the DR and - as a result, only one of the links (B-
         1<=>RB-a, B-2<=>RB-b) will get used.

s/DR/DRB/ or something else?

         [2]   Touch, J., R. Perlman, (ed.) "Transparent Interconnection
               of Lots of Links (TRILL): Problem and Applicability
               Statement", work in progress, draft-touch-trill-prob-
               00.txt, November, 2005.

This ref should be updated to point to draft-ietf-trill-prob.

On Thu, 1 May 2008, Erik Nordmark wrote:
> At the TRILL WG meeting in Philadelphia you volunteered to review the
> TRILL architecture document and send comments (or a "It is fine" email)
> to the WG mailing list.
>
> Can you review it in the next few weeks? If not, let us know.
>
> The document is at
> www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-05.txt
>
> Please send comments on the document to the WG mailing list.
>
> If you have some other concerns please send them to the co-chairs.
>
>    Erik and Donald
>

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings