[rbridge] [Fwd: A Review of TRILL architecture document]
Eric Gray
eric.gray at ericsson.com
Fri May 23 15:00:33 PDT 2008
Pekka,
Thanks for taking the time to do this review.
Please see comments in line below.
--
Eric Gray
Principal Engineer
Ericsson
> -----Original Message-----
> From: rbridge-bounces at postel.org
> [mailto:rbridge-bounces at postel.org] 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]
>
> 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).
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"?
>
> 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?
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.
>
> 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.)
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).
>
> 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.
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).
>
> 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?
Yes to both of these. Thanks for pointing them out.
>
> 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.
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.
>
> 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?
DRB. Again, thanks.
>
> [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.
Yes.
>
> 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
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
More information about the rbridge
mailing list