Warren Kumari has entered the following ballot position for draft-ietf-bess-srv6-services-10: 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/blog/handling-iesg-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-bess-srv6-services/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The Security Considerations section says: "The service flows between PE routers using SRv6 SIDs advertised via BGP are expected to be limited within the trusted SR domain (e.g., within a single AS or between multiple ASes within a single provider network). Precaution should be taken to ensure that the BGP service information (including associated SRv6 SID) advertised via BGP sessions are limited to peers within this trusted SR domain." This is related to (from RFC8402): "Therefore, by default, the explicit routing information MUST NOT be leaked through the boundaries of the administered domain." However, we all know that BGP leaks happen -- and when they do, the SID’s contained in the leak will be logged by various systems and hence available to the public into perpetuity. While the document states that border filtering should protect against traffic injection, this does not cover the case of internal compromise. Sure, there is the argument that once there is an internally compromised system, all bets are off -- but with this, an attacker that knows the SIDs in e.g inject traffic into a VPN. This seems to me to significantly expand the attack surface to include the customer's networks too. Not only does an operator have to ensure that BGP leaks never occur, they have to then ensure that at no point can there be any filter lapses at any border node, and be able to guarantee the security of every device, server and machine within the domain in order for a secure posture to be maintained. Simply saying that precautions should be taken to make sure that route leak don't occur, when the consequences of doing so are a: severe and b: hard to recover from seems to not really cover it. In addition, it seems that the blast radius from a missing ACL seems much larger if it allows injections. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm still reviewing the document, but wanted to get an initial ballot in, so that we could start discussing it. Hopefully someone can help my understand how this doesn't expand the consequences of a BGP leak. _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
