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
