Re: [spring] Lars Eggert's Discuss on draft-ietf-spring-sr-replication-segment-16: (with DISCUSS and COMMENT)

[Lars Eggert <[e-mail]>]

Hi,

On Aug 11, 2023, at 21:40, Rishabh Parekh <[e-mail]> wrote:
> On Thu, Aug 10, 2023 at 12:54 AM Lars Eggert <[e-mail]> wrote:
> Hi,
> 
> On Aug 10, 2023, at 00:24, Rishabh Parekh <[e-mail]> 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