Andrew, We have added text addressing your DISCUSS concern in revision 17 of the document.
Please take a look, -Rishabh On Tue, Aug 8, 2023 at 3:19 PM Rishabh Parekh <risha...@gmail.com> wrote: > Andrew, > > On Fri, Aug 4, 2023 at 4:25 AM Andrew Alston via Datatracker < > nore...@ietf.org> wrote: > >> Andrew Alston has entered the following ballot position for >> draft-ietf-spring-sr-replication-segment-16: Discuss >> >> 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-sr-replication-segment/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Firstly, thanks for the security section updates - that moves me from an >> abstain to a discuss. >> >> I would like to this discuss text: >> >> "Given the definition of the Replication segment in this document, an >> attacker >> subverting ingress filter above cannot take advantage of a stack of >> replication >> segments to perform amplification attacks nor link exhaustion attacks. >> Replication segment trees always terminate at a Leaf or Bud node >> resulting in a >> decapsulation." >> >> Here is issue with this - what happens post decapsulation. I.E - if I >> were to >> take an IPv4 packet - encapsulate it in a replication SID - with a source >> host >> I wished to attack, and a destination address of an attached broadcast - >> would >> the IPv4 packet be processed post de-cap. >> >> If the packets post de-cap do indeed get forwarded, the attack vector is >> still >> entirely real. The SRv6 is used to tunnel packets pass things like IP >> directed >> broadcast protections, unicast reverse path filtering etc, and the de-cap >> ensures they get acted on. >> >> If I've missed something here or am off in my analysis - apologies - but >> if not >> - the above text needs to be rectified so that this attack vector is made >> clear. >> >> >> Yes, this is certainly possible, but the same vulnerability applies to > other SRv6 behaviors that perform decapsulation or even to MPLS > encapsulated payloads. I will add text about this in the next revision. > > Thanks, > -Rishabh >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
