On Thu, Oct 22, 2026 at 8:12 AM Christopher Inacio via Datatracker < [email protected]> wrote:
> Christopher Inacio has entered the following ballot position for > draft-ietf-spring-srv6-security-19: No Objection > > 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/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-security/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks to Christian H. for the SECDIR review. > > Truly, thank you to the authors for writing this draft; as a SECAD I > appreciate > this effort. > > #1 I support Roman's discuss. It is always hard to define your security > boundary when building a secure system, but the lines become quite blurred > in > this document. > I believe we have addressed the blocking issues in the latest versions. Please let us know if that is not the case. Other issues with trusted domain and filtering seem related and are addressed below. > > #2 While covered in section 7.1.1, filtering seems to be required to play > an > outsized role in the security of this and getting filtering correct on a > continuing basis is extremely challenging. Especially, as mentioned, when > there are potentially limited resources for the filtering. Commenting on > the > tradeoff between how to use those limited resources (e.g. rule limits > because > of TCAMS) and the tradeoff between denying too much / allowing too much > could > be helpful. > > Better yet might be some recommendations for future improvements in > protocol > design; I think device implementation can easily request infinite CAMs > (that > you will never receive, obviously.) > We had some of this in prior versions and it was removed because it sounded somewhat vague due to there being vastly different resources on platforms. Most of the heavy lifting of the filtering recommendations are handled by RFC 8402 and RFC 4381. Because of the nature of SR, filtering does play a somewhat outsized role even with using a prefix from the assigned RFC9602 address block. In my operational practice, this filtering tends to be rolled into existing ingres ACLs with one or two extra lines of config. If you or others have suggestions I would welcome them, overall the WG felt that it was better to rely on existing documents that covered the trusted domain topic. > > #3 And this is related to #1, but encapsulation could still take another 10 > pages to possibilities and approaches. I don't have a particularly good > recommendation here. Other than relying on filtering seems to be > problematic. > I'm still trying to understand this comment. Could you elaborate a bit? That said, I think we cover other options such as use of non-globally-routed blocks, but again, those will rely on perimeter filtering as well if done in a complete manner and in accordance with RFC 8402. > > Lastly, I will state this as a meta-comment: this approach feels like the > security approach from the '90s, with a defensible border. Security > approaches > have definitely moved beyond the defensible border into stronger > authentication > and encryption from end-point to end-point. But I cannot say a particular > recommendation in here isn't something operators with what is currently > available should not consider. > You aren't totally off here. In my experience with wide area networking the boundary is often squishy and defined by the ASN(s) + management authority. Because of that we also rely on other more specific documents that better define these areas.
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
