Hi all, I have looked up Section 7.1.1 of the draft<https://datatracker.ietf.org/doc/html/draft-bdmgct-spring-srv6-security-02#section-7.1.1>, and it looks problematic to me:
* The first para of this section starts with “SRv6 packets rely on the routing header in order to steer traffic”. (This statement is effectively repeated in Section 8.1) * The second para explains that, with the use of compression, SRv6 can be used without SRH. My guess (FWIW) is that this may be the one of the most relevant use cases with SRv6. I wonder if . security mechanisms that rely on presence of SRH .t really important?7 My 2c, Sasha From: Nick Buraglio <burag...@forwardingplane.net> Sent: Wednesday, August 21, 2024 10:53 PM To: Boris Hassanov <bhassa...@yahoo.com> Cc: SPRING WG <spring@ietf.org>; Alvaro Retana <aretana.i...@gmail.com>; draft-bdmgct-spring-srv6-secur...@ietf.org; spring-cha...@ietf.org Subject: [EXTERNAL] [spring] Re: WG Adoption Call for draft-bdmgct-spring-srv6-security (ends Aug/19) On Sat, Aug 10, 2024 at 11:35 AM Boris Hassanov <bhassa...@yahoo.com<mailto:bhassa...@yahoo.com>> wrote: 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]." How does this sound: "SRv6 may use the SRH which is a type of Routing Extension Header defined by [RFC8754]." 1.2) "SRv6 consists of using the SRH on the IPv6 dataplane..." -> "SRv6 uses the IPv6 dataplane..." +1 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])." +1 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. " +1 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. Will work with the group on this. 4) 6.Attacks I would add the comparison table at the end of this chapter (Attack type - Overview--- Scope--Impact) Will work with the group on this. 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". +1 "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]. " Is there a desire to remove the citation for RFC7872? Will the authors propose any kind of solution here besides the problem statement? I don't believe we will provide any solutions. 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. What are the group's thoughts on generalizing this to be more about the challenges which IPv6 extension headers introduce to middle boxes, and note that there this extends into the use of SRv6 in that context? 6) Items 12 and 13 (Security Considerations and IANA Considerations) repeat the same items 9 and 10 Fixed 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. Will discuss with the group. SY, Boris On Monday, August 5, 2024 at 04:04:44 PM GMT+3, Alvaro Retana <aretana.i...@gmail.com<mailto: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/<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<mailto:spring@ietf.org> To unsubscribe send an email to spring-le...@ietf.org<mailto:spring-le...@ietf.org> Disclaimer This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
