I agree this security issue #4 can be closed based on the response by the authors that the security filtering does not rely on presence of an SRH.
Thank you Gyan On Tue, Aug 8, 2023 at 11:01 AM Joel Halpern <j...@joelhalpern.com> wrote: > Issue #4 reads: > > In some cases it is possible that the SR policy can be expressed purely > with C-SIDs without requiring an SRH. In this case, to allow the SR domain > to fail closed, some form of filtering based on the LOC part of the SRv6 > SID is required as relying purely on the presence of an SRH will not be > sufficient. > > I would also like to note upfront that it is already possible based on > RFC8754 to send packets without an SRH (e.g. one segment encapsulated into > outer header) but having C-SIDs makes it applicable to a wider set of use > cases. > > The response from the editors reads: > > Added text in revision -01 (Sec. 12 > <https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression-05#section-12>) > indicating that the SRv6 security model (Sec. 5.1 of RFC 8754 > <https://www.rfc-editor.org/rfc/rfc8754.html#section-5.1>) also applies > to the SIDs defined in draft-ietf-spring-srv6-srh-compression. > > The SRv6 security model uses IP address filtering (SRv6 SID block) and > does not rely on the presence of an SRH. > > > Please indicate to the list whether you consider this resolution > sufficient to close the issue, or have further concerns that should be > addressed. If you have concerns, clarity about them is appreciated. This > call is open for two weeks, through August 22. > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
