All, We submitted a new version that addresses the copy editing issues as well as a number of the initial comments. This is initial pass through the list with clean up intended to make the adopted version cleaner and easier to read. We will propose other adjustments to comments received and make another pass through the document addressing those prior to submitting -01. Please take a look at the -00 and continue to provide input if you have it.
Below is a list of what was addressed with this version: -[x] 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]." -[x] 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])." -[x] 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. " -[x] "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? -[x] 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. -[x] 6) Items 12 and 13 (Security Considerations and IANA Considerations) repeat the same items 9 and 10 # Nits - - [x] Expand SRv6 in the title and abstract - - [x] Add reference for Segment Routing Header (SRH) as [RFC8754] - - [x] s/reliance of a new header/reliance on a new header/ - - [x] s/applied baed on/applied based on/ - - [x] s/using LUA addresses/using ULA addresses/ - - [x] s/from the last entry in the ./from the last entry in the SRH./ (?) - - [x] s/keeeping/keeping/ - - [x] s/do not posses/do not possess/ - - [x] s/PE device a as source address/PE device as source address/ - - [x] Please run the text through a grammar check, many issues that I did not list! On Thu, Aug 22, 2024 at 6:42 AM <internet-dra...@ietf.org> wrote: > Internet-Draft draft-ietf-spring-srv6-security-00.txt is now available. It > is > a work item of the Source Packet Routing in Networking (SPRING) WG of the > IETF. > > Title: Segment Routing IPv6 Security Considerations > Authors: Nick Buraglio > Tal Mizrahi > Tian Tong > Luis M. Contreras > Fernando Gont > Name: draft-ietf-spring-srv6-security-00.txt > Pages: 21 > Dates: 2024-08-21 > > Abstract: > > SRv6 is a traffic engineering, encapsulation and steering mechanism > utilizing IPv6 addresses to identify segments in a pre-defined > policy. 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. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-security/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-spring-srv6-security-00.html > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > _______________________________________________ > 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
