Directory-Assisted Transparent Interconnection of Lots of Links (TRILL) Encapsulation
RFC 8380

Note: This ballot was opened for revision 09 and is now closed.

(Alia Atlas) Yes

Deborah Brungard No Objection

Comment (2018-03-06 for -10)
No email
send info
Support comments by Alvaro and Kathleen on security aspects.

(Ben Campbell) No Objection

Comment (2018-03-07 for -10)
No email
send info
I support Alvaro's DISCUSS and Kathleen's comments

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

Suresh Krishnan No Objection

Alexey Melnikov No Objection

Comment (2018-03-07 for -10)
No email
send info
Agreeing with Alvaro's DISCUSS.

(Kathleen Moriarty) No Objection

Comment (2018-03-03 for -09)
No email
send info
Thanks for your work on this document.  I'd like to see stronger language used in the security considerations section.  I'll propose edits for you to consider:

OLD:
Therefore, there could be a potential security risk
   when the TRILL-ENs are not trusted.  In addition, if the path between
   the directory and the TRILL-ENs are attacked, false mappings can be
   sent to the TRILL-EN causing packets from the TRILL-EN to be sent to
   wrong destinations, possibly violating security policy. Therefore, a
   combination of authentication and encryption should be used between
   the Directory and TRILL-EN. The entities involved will need to
   properly authenticate with each other to protect sensitive
   information.

NEW: 
   Therefore, there could be a potential security risk
   when the TRILL-ENs are not trusted or are compromised.  In addition, if the path between
   the directory and the TRILL-ENs are attacked, false mappings can be
   sent to the TRILL-EN causing packets from the TRILL-EN to be sent to
   wrong destinations, possibly violating security policy. Therefore, a
   combination of authentication and encryption is RECOMMENDED between
   the Directory and TRILL-EN. The entities involved will need to
   properly authenticate with each other, provide session encryption, maintain
   security patch levels, and configure their systems to allow minimal access and
   running processes to protect sensitive information.

(Eric Rescorla) No Objection

Comment (2018-03-07 for -10)
No email
send info
I support Alvaro's DISCUSS and Kathleen's comment

I also think it would be useful to emphasize the need for some security on the links between the egress and ingress nodes, although presumably that's a standard TRILL consideration.

Finally
      nodes. Such spoofing cannot cause looping traffic because TRILL has a
     hop count in the TRILL header [RFC6325] so that, should there be a
      loop, a TRILL packet caught in that loop (i.e., an encapsulated
      frame) will be discarded.

Is it in fact the case that it cannot cause looping or merely that the loop is contained by the hop count? Perhaps this is just a terminology issue and in routing loop just means infinite loop?

Alvaro Retana (was Discuss) No Objection

Comment (2018-03-08)
No email
send info
[Thank you for addressing my DISCUSS!]