Hi, On Aug 11, 2023, at 21:40, Rishabh Parekh <risha...@gmail.com> wrote: > On Thu, Aug 10, 2023 at 12:54 AM Lars Eggert <l...@eggert.org> wrote: > Hi, > > On Aug 10, 2023, at 00:24, Rishabh Parekh <risha...@gmail.com> wrote: > > This document introduces packet replication functionality into SR > > networks. This significantly increases and complicates the attack > > surface of the technology while at the same time introducing severe > > new misconfiguration possibilities (e.g., multicast amplification > > loops that can lead to congestion collapse of the network.) This > > document does not adequately describe and discuss these issues. > > > > [RP] May I ask what you think is missing in the Security section text about > > loops? > > A way to detect and/or mitigate the effects of loop congestion. Or if that > cannot be done in this document, a requirement that this technology MUST NOT > be deployed without a control plane that either prevents loops or detects and > mitigates their effects, and a normative reference to those control plane > specs. > > [RP2] I will add a MUST requirement for a control plane to prevent or > detect/mitigate loops in steady state in the next revision.
I'm missing a normative reference to at least one control plane that satisfies this requirement. > Local provisioning of replication segments on SR nodes is valid too - maybe > we can add a SHOULD clause to prevent loops via local provisioning. However, > I don't think a normative reference to the control plane is required because > the behavior of a single replication segment - as specified in this document > does not necessitate a control plane. Safe deployment of this technology requires that loop congestion collapse be prevented. If the only way to achieve this is by requiring a control plane, that must be a normative reference. If there is some other way to prevent loop congestion without a control plane, this document or a normative reference must specify how this is done. > > Additionally, this documents needs to specify suitable > > countermeasures - it is not sufficient to leave this up to > > unspecified control plane mechanisms. > > > > [RP] This document is just specifying behavior of a single replication > > segment. The use of PCE as a controller to create a tree by stitching > > replication segments in specified in PIM WG document > > (draft-ietf-pim-sr-p2mp-policy) and PCEP protocol extensions are described > > in PCE WG doc (draft-ietf-pce-sr-p2mp-policy). > > draft-ietf-pim-sr-p2mp-policy is only cited informally, and > draft-ietf-pce-sr-p2mp-policy not at all. If they do contain these > countermeasures, they need to be cited normatively and their use needs to be > required. However, I just skimmed them and neither seems to discuss loops or > congestion? > > [RP] draft-ietf-pim-sr-p2mp-policy is really an "architecture" draft for > using PCE as a control plane for creating a tree by stichting replication > segments; draft-ietf-pce-sr-p2mp-policy is just PCEP signalling extensions > and hence not really referenced in this draft. Once we add the MUST > requirements in this draft, I will update draft-ietf-pim-sr-p2mp-policy to > satisfy this requirement. If draft-ietf-pim-sr-p2mp-policy is the control plane that contains the loop congestion collapse protection, it must also become a normative reference. > > ### Section 2, paragraph 18 > > ``` > > In principle it is possible for different Replication segments to > > replicate packets to the same Replication segment on a Downstream > > node. However, such usage is intentionally left out of scope of this > > document. > > ``` > > What was the intent of leaving this out? There seems to be complexity > > here that can be abused, in which case I would have expected this to > > either be explicitly forbidden or discussed in sufficient detail to > > understand (and mitigate) the issues. > > > > [RP] This came up in WG discussion during WGLC about "sharing" a downstream > > replication segment across multiple "upstream" replication segments > > (possibly to enable Multipoint-to-Multipoint). Although this is feasible, > > it is only possible to do this when a complex set of conditions are > > satisfied. This adds complexity to both control plane and data plane (like > > needing "outer" and "inner" replication segment context in packets). Hence, > > it was kept out of scope of this document. > > So what you write seems to argue that this should then be explicitly > forbidden? > > [RP2] No, it should not be forbidden, but left to other future documents that > can address the MP2MP use-case or replication segment sharing, if required. Those other documents should then update this one, allowing this option and describing the details. Thanks, Lars
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
