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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 19 Aug 2015 05:01:29 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-trill-aa-multi-attach-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-aa-multi-attach/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- 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.

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

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

- 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.

---

From: Mingui Zhang <[email-masked]>
Date: Thu, 20 Aug 2015 06:13:09 +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.

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])".

> (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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Aug 2015 10:12:32 +0100

Hiya,

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

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.

> "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

---

From: Mingui Zhang <[email-masked]>
Date: Fri, 21 Aug 2015 01:32:36 +0000

Hi Stephen,

Thanks for the suggestions!

> 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

[MZ] I agree the word "association" is more easily to be understood. Let's incorporate the text. And, since the word "attach" is used everywhere, it'd be helpful to relate them as below.

...maintain all those associations (i.e., MAC attachments) and ...

> Heh:-) I'm not so sure I agree that faking an ESADI message from the right
> place within the campus would be that hard.

[MZ] Yes, I agree. Faking an ESADI message is possible and it has been captured in [RFC7357].

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

[MZ] Yes, we did:-)

Thanks,
Mingui