Lars, Inline @ [RP2] Thanks, -Rishabh
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. 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. > > > 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. > > > ### 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. > > Thanks, > Lars > > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
