Hi Nick, Thanks for your response and update. Indeed everything has been addressed.
Many thanks, Ketan On Fri, 16 Oct, 2026, 9:55 pm Nick Buraglio, <[email protected]> wrote: > I believe all but the noted comment was addressed in -18 > > On Wed, Oct 14, 2026 at 1:32 PM Ketan Talaulikar via Datatracker < > [email protected]> wrote: > >> 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. >> >> OLD: Many operators reserve a /64 block for all loopback addresses and > allocate /128 for each > NEW: Alternatively, loopback addresses can be allocated from each node's > locator, in which case the permitted source addresses are covered by the > SID address range. A hierarchical addressing plan whose locators summarize > at domain and area boundaries 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]
