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

[Stephen Farrell <[e-mail]>]

Hi Don,

Yes, that'd do the job. If there were any sensible pointers
to the kind of proprietary things folks do (e.g. in some
workshop paper or product documentation) then that might be
useful, but I can imagine there might not be.

Thanks,
S.

On 24/09/15 04:46, Donald Eastlake wrote:
> 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]