Re: [secdir] Review of draft-ietf-trill-rfc6439bis-03

[Shawn M Emery <[e-mail]>]

On 01/10/17 06:03 PM, Donald Eastlake wrote:
> Hi Shawn,
>
> Thanks for your comments. See below.
>
> On Mon, Jan 9, 2017 at 12:11 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 updates the Appointed Forwarders mechanism (RFC 6439);
>> which supports multiple TRILL switches that handle native traffic
>> to and from end stations on a single link.
>>
>> The security considerations section does exist and states that this
>> update does not change the security properties of the TRILL base
>> protocol.  The section goes on to state that the Port-Shutdown message
>> SHOULD be secured through the Tunnel Channel protocol (which is in draft
>> state).  Was this intended to be a normative reference?
> That reference is out of date. draft-ietf-trill-channel-tunnel has
> issued as RFC 7978. That should be updated and I agree that this
> should be a normative reference.

Thanks.

>>                                                                                            The section quickly
>> finishes with a reference to Authentication TLVs as a way to secure E-LICS
>> FS-LSPs traffic.  I'm not a TRILL expert and therefore find it difficult to
>> distinguish between the usage of Tunnel Channels and Authentication TLVs for
>> securing Port Shutdown messaging.  Could you please clarify?
> "Channel Tunnel", although left in the draft name for convenience, was
> basically changed to RBridge Header Extension. This is a way to add a
> layer of header to RBridge Channel messages (specified in RFC 7178) to
> secure their content. The Authentication TLV is an IS-IS TLV and
> including that TLV in an IS-IS PDU can be used to secure the content
> of the PDU. Some text can be added to clarify this.

Ah, I see.  Yes, clarifying text would be helpful for the nascent reader.

>> General comments:
>>
>> None.
>>
>> Editorial comments:
>>
>> s/the need to "inhibition"/the need for "inhibition"/
>> s/forarding/forwarding/
>> s/two optimization/two optimizations/
>> s/messages are build/messages are built/
> Thanks for spotting those. We'll fix them.

No problem.

Regards,

Shawn.
--