Hi Eric, On Wed, Mar 7, 2018 at 11:41 PM, Eric Rescorla <e...@rtfm.com> wrote: > > Eric Rescorla has entered the following ballot position for > draft-ietf-trill-directory-assisted-encap-10: No Objection > > ... > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 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.
Sure. The links between TRILL nodes can be a variety of technologies. So security on on the links depends on the link technology and is discussed in the RFC covering TRILL over that link technology. > 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? Should probably say "...persistently looping traffic...". Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill