Re: [Idr] Returning draft-ietf-idr-rfc5575bis to WG, new 2 week discussion period

[Robert Raszuk <[e-mail]>]

Hi John,

RFC5575 has been written as DDoS mitigation tool and 5575bis attempts to
clarify various ambiguities of the base spec.

We as the WG have decided that numerous 5575 extensions (for example those
injected by controllers or NMS) will be specified in different documents
and not be embedded into base Flow Specification one.

With that if we agree that DDoS mitigation is still our target for the base
spec I would tent to suggest that destination field to be made mandatory
for real DDoS mitigation use case. Relaxing that could be done for other
Flow Spec use cases in their separate documents, but outside of the base
spec.

So the only change which may be needed would be add:

4.2.  NLRI Value Encoding

   The Flow Specification NLRI-type consists of several optional
   subcomponents (except Type 1 which is mandatory).

Thx,
R.







On Thu, Jun 13, 2019 at 7:42 PM John Scudder <[e-mail]> wrote:

> Hi Authors and WG,
>
> I just had it brought to my attention that RFC 5575 and
> draft-ietf-idr-rfc5575bis both are underspecified with regard to the
> validation procedures. The problem is what to do if a flow-spec NLRI
> doesn't contain a destination prefix component. Section 4.2 makes it clear
> that destination prefix is optional, so it's valid for it not to be
> present. But the first set of validation steps in section 6 are written in
> terms of the destination prefix, without acknowledging it might not be
> there.
>
> This leaves a gap for an interoperability problem, where some
> implementations might choose to consider validation to have succeeded if
> the destination prefix component isn't present, and others might consider
> it to have failed.
>
> To fix this ambiguity I'd like to suggest the following change. The
> summary is we add a new rule (a), renumber the old (a) and (b), and add a
> note following.
>
> OLD:
>    A Flow Specification NLRI must be validated such that it is
>    considered feasible if and only if:
>
>       a) The originator of the Flow Specification matches the originator
>       of the best-match unicast route for the destination prefix
>       embedded in the Flow Specification.
>
>       b) There are no more specific unicast routes, when compared with
>       the flow destination prefix, that has been received from a
>       different neighboring AS than the best-match unicast route, which
>       has been determined in step a).
>
> NEW:
>    A Flow Specification NLRI must be validated such that it is
>    considered feasible if and only if:
>
>       a) A destination prefix component is embedded in the Flow
>       Specification.
>
>       b) The originator of the Flow Specification matches the originator
>       of the best-match unicast route for the destination prefix
>       embedded in the Flow Specification.
>
>       c) There are no more specific unicast routes, when compared with
>       the flow destination prefix, that has been received from a
>       different neighboring AS than the best-match unicast route, which
>       has been determined in step b).
>
>    Rule a) MAY be relaxed by configuration, permitting Flow
>    Specifications that include no destination prefix component. If such
>    is the case, rules b) and c) are moot and MUST be disregarded.
>
> We need the MAY clause since 4.2 does say destination prefix is optional,
> and also because an operator might actually want to permit this under some
> circumstances, particularly if the route is internally sourced. I'll also
> point out that another way according to the proposed rule set to have a
> flow-spec that matches every packet is to actually put /0 in the
> destination prefix, then you don't need the optional configuration
> mentioned in the MAY clause (you do need to accept default for validation
> to succeed, but that's inherent in flow-spec's design).
>
> The draft has already passed WGLC and been sent to the IESG. But given
> that it's always easier to correct problems sooner rather than later, I've
> just pulled it back to the WG. I'm hoping we can have quick consensus on
> what to do --
>
> - Adopt the fix I've suggested,
> - Adopt a different fix,
> - Determine that no fix is needed.
>
> We could also let the IESG resolve this but it doesn't seem like good WG
> hygiene.
>
> I'd like to keep the discussion tightly scoped to just the minimum
> necessary to clarify section 6.
>
> Let's have the traditional two week window for discussion, to end by June
> 28.
>
> Thanks,
>
> --John