Subject: [trill] draft-ietf-trill-smart-end-nodes-06.txt - Comments upon forwarding to the AD

From: "Susan Hares" <[email-masked]>
Date: Mon, 22 Jan 2018 11:53:49 -0500

Version 6 fixes the issues we discussed in IETF 99 and 100 - so I am
forwarding this to the AD for Evaluation. 

I want to complement you on improving the readability of the draft. 

Two editorial nits exist, and I will be asking the AD one significant
question which I provide to you.  This question arose out of a discussion
with the Security ADs last week (which was original scheduled in November). 

I had been awaiting the meeting with the Security ADs before forwarding this
draft.   Hopefully, it will raise this question early in the process. I
apologize to the authors (especially Fangwei and Donald) for the lengthy
delay in posting this shepherd review. 

We have also been awaiting the response from Julien Meuric in his routing
directorate review. 

https://www.ietf.org/mail-archive/web/rtg-dir/current/msg02740.html

I've sent another query to him this morning.  The authors and I will need to
work all of these reviews in parallel as we do not have enough time to work
these in series.  I would like to ask the authors of
draft-ietf-smart-end-nodes to be watching all of this email.  I am going to
push to resolve all issues quickly this week.  Please be ready to revise
this document based on exterior reviews. 

Sue Hares 

------------

Significant Security question: 

Shepherd question to the AD (1/22/2018): 

Does this security section need to explain the risks of an 

end-node participating with secured hellos using 

authentication TLVs [RFC5310], TRILL ES-IS Security [RFC8171],

ISIS general cryptographic security, and TRILL's general 

security considerations.  The WG thought was to not repeat

the thought and comments presented in these other drafts.

The WG believes that with TRILL security and authentication 

this end node is as secure as the main TRILL infrastructure and 

any IS-IS infrastructure. Does the draft need a summary of these mechanisms
in the draft? 

If so this could be added in section 7.  Otherwise, section 7 is very brief.

Should possible attack vectors for remote dual homed nodes be added

to section 7.  These attack vectors are similar for any stub ISIS/OSPF node.

As you will note in the  IESG review draft-ietf-ospf-link-overload-12, the 

potential attacks for stub ISIS/OSPF nodes or smart-end nodes may be
slightly 

different than core nodes.  However, this is a general case of problems. 

In general, I think this general attack vector belongs in a routing-area

related draft relating to all IGPs (OSPF, ISIS, Babel) or IGP that support

L2 forwarding (E.g. TRILL).

Editorial nits  - catch next time you do a revision or as RFC editor note

Page 6 in Holding time: paragraph. 

 Old /Holding Time in the IS-IS Hellos [IS-IS] ./

New/Holding Time in the IS-IS Hellos [IS-IS]./ 

(note your processor added a space prior to the period.) 

Page 8 section 5.2 last paragraph

OLD/nickname as the niknamae/

New/nickname as the nickname/

Sue Hares