Re: [trill] Stephen Farrell's Discuss on draft-ietf-trill-pseudonode-nickname-06: (with DISCUSS)

[Donald Eastlake <[e-mail]>]

Hi Stephen,

Would the following change resolve your DISCUSS?

OLD
   This draft does not introduce any extra security risks. For general
   TRILL Security Considerations, see [RFC6325].

NEW
   Since currently deployed LAALPs [RFC7379] are proprietary, security
   over membership in and internal management of active-active edge
   groups is proprietary. A rogue RBridge that insinuates itself into
   an active-active edge group can disrupt end station traffic flowing
   into or out of that group. For example, if there are N RBridges in
   the group, it could typically control 1/Nth of the traffic flowing
   out of that group and a similar amount of unicast traffic flowing
   into that group.  For multi-destination traffice flowing into that
   group, it could control all that was in a VLAN for which it was DF
   and it can exercise substantial control over the DF election by
   changing its own System ID.

   For general TRILL Security Considerations, see [RFC6325].


Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]


On Thu, Sep 17, 2015 at 9:49 AM, Donald Eastlake <[e-mail]> wrote:
> Hi Stephen,
>
> On Thu, Sep 17, 2015 at 6:34 AM, Stephen Farrell
> <[e-mail]> wrote:
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-trill-pseudonode-nickname-06: Discuss
>>
>> ...
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-trill-pseudonode-nickname/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>>
>> I have two questions where it's not clear to me if this
>> specification does or does not introduce new vulnerabilities.
>> It could well be that it does not and these are handled
>> elsewhere, but I'm not sure so...
>>
>> (1) How is authorization for being a member of an RBv handled?
>
> Currently I think that this is out of scope because the active-active
> edge groups, each of which is represented by an RBv, are proprietary
> MC-LAG implementations with proprietary management. (See bottom of
> page 5 of RFC 7379. This draft is standardizing a TRILL campus facing
> interface for an AAE group.)
>
>> (2) If a rogue RB can add itself to an RBv can it arrange
>> things so the rogue RB becomes the DF for the RBv?  (If so,
>> that would seem to create new DoS opportunities at least.)
>
> I don't see any problem in mentioning this in the Security Considerations.
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail]