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

[Donald Eastlake <[e-mail]>]

Hi Shawn,

Those fixed look good to me. We should be able to implement them.

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

On Thu, Jan 12, 2017 at 7:24 PM, Shawn M Emery <[e-mail]>
wrote:

> 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]> <[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]> <[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.
> --
>
>
>