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

[Donald Eastlake <[e-mail]>]

Hi Stephen,

On Thu, Sep 24, 2015 at 4:27 PM, Stephen Farrell
<[e-mail]> wrote:
>
>
> On 24/09/15 21:26, Donald Eastlake wrote:
>> Hi Stephen,
>>
>> On Thu, Sep 24, 2015 at 6:58 AM, Stephen Farrell
>> <[e-mail]> wrote:
>>>
>>> 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.
>>
>> I'm not aware of such write-ups.
>
> Fair enough, wasn't meant as a blocking comment anyway, so
> I'm fine to clear with your suggested change.

draft-ietf-trill-pseudonode-nickname-07.txt has been uploaded with
this change in it. So, unless you have further comments, we'd
appreciate it if you cleared you DISCUSS.

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

> S
> g
>
>>
>> Thanks,
>> Donald
>> =============================
>>  Donald E. Eastlake 3rd   [phone] (cell)
>>  155 Beaver Street, Milford, MA 01757 USA
>>  [e-mail]
>>
>>> 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]
>>