Re: [secdir] Review of draft-ietf-trill-irb-13

[Donald Eastlake <[e-mail]>]

Hi Shawn,

On Wed, Jun 29, 2016 at 12:00 AM, Shawn M Emery <[e-mail]> wrote:
> On 06/28/16 08:56 PM, Donald Eastlake wrote:
>>
>> Hi Shawan,
>>
>> Thanks for our comments.
>>
>> On Mon, Jun 27, 2016 at 2:05 AM, Shawn M Emery <[e-mail]>
>> wrote:
>>>
>>> I have reviewed this document as part of the security directorate's
>>> ongoing effort to review all IETF documents being processed by the IESG.
>>> These comments were written primarily for the benefit of the security
>>> area directors. Document editors and WG chairs should treat these
>>> comments just like any other last call comments.
>>>
>>> This draft specifies layer 3 (inter-subnet) gateway messaging of the
>>> TRILL (Transparent Interconnection of Lots of Links) protocol.
>>>
>>> The security considerations section does exist and refers to Intermediate
>>> System to Intermediate System (IS-IS) authentication (RFC 5310) for
>>> securing
>>> information advertised by Routing Bridges.  For generic TRILL security
>>> the
>>> draft refers to RFC 6325.  For sensitive data, it prescribes end-to-end
>>> security, but does not reference or provide details on how this is done
>>> in
>>> a layer 3 deployment.
>>
>> Would you think it helpful if it gave IPsec and/or TLS as examples of
>> protocols that might be used for end-to-end security?
>
> Yes, whatever is commonly used in TRILL and if there are ones that shouldn't
> be used then I would suggest writing text describing why not.

End stations attached to a TRILL campus think they are on the same
local link unless they use or listen for special link control or TRILL
IS-IS PDUs. So I would say it is no business of TRILL's to say what
end-to-end security protocol they should or shouldn't use. The
Security Considerations section is just pointing out the general
recommendation that end-to-end security is a good idea to supplement
any security of more limited transit scope, particularly for sensitive
information.

>>> General comments:
>>>
>>> None.
>>>
>>> Editorial comments:
>>>
>>> Does TRILL and FGL need to be expanded in the Abstract and Introduction
>>> section, respectively?
>>> I think it would be helpful to describe the "Inner.VLAN" syntax used
>>> throughout the document.
>>
>> The payload of a TRILL Data packet looks like an Ethernet frame with a
>> VLAN tag which is the inner.VLAN. This could be added to the
>> definitions in Section 2.
>
> Thanks for clarifying.
>
>> ...
>>>
>>> s/optimal pair-wise forwarding path/optimal pair-wise forwarding paths/
>>
>> I don't see that in version -13.
>
> The text was part of a new-line.  Let's try:
>
> s/wise forwarding path/wise forwarding paths/

Ah, sorry, found it now. OK.

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

> Shawn.
> --