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

[Rishabh Parekh <[e-mail]>]

Lars,
Revision 17 addresses your concerns about loop prevention and other
comments.

Please take a look,
-Rishabh

On Fri, Aug 11, 2023 at 11:40 AM Rishabh Parekh <[e-mail]> wrote:

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