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
