Hi Donald, Thanks for your response, inline.
On Wed, Mar 14, 2018 at 4:52 PM, Donald Eastlake <d3e...@gmail.com> wrote: > Hi Kathleen, > > On Wed, Mar 14, 2018 at 2:28 PM, Kathleen Moriarty > <kathleen.moriarty.i...@gmail.com> wrote: >> Hi Donald, >> >> Thanks for the proposed text. Please see inline. >> >> On Mon, Mar 12, 2018 at 10:01 PM, Donald Eastlake <d3e...@gmail.com> >> wrote: >>> Hi Kathleen, >>> >>> Would the following replacement Security Considerations section for >>> draft-ietf-trill-transport-over-mpls be adequate? >>> >>> >>> This document specifies methods using existing standards and >>> facilities in ways that do not create new security problems. >>> >>> For general VPLS security considerations, including discussion of >>> isolating customers from each other, see [RFC4761] and [RFC4762]. >>> >>> For transport of TRILL by Pseudowires security consideration, see >>> [RFC7173]. In particular, since pseudowires are support by MPLS or IP >>> which are in turn supported by a link layer, that document recommends >>> using IP security or the lower link layer security. >>> >>> For added security against the compromise of data end-to-end >>> encryption and authentication should be considered; that is, >>> encryption and authentication from source end station to destination >>> end station. >> >> Would this be accomplished through IPsec? > > For end-to-end security, it could be. Or DTLS. Whatever is convenient for > the information you want to protect. Since end stations are connected to > edge TRILL switches via Ethernet, if you wanted to protect all of the data > between two end stations, you could use IEEE Std 802.1AE. Do you want a list > added? Yes, I think that would be helpful. Thank you. > >> If encryption and authentication are not employed, what are the risks >> to tenant isolation since this draft joins TRILL campuses? > > I wouldn't say that the draft "joins TRILL campuses". If a TRILL campus is > actually structured so that the connectivity being provided is connecting > two islands, then you could say it is making those TRILL switches parts of > the same campus. The term "campus" in TRILL is not intended to have any > geographic (or academic) implication but rather, to be for TRILL switches > the same as the term "bridged LAN" is for IEEE 802.1 bridges. > > Whenever a link extends outside local physical control, there is increased > risk. Assuming a link between two TRILL switch ports in a TRILL campus is > Ethernet, it could be anything from a little copper on a backplane inside a > cabinet to Ethernet connectivity purchased from a carrier and extending > hundreds of miles. > > If you are talking about the risk of a TRILL campus merging with a malicious > TRILL switch, that can be avoided by IS-IS PDU authentication. Until > adjacency is establish (RFC 7177), which requires successful exchange of > IS-IS Hellos PDUs, no data will flow. > >> I think >> there should be text that explains this risk in addition to the text >> already proposed. > > How about adding text like the following: > > > Transmission outside the customer environment through the provider > environment, as described in this document, increases risk of compromise or > injection of false data through failure of tenant isolation or by the > provider. In the VPLS model (Section 3), the use of link encryption and > authentication between the CEs of a tenant that is being connected through > provider facilities should be a good defense. In the VPTS model (Section 4), > it is assumed that the CEs will peer with virtual TRILL switches of the > provider network and thus link security between TRILL switch ports is > inadequate as it will terminate at the edge PE. Thus, end station to end > station encryption and authentication is more appropriate for the VPTS > model. That's helpful, thanks for the proposed text. Best regards, Kathleen > > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e...@gmail.com > >> Thanks, >> Kathleen >> >>> >>> For general TRILL security considerations, see [RFC6325]. >>> >>> >>> Thanks, >>> Donald >>> =============================== >>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>> 155 Beaver Street, Milford, MA 01757 USA >>> d3e...@gmail.com >>> >>> On Wed, Mar 7, 2018 at 5:35 PM, Andrew G. Malis <agma...@gmail.com> >>> wrote: >>>> >>>> Kathleen, >>>> >>>> I don’t want to speak for the authors. However, I did contribute to this >>>> draft (although not this specific section). So that said, here’s my two >>>> cents …. >>>> >>>> I agree that first sentence could have been worded better, but the >>>> bottom >>>> line is that depending on the model used, the security considerations >>>> for >>>> RFC 7173, 4761, or 4762 applies, including the discussions in those RFCs >>>> on >>>> issues such as isolation and end-to-end security. Those RFCs are >>>> referenced >>>> in the security section. So the substance is already there, perhaps the >>>> draft just needs better pointers to it. >>>> >>>> Cheers, >>>> Andy >>>> >>>> >>>> On Wed, Mar 7, 2018 at 5:01 PM, Kathleen Moriarty >>>> <kathleen.moriarty.i...@gmail.com> wrote: >>>>> >>>>> Kathleen Moriarty has entered the following ballot position for >>>>> draft-ietf-trill-transport-over-mpls-07: Discuss >>>>> >>>>> When responding, please keep the subject line intact and reply to all >>>>> email addresses included in the To and CC lines. (Feel free to cut this >>>>> introductory paragraph, however.) >>>>> >>>>> >>>>> Please refer to >>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>> >>>>> >>>>> The document, along with other ballot positions, can be found here: >>>>> https://datatracker.ietf.org/doc/draft-ietf-trill-transport-over-mpls/ >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> I was very surprised to see the following in the security >>>>> considerations >>>>> section and would like to work with you on improvements. >>>>> As an informational document specifying methods that use only >>>>> existing standards and facilities, this document has no effect on >>>>> security. >>>>> >>>>> Having watched many TRILL documents go by in the last 4 years, we >>>>> didn't >>>>> push >>>>> too hard on security in some cases as a result of the restriction to a >>>>> campus >>>>> network. This particular document extends into multi-tenancy where >>>>> there >>>>> are >>>>> certainly security considerations introduced to be able to provide >>>>> isolation >>>>> properties. MPLS offers no security and it is being used to join TRILL >>>>> campuses as described int his draft. This is done without any >>>>> requirement of >>>>> an overlay protocol to provide security - why is that the case? >>>>> Minimally, the >>>>> considerations need to be explained. Ideally, a solution should be >>>>> offered to >>>>> protect tenants when TRILL campuses are joined. >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> trill mailing list >>>>> trill@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/trill >>>> >>>> >>> >> >> >> >> -- >> >> Best regards, >> Kathleen -- Best regards, Kathleen _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill
