Re: [trill] Stephen Farrell's No Objection on draft-ietf-trill-aa-multi-attach-04: (with COMMENT)

Mingui Zhang <> Thu, 20 August 2015 06:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D60E21B2C0E; Wed, 19 Aug 2015 23:13:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KDCzGOpEiwdD; Wed, 19 Aug 2015 23:13:42 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A625E1B2C0D; Wed, 19 Aug 2015 23:13:40 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id BWN03034; Thu, 20 Aug 2015 06:13:39 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 20 Aug 2015 07:13:17 +0100
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Thu, 20 Aug 2015 14:13:10 +0800
From: Mingui Zhang <>
To: Stephen Farrell <>, The IESG <>
Thread-Topic: Stephen Farrell's No Objection on draft-ietf-trill-aa-multi-attach-04: (with COMMENT)
Thread-Index: AQHQ2n297KACDXoA4Ui65GT9PKA+k54UH08A
Date: Thu, 20 Aug 2015 06:13:09 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Cc: "" <>, "" <>, "" <>, "" <>, "" <>, "" <>
Subject: Re: [trill] Stephen Farrell's No Objection on draft-ietf-trill-aa-multi-attach-04: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Aug 2015 06:13:44 -0000

Hi Stephen,

Thanks for the comments!

> - abstract: "Thus, remote edge RBridges are required to keep multiple
> locations of one MAC address in one Data Label." I find that very hard to read
> and don't understand what it's telling me. Even if these terms are terms-of-art
> for trill, it'd be worth being less opaque in the abstract. I have the same
> problem with the intro. I think if you tried to be specific about whose MAC
> address you mean (a host attached to RBridges in the AAE) and also explained
> (or avoided) the term "Data Label" here that'd help.

[MZ] I find the word "location" is causing the confusion. I'd like to use "attachment" instead.

In the abstract, I believe, the following change will clear the confusion.

   remote edge RBridges are required to keep multiple locations of one
   MAC address in one Data Label.
   remote edge RBridges will see one MAC address being attached to
   multiple RBridges. These remote edge RBridges are required to keep
   all the attachments rather than flip-flop among them.

In the intro, the term "Data Label" will be explained as "Data Label (VLAN or Fine Grained Label [RFC7172])".

> - 5.1: for how long is a remote RBridge "required to adhere"?
> (Sorry if that's clear in 4.1, in which case I missed it.)

[MZ] Yes, I think it is clear. Please take a look.

   "So the receiving edge RBridge will stick to this MAC
   attachment until it is overridden by one learned from the ESADI
   protocol [RFC7357]."

> - 5.3.2: "well-known split horizon technique" just screams for a reference.
> Please add one, which is presumably easy to do as this is well-known:-)

[MZ] Sure. Will fix it.

> - security considerations: I'm surprised there's nothing new here. Did someone
> do the analysis to check? (Sorry for doubting you but security considerations
> sections like this that only consist of references are often an indicator that
> nobody did take a real look;-) One possible example (not sure if it
> works): if I can fake an ESADI message then I could pretend to be the RBridge in
> the AAE that has least cost and so lots of traffic would be sent to me, instead of
> the real RBridges in the AAE.  Compared to the situation without this
> specification, that might mean a more effective attack. Now I'm not really sure
> if that's true or not (I'm sure you'll tell me) but my question is whether or not
> those kinds of thing were considered already.

[MZ] In order to achieve that kind of attack, the attacker need to fake another message, the "AA LAALP Grouped RBridges" APPsub-TLV. This TLV is used to achieve the discovery as a member of AAE. This APPsub-TLV is hard to fake since the attacker has to fake the nickname, ISIS System ID, etc, in order to make this APPsub-TLV to be effective. That is equally hard as faking a real RBridge. In other words, this document creates no new security issues that are not already present in the references. I realize such assertion should be included in the beginning of this section:-)