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

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

On 01/11/17 11:56 AM, Donald Eastlake wrote:
> Hi Shawn,
>
> A version -04 has been uploaded with these fixes.

I have just one suggested update, provided that the update is an 
accurate statement:

OLD:
As such, they are securable through the addition to those PDUs 
Authentication TLVs [RFC5310] in the same way as Hellos or other IS-IS PDUs.

NEW:
Therefore, they are securable through the addition of Authentication 
TLVs [RFC5310] in the same way as Hellos or other IS-IS PDUs.

and one editorial:

s/It this case/In this case/

The rest of the changes looks good to me.

Thanks,

Shawn.
-- 
> On Wed, Jan 11, 2017 at 12:22 AM, Shawn M Emery<[e-mail]>  wrote:
>> 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.
>> --