Ketan Talaulikar has entered the following ballot position for draft-ietf-spring-srv6-security-18: 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: ---------------------------------------------------------------------- Many thanks to the authors and the WG for this important work on SRv6 security considerations. This would be very helpful for everyone implementing and deploying SRv6. Note: This review is provided inline in the idnits output of v17 of this document. Please look for the tag <EoRv17> at the end to ensure you have the full review. #Updated for v18: Thanks for taking care of the discussion points and several of the comments/suggestions in my original ballot. I've only retained those (NON-BLOCKING) points that were not updated or perhaps missed out and deleted all the rest - I leave them to the authors' discretion. The idnits extracts still refer to v17. #new for v18 - please fix the warnings reported by idnits, especially the ones related to references. <editorial> Perhaps gather the practices for securing an SR domain, now spread across Sections 7.1.1 to 7.2 and 8.2, into a short subsection, for example: NEW (perhaps subsection after 7.2?) The practices described in Sections 7.1 and 7.2 can be summarized as follows: * Allocate SIDs from a dedicated address block (Section 7.1.3, [RFC9602]), separate from infrastructure and customer addresses. * Use a hierarchical locator plan that summarizes into a few prefixes [I-D.ietf-srv6ops-srv6addressing]. * Filter packets destined to the SID block at the SR domain boundary and at SRv6 enabled nodes, together with ingress source address validation (BCP 38, BCP 84) (Section 7.1.3; Section 5.1 of [RFC8754]). * Encapsulate traffic at the SR ingress node (Section 7.2). * Do not advertise locators, the SID block, or SR information in BGP outside the SR domain ([RFC8402], Section 9.2 of [RFC9252]). * Where hosts add an SRH, consider the HMAC TLV (Section 7.3; Section 5.2 of [RFC8754]). Again, just a suggestion for the authors' consideration. <about references> Unless the analysis is extended to them, RFC 9020, RFC 9256, RFC 9491 and RFC 9524 could move to the Informative References: nothing in the document as written seems to depends on them? Rest of the comments/suggestions are provide inline in the document text: 896 In order to apply such a filtering mechanism the SR domain needs to 897 have an infrastructure address range for SIDs and an infrastructure 898 address range for source addresses that can be detected and enforced. <minor> Section 7.1.3 could align with draft-ietf-srv6ops-srv6addressing: SIDs from a range separate from infrastructure and customer addressing (it calls the SID range "infrastructure"), loopbacks optionally taken from the locator, and a hierarchical plan that summarizes so the filters stay few. Now, that draft is focussed on CSID, but the hierarchical and summarization aspects apply for all of SRv6. Suggest: CURRENT In order to apply such a filtering mechanism the SR domain needs to have an infrastructure address range for SIDs and an infrastructure address range for source addresses that can be detected and enforced. SUGGEST In order to apply such a filtering mechanism the SR domain needs to have an address range for SIDs, separate from the infrastructure and customer address ranges, and an infrastructure address range for source addresses, both of which can be detected and enforced. CURRENT Many operators reserve a /64 block for all loopback addresses and allocate /128 for each loopback interface. This simplifies the filtering of permitted source addresses. SUGGEST Many operators reserve a /64 block for all loopback addresses and allocate /128 for each loopback interface. This simplifies the filtering of permitted source addresses. Alternatively, loopback addresses can be allocated from each node's locator [I-D.ietf-srv6ops-srv6addressing], in which case the permitted source addresses are covered by the SID address range. In either case, a hierarchical addressing plan whose locators summarize at domain and area boundaries [I-D.ietf-srv6ops-srv6addressing] keeps the filters to a few stable prefixes. 920 Many operators reserve a /64 block for all loopback addresses and 921 allocate /128 for each loopback interface. This simplifies the 922 filtering of permitted source addresses. <minor> Loopback addresses can alternatively be allocated from each node's locator, and a hierarchical locator plan keeps the source-address filters to a few stable prefixes. Please see my comments on line 896, which include suggested text for this paragraph. <EoRv17> _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
