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

[Mingui Zhang <[e-mail]>]

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.

OLD
   Thus,
   remote edge RBridges are required to keep multiple locations of one
   MAC address in one Data Label.
END
NEW
   Thus,
   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.
END

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:-)

Thanks,
Mingui