Donald and Alvaro: Do we have an agreed upon text changes? If so, can we send a proposed change to Alvaro for review prior to Thursday's meeting?
Sue Hares -----Original Message----- From: Donald Eastlake [mailto:[email protected]] Sent: Monday, March 5, 2018 3:27 PM To: Alvaro Retana Cc: The IESG; [email protected]; [email protected]; Susan Hares; trill IETF mailing list Subject: Re: Alvaro Retana's Discuss on draft-ietf-trill-directory-assisted-encap-10: (with DISCUSS) Hi Alvaro, On Mon, Mar 5, 2018 at 2:32 PM, Alvaro Retana <[email protected]> wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-trill-directory-assisted-encap-10: Discuss > > ... > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I have significant concerns about this document; as currently written, > I believe the technology is underspecified and can cause significant > damage to a DC network where it might be deployed. I am then balloting a > DISCUSS. > > The document (including the security considerations) is written > assuming that the TRILL-ENs can be trusted (and are not compromised), > and that the directory information is accurate. However, I believe > there are several cases that have been overlooked. > > (1) There aren't any basic safeguards specified to at least make sure > that a TRILL-EN is doing the right thing (or something sensible). For > example, what if the Ingress RBridge Nickname field in the TRILL > header doesn't correspond to the first rBridge at the domain boundary? > Should that frame be accepted? This concern doesn't seem very different from the general insecurity of Layer 2. If a link has no TRILL router adjacencies, then I guess it it reasonable to check that the ingress nickname is that of the receiving RBridge but it gets harder if you have a mixed link with both end stations and TRILL routers (probably rare in deployments but, on the other hand, in TRILL a "link" can be a bridged LAN...). > (2) rfc8171 talks about issues with incorrect directory mappings. > Consider the case where a TRILL-EN uses (on purpose!) an incorrect > mapping. That "can result in data being delivered to the wrong end > stations, or set of end stations in the case of multi-destination packets, > violating security policy." > [rfc8171] How can this risk be mitigated? I'm not sure how using "an incorrect mapping" is that different from just using whatever nicknames it feels like... > I don't think that there are easy mitigations for these issues, but at > least mentioning them so that operators are aware of the risk would be > enough to clear this DISCUSS. It is certainly reasonable to mention these. One possible mitigation is the use of end-to-end encryption. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA [email protected] _______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
