Hi Alvaro and all, Yes, I support the publishing of this document.
Few comments after the review: 1) 1.Introduction 1.1) "SRv6 makes use of the SRH which is a new type of Routing Extension Header." -> IMO, would be better to write: "SRv6 may use the SRH which is a new type of Routing Extension Header [RFC8754]." 1.2) "SRv6 consists of using the SRH on the IPv6 dataplane..." -> "SRv6 uses the IPv6 dataplane..." 1.3) "A typical SRv6 segment identifier (SID) is broken into a locator, a function identifier, and optionally, function arguments." -> "A typical SRv6 segment identifier (SID) consists of a locator, a function identifier, and optionally, function arguments (LOC:FUNCT:ARG [RFC8986])." 2) 4.Threat model 2.1) "Internal vs. External:...In this context, the latter means that the attacker can be reached from a node in the SR domain without traversing an SR egress node, and can reach a node in the SR domain without traversing an SR ingress node." IMO, this sentence brings a confusion here and not needed, since the previous sentence: "Specifically, an internal attacker either has access to a node in the SR domain, or is located on an internal path between two nodes in the SR domain. " is a self-explanatory. Also you give comparison On-path vs. Off-path in the next paragraph. So I would re-write that paragraph in this way: " Internal vs. External: An internal attacker in the context of SRv6 is an attacker who is located within an SR domain. Specifically, an internal attacker either has access to a node in the SR domain, or is located on an internal path between two nodes in the SR domain. External attackers, on the other hand, are not within the SR domain. " 3) 5. Impact 3.1) "Unauthorized Access: an attack that results in unauthorized access might be achieved by having an attacker leverage SRv6 to circumvent security controls as a result of security devices being unable to enforce security policies in the presence of IPv6 Extension Headers (see [RFC9098]," -> This part of sentence is quite complex and confusing, I cannot get the logic: SRv6 is just a transport mechanism in this context, if it was somehow leveraged to circumvent security control on the router - how is this related with some security devices and their inability to enforce security policies? RFC9098 mainly says about DoS attacks with leveraging IPv6 EH. Probably it would be better to re-write. 4) 6.Attacks I would add the comparison table at the end of this chapter (Attack type - Overview--- Scope--Impact) 5) 8.2. Middlebox Filtering Issues "And it is able to retrieve the final destination of SRv6 packet from the last entry in the ." -> Probably the SRH is missed: "And it is able to retrieve the final destination of SRv6 packet from the last entry in the SRH". "Additionally, implementation limitations in the processing of IPv6 packets with extension headers may result in SRv6 packets being dropped RFC7872 [RFC9098]." -> " Additionally, implementation limitations in the processing of IPv6 packets with extension headers may result in SRv6 packets being dropped [RFC9098]. " Will the authors propose any kind of solution here besides the problem statement? There is also the term: SRv6 aware firewall, 7.5 of RFC9098 says about multiple challenges which IPv6 extension headers bring to a FW. So I think more research work is needed to define the requirements for SRv6 aware firewall. 6) Items 12 and 13 (Security Considerations and IANA Considerations) repeat the same items 9 and 10 7) I think it would be very helpful if we add the table about known supported mitigation methods for vendor and open source SRv6 implementations such as HMAC TLV, IPv6 extension headers filtering etc. SY, Boris On Monday, August 5, 2024 at 04:04:44 PM GMT+3, Alvaro Retana <aretana.i...@gmail.com> wrote: Dear WG: This message starts a two-week adoption call for ddraft-bdmgct-spring-srv6-security, ending on August/19. From the Abstract: This document discusses security considerations in SRv6 networks, including the potential threats and the possible mitigation methods. The document does not define any new security protocols or extensions to existing protocols. https://datatracker.ietf.org/doc/draft-bdmgct-spring-srv6-security/ Please review the draft and consider whether you support its adoption by the WG. Please share any thoughts with the list to indicate support or opposition -- this is not a vote. If you are willing to provide a more in-depth review, please state it explicitly to give the chairs an indication of the energy level in the working group willing to work on the document. WG adoption is the start of the process. The fundamental question is whether you agree the proposal is worth the WG's time to work on and whether this draft represents a good starting point. The chairs are particularly interested in hearing the opinions of people who are not authors of the document. Note that the IESG requested that the WG deliver a document covering security considerations for SRv6. This document is intended to satisfy that request. Thanks! Alvaro (for the Chairs) _______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org _______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
