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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I've been back and forth on this having read the document several times - and I have to join Warren in an abstention here - for very similar reasons. While I view the security issues in this document as stemming from a former document (RFC8402) - the way I see it, we're building on quicksand here. Yes, RFC8402 says that SRv6 must run in a trusted domain - however, the practical methods of enforcing the trusted domain seem woefully lacking, and then, in addition to that when dealing with replication we then compound the issues created by potential packet injection. I simply cannot see how I can no-object to this, however, I also fully understand the criteria for discuss ballots, and since these issues stem from RFC8402 I do not feel that I'm on solid ground balloting discuss. As such, I must abstain. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
