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

[Rishabh Parekh <[e-mail]>]

Lars,
Inline @ [RP2]

Thanks,
-Rishabh

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. 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
>
>
>