Hi, Thanks for the ping and updated text, I must not have seen the original message for some reason.
Best regards, Kathleen On Mon, Feb 12, 2018 at 9:20 AM, Alvaro Retana <aretana.i...@gmail.com> wrote: > Kathleen: > > Hi! > > When you get a chance, please take a look at Les’ updates. > > Thanks! > > Alvaro. > > On January 12, 2018 at 6:06:24 PM, Les Ginsberg (ginsberg) > (ginsb...@cisco.com) wrote: > > Kathleen - > > I propose the following addition to the end of Section 8. > > "The use of best practices to reduce the risk of tampering within > the trusted domain is important. Such practices are discussed in > [RFC4381] and are applicable to both SR-MPLS and SRv6." > > Les > > >> -----Original Message----- >> From: Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com] >> Sent: Friday, January 12, 2018 10:58 AM >> To: Alvaro Retana <aretana.i...@gmail.com> >> Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; The IESG >> <i...@ietf.org>; spring@ietf.org; spring-cha...@ietf.org; >> draft-ietf-spring- >> segment-rout...@ietf.org; martin.vigour...@nokia.com >> Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-spring-segment- >> routing-13: (with DISCUSS) >> >> Hi, Alvaro! >> >> Thanks for bringing this to my attention, the message from Les slipped >> through the cracks. >> >> On Thu, Jan 11, 2018 at 4:57 PM, Alvaro Retana <aretana.i...@gmail.com> >> wrote: >> > Kathleen: >> > >> > Hi! >> > >> > Any thoughts on the update to this document? >> > >> > Thanks! >> > >> > Alvaro. >> > >> > On December 20, 2017 at 6:42:02 PM, Les Ginsberg (ginsberg) >> > (ginsb...@cisco.com) wrote: >> > >> > Kathleen - >> > >> > Thanx for the review. >> > V14 has been published and it attempts to address the Security >> > concerns raised by you and others. >> > Look forward to your feedback. >> > >> > Inline. >> > >> >> -----Original Message----- >> >> From: Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com] >> >> Sent: Wednesday, December 13, 2017 7:55 PM >> >> To: The IESG <i...@ietf.org> >> >> Cc: draft-ietf-spring-segment-rout...@ietf.org; >> >> aretana.i...@gmail.com; spring-cha...@ietf.org; >> >> martin.vigour...@nokia.com; spring@ietf.org >> >> Subject: Kathleen Moriarty's Discuss on >> >> draft-ietf-spring-segment-routing- >> >> 13: (with DISCUSS) >> >> >> >> Kathleen Moriarty has entered the following ballot position for >> >> draft-ietf-spring-segment-routing-13: 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-spring-segment-routing/ >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> - >> >> DISCUSS: >> >> --------------------------------------------------------------------- >> >> - >> >> >> >> While I understand the assumption that following the capabilities of >> >> existing protocols that incorporate similar functionality is okay, >> >> I'd like to walk through the security properties left off in the >> >> security considerations section to prevent tampering and see what can >> >> be done to correct that or minimally to list out the considerations. >> >> >> >> There's a few places in the security considerations section to call >> >> out specifically. >> >> >> >> Section 8.1: >> >> "The received information is validated using existing control plane >> >> protocols providing authentication and security mechanisms. Segment >> >> Routing does not define any additional security mechanism in existing >> >> control plane protocols." >> >> >> >> For MPLS what "security mechanisms" are referred to in this text? It >> >> would be helpful to list any properties explicitly or drop this >> >> phrase if there are no additional security mechanisms. Since segment >> >> routing lists an explicit list of segments (I see that this can be >> >> done with MPLS labels and you note it is already exposed), why is >> >> there no mention of integrity protection and origin authentication to >> >> prevent tampering? I think EKR's comment is already hinting at this >> >> with his comments on IPv6, but I'd like to see explicit text to >> >> preferably fix this gap in the architecture, but minimally to >> >> document it and the associated security threats that result from this >> >> gap for MPLS and IPv6. >> >> >> > >> > [Les:] We have reemphasized that SR is designed to be used within a >> trusted >> > domain. As such, any attacker who sees a segment list already has >> breached >> > the domain protections. >> > >> >> Section 8.2: >> >> >> >> "From a network protection standpoint, there is an assumed trust model >> >> such that any node adding an SRH to the packet is assumed to be >> >> allowed to do so. Therefore, by default, the explicit routing >> >> information MUST NOT be leaked through the boundaries of the >> >> administered domain. Segment Routing extensions that have been >> >> defined in various protocols, leverage the security mechanisms of >> >> these protocols such as encryption, authentication, filtering, etc." >> >> >> >> This document focuses on the same threats as the MPLS use cases with >> no >> >> mention of tampering or mitigations. Text should be added to describe >> how >> >> origin authentication and integrity are provided in the source routing >> >> header >> >> for IPv6 with the associated threats or to describe this gap if a >> >> solution >> >> does >> >> not exist. I have not read the draft referred to at the start of this >> >> section, so I >> >> don't know if it addresses the concern or not. In any case, this >> >> document >> >> isn't complete without some text on tampering considerations within >> >> your >> >> trusted domain. >> >> >> > [Les:] The architecture draft is NOT proposing support of SRH introduced >> > outside the domain of trust. Such support is an exception to the >> > architecture. When done the use of origin authentication would be >> > appropriate, but such an exception is not being described nor advocated >> > in >> > this document. >> >> Here I'm asking about tampering within the trusted domain, not just a >> statement that this is expected to occur within a trusted domain. If >> there are no mitigations, that is a security consideration that should >> be stated explicitly as a risk and it's fine if you tie it to your >> assumed trust model. >> >> So describing the gap in the text as requested in one of the options >> to address the discuss seems like the approach needed here. >> >> Thank you, >> Kathleen >> >> > >> > Les >> > >> >> Thank you. >> >> >> >> >> >> >> > >> >> >> >> -- >> >> Best regards, >> Kathleen -- Best regards, Kathleen _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
