Mohamed Boucadair has entered the following ballot position for draft-ietf-spring-srv6-security-17: 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: ---------------------------------------------------------------------- Hi Nick, Tal, Tian , Luis, and Fernando, Thank you for the effort put into this document. Thanks also to Jean-Michel Combes for the OSPDIR review and the authors for engaging. Several of the attacks in the document are also applicable to non-SR as an attacker that act from within a network can do a lot of damage, for example, this one: - Causing packets to be discarded: an attacker may cause a packet to be forwarded to a point in the network where it can no longer be forwarded, causing the packet to be discarded. ..but that is OK. Please find below some few comments: # For authors convenience, I sent a PR with some suggestions: https://github.com/buraglio/draft-bdmgct-spring-srv6-security/pull/79. # Steering is a TE function CURRENT: SRv6 is a traffic engineering, encapsulation and steering mechanism utilizing TE/steering is redundant. Please refer to TE components in RFC9522. # The text can be simplified and avoid repetition. For example, the following can be simply deleted: CURRENT: SRv6 is fundamentally bound to the IPv6 protocol and introduces the aforementioned new extension header. Or * SRv6 may use the SRH which is a type of Routing Extension Header defined by [RFC8754]. # Clarification CURRENT: * While SRv6 uses what appear to be typical IPv6 addresses, the address space is processed differently by segment endpoints. A typical IPv6 unicast address is comprised of a network prefix and a host identifier. and other SID list mention; Check if e a reminder of the clarifications in draft-ietf-6man-sidlist-clarification is useful here. # Not sure how this is used in the document CURRENT: The following IETF RFCs were selected for security assessment as part of this effort: * [RFC8402] : Segment Routing Architecture * [RFC8754] : IPv6 Segment Routing Header (SRH) * [RFC8986] : Segment Routing over IPv6 (SRv6) Network Programming * [RFC9020] : YANG Data Model for Segment Routing * [RFC9256] : Segment Routing Policy Architecture * [RFC9491] : Integration of the Network Service Header (NSH) and Segment Routing for Service Function Chaining (SFC) * [RFC9524] : Segment Routing Replication for Multipoint Service Delivery * [RFC9800] : Compressed SRv6 Segment List Encoding For example, how the SFC/NSH was used in the analysis? # Source routing in general CURRENT: This may allow an attacker to perform a number of attacks on the victim networks and hosts that would be mostly unfeasible for a non-SRv6 environment. I don’t think this is accurate as this would apply for any source routing approach. # Billing bypass CURRENT: example in order to avoid the billing service or circumvent access controls and security filters. I don’t this one # Idem for this one: CURRENT: This can result in allowing various unauthorized services such as traffic acceleration. # Use RFC9907#section 3.7.1 boilerplate instead CURRENT: Management protocols such as NETCONF [RFC6241] and RESTCONF [RFC8040] are commonly used to configure and monitor SRv6-enabled devices. These protocols must be secured to prevent unauthorized access, configuration tampering, or information leakage. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to- implement secure transport is TLS [RFC9846]. Cheers, Med _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
