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]." > 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> 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
