Boris, Thank you for this detailed review. We will incorporate the suggestions into our next version.
On Sat, Aug 10, 2024 at 11:35 AM Boris Hassanov <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]." > 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
