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

[Stephen Farrell <[e-mail]>]

Hiya,

On 20/08/15 07:13, Mingui Zhang wrote:
> 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])".

Good improvements. For this (fairly ignorant) reader though, saying
"keep all the attachments" is still a bit puzzling. If that's normal
trill phraseology then it's probably best as-is, but if not, maybe
it'd be better something like:

NEWNEW
    Thus, remote edge RBridges (who are not in the group) will see
    one host MAC address being associated with the multiple RBridges
    in the group. Such remote edge RBridges are required to
    maintain all those associations and to not flip-flop among them
    which would be the behaviour prior to this specification.
NEWNEW

But your call as to what you find better.

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

Heh:-) I'm not so sure I agree that faking an ESADI message from
the right place within the campus would be that hard. But I also
note that you've answered that my example doesn't work which is
fine, but you didn't explicitly say that the general analysis had
been done. I'll assume that you did mean that though:-)

Cheers,
S.


> 
> Thanks, Mingui
>