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]
