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

[Christoph Loibl <[e-mail]>]

Hi John and Robert,

Thanks for pointing that out. This is a very good point! I think that a missing dest-ip component could be treated as 0/0 in terms of validation.

Making the destination-ip component mandatory may badly break existing implementations (that do not treat destination-ip as mandatory and may break deployments). It may also be problematic for certain extensions that do not need dest-ip addresses (with this draft we did not only try to be more precise in the specification, we also wanted improve extensibility -> relaxed behaviour on un-decodable NLRI).

I think that in this context we can treat a non-existing destination-ip flow-component as 0/0 and I suggest something like this:

OLD:

     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.

NEW:

     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. 0/0 is assumed as destination prefix in 
     this context if it is not embedded in the Flow Specification.  

Extensions may need to revise this validation behaviour for their needs anyway.

The draft itself does not deal with / mention any possible vendor-specific exception mechanisms that allow to circumvent the validation (complete or partly), thus I think there is no additional paragraph needed that tries to explain how such validation can be relaxed. (maybe only very minimal “This validation procedure MAY be relaxed by configuration.”) 

Cheers Christoph

-- 
Christoph Loibl
[e-mail] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at



> On 13.06.2019, at 19:42, John Scudder <jgs=[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
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr