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

From: Erik Nordmark <[email-masked]>
Date: Fri, 23 May 2008 10:12:30 -0700

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 <[email-masked]>
To: [email-masked]
CC: [email-masked], "W. Mark Townsley" <[email-masked]>
References: <[email-masked]>

(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
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 23 May 2008 17:00:33 -0500

Pekka,

	Thanks for taking the time to do this review.

	Please see comments in line below.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Erik Nordmark
> Sent: Friday, May 23, 2008 1:13 PM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] [Fwd: A Review of TRILL architecture document]
> 

The timing of this document was dictated by the charter, and has been
ammended at least once already.  The original chartered completion
date was roughly a year earlier than the current chartered completion
date, and the draft is already late for that date (March, 2008).  Note
that the current scheduled completion for the protocol specififation -
also March, 2008 - represents significantly less of a delay, since the
protocol specification was originaly expected to complete not earlier
than 6 months _after_ the architecture specification.

See http://www.ietf.org/html.charters/trill-charter.html

Per working group instruction, the current version of the draft is
constrained _not_ to make choices the working group has deemed to
be appropriate for the protocol specification.

The closest match for the term systems architecture as the working
group consistently seems to identify it is something between the
1st and 8th definitions given in Wikipedia - i.e. -

1) The fundamental organization of a system, embodied in its components,

   their relationships to each other and the environment, and the 
   principles governing its design and evolution. 
   From ANSI/IEEE 1471-2000.

and

8) The structure of components, their interrelationships, and the 
   principles and guidelines governing their design and evolution over 
   time.

There are many other definitions of the term (clearly, since there are
at least 6 other definitions in Wikipedia - which are only "between 
these two defintions as a matter of physical placement), but these two 
are close to what I believe we are trying to achieve.  You may want to
note that - defined this way - an architecture is supposed to leave 
design details to design documents.

In addition, several working group members have asked that this ID/RFC
should provide a tutorial of the technology (much like your expectation
appears to be).  I think this is accomplished in section 5.  Could you
please provide a somewhat more detailed explanation of how the current
draft "accomplishes this goal only partially"?

> could nail down most of the uncertainties) before pushing this out?

The document serves multiple purposes as it is now:

o  It serves to document the considerations that apply to any design
   that might be applied to solving the problems defined in the PS&A
   draft.
o  It attempts to document specific considerations and choices made
   in the current protocol design specification.
o  It attempts to provide a tutorial of the technological approach.

In my opinion, if the architecture document is postponed much further,
it will have been completely overcome by events, and should be allowed
to retire gracefully.  In particular, I see little purpose in having
an architecture document that describes the "architecture" specific to
an existing design.

> depending on topology but here that would not suffice.)

There is some confusion of terminology here, at least as I understand
it.  Architecurally, there is nothing about the technology that makes
it necessary to elect a "root rbridge" and the default assumption is
that each ingress serves as the "root" of a multi-point distribution
tree.

For the unicast case, the term "root rbridge" has no architectural
meaning whatsoever.

I suspect that the term you may mean is Designated RBridge - or (from
the protocol's terminology) Designated Forwarder.

However, the "security considerations" section clearly states that a
"configuration free" deployment requires an appropriate trust model.

It also states that - in the event that the deployment does not meet
this criteria - then the existing extensions that apply to routing
protocols (IS-IS specifically, in the current protocol design), can
be applied in the use of these protocols by RBridges.

Another thing to consider is that the architecture document is not
an instance of protocol design and - as such - is not implementable.
As such, publishing this document poses absolutely no security risk
to the Internet.  Hence, the contents of the security considerations
section are intended (as is the rest of the document) to provide the
"principles and guidelines" for use in design documents (in the case
of "security considerations", expectations of security considerations
in design documents).

> runs, and if the network topology / MAC addresses never converge, this

This is a good point.  I propose to add text to the security section to
point out the relative risks for certain types of attack under different
asusmptions about how MAC destination forwarding information might be
acquired.

I will think about a specific proposed addition to the section to do
this and send it out later (late next week, or early the week after).

I welcome any suggestions you might have, or any suggestions anyone
might have - for that matter.

As you say, the default mode for acquiring this information (from the
data-plane) also has security issues which may be worse under certain
circumstances.  This is implied in the (brief) paragraph that mentions
the trade-off considerations that apply in selecting the learning mode
(page 22, next to last paragraph).

> Difficulties in parsing.  Should "either" be removed?

Yes to both of these.  Thanks for pointing them out.

> body is 5.3.1-[123].  I suspect the former is more appropriate.

Yes, but that format is recognized by idnits as an "innappropriate use
of IP addresses" because of the #.#.#.# format that results.  To avoid
this annoying warning, I have been (trying to) consistently manually
change the output from generic text-printing the word document format
such that it uses the #.#.#-# format for the small number of sections
where this (annoying little) problem comes up.

> s/DR/DRB/ or something else?

DRB.  Again, thanks.

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

Yes.