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. #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.) #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. 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. _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
