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

From: John Scudder <[email-masked]>
Date: Thu, 13 Jun 2019 17:42:46 +0000

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 13 Jun 2019 20:26:28 +0200

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 <[email-masked]> 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:
> 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 --
>

---

From: Christoph Loibl <[email-masked]>
Date: Thu, 13 Jun 2019 21:22:15 +0200

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:

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
[email-masked] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at

> On 13.06.2019, at 19:42, John Scudder <jgs=[email-masked]> wrote:
> 
> Hi Authors and WG,
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 13 Jun 2019 16:48:30 -0400

Robert (and 5575bis authors),

>    subcomponents (except Type 1 which is mandatory).

While I agree that DDoS mitigation is the core use case for flowspec in its
current form, your suggested change will likely have negative impacts on
implementations.  Destination-less filters exist and get deployed, and the
text you're suggesting makes them not-only non-compliant but arguably
mal-formed.

I think where we have some room for discussion is where we draw the line for
validation in the default case vs. the clarification:

https://tools.ietf.org/html/draft-ietf-idr-bgp-flowspec-oid-08

I believe the reason the discussion is needed in a 5575-bis context is that
we have an obvious hole in the core spec as to what we should do for what is
intended to be a compliant case.

Whether the text we converge on obviates the need for the -oid draft is an
open question.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 13 Jun 2019 16:53:10 -0400

Christoph,

>      this context if it is not embedded in the Flow Specification.  

I think this has the likelihood to cause some undesirable implementation
behaviors.

If the dest-prefix filter is presumed to be 0/0, the only route that can
contain it is 0/0.  We're thus implicitly suggesting that if you want
flowspec validation to work, originate default.

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

See also https://tools.ietf.org/html/draft-ietf-idr-bgp-flowspec-oid-08

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

Thus why John's text is probably the level of desired flexibility.  Copied
from below:

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

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 13 Jun 2019 23:06:39 +0200

Jeff,

Let me explain the full picture - was just staying focused on John's mail.

When I suggested that destination type should be mandatory I did mean the
base use case of DDoS mitigation.

For other use cases validation will be disabled anyway in all cases hence
we do not have an issue to start with. Nowhere I stated that validation
must be mandatory.

Now that fact that some use cases of flow spec go beyond DDoS mitigation
today my understanding is that future documents will describe it well as
they already go beyond base spec. I would actually recommend to use
different SAFI for those additional use cases clearly separating both - if
for nothing else then for concurrent ability to validate filters for DDoS
while filling much more free to use same mechanism for intradomain use
cases.

And to the point of treating missing destination as 0/0 I think it is not a
good idea. It may break even more things especially in other then DFZ
environments.

Thx a lot,
R.

---

From: Christoph Loibl <[email-masked]>
Date: Thu, 13 Jun 2019 23:54:22 +0200

Hi,

> On 13.06.2019, at 22:53, Jeffrey Haas <[email-masked]> wrote:

I have no lab at hand (now) - but I am really curios how ie. Juniper (also other vendors) actually validate FS without a destination-prefix component (to be honest, I never tried this - but it is supposed to be easily verified).

> flowspec validation to work, originate default.

Originate default + have no other more-specifics punching holes into that 0/0 - this is arguable very unlikely :-) - still I am not convinced if the behaviour is so much different to what John suggested. I have no objections to John’s solution either.

> See also https://tools.ietf.org/html/draft-ietf-idr-bgp-flowspec-oid-08

Yes. Saw that.

> Thus why John's text is probably the level of desired flexibility.  Copied

Reading John’s suggestion twice this seems to give more flexibility to extensions while keeping the core behaviour close to what is out there (still there may be changes in behaviour given we do not know what is out there). 

Cheers Christoph

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 14 Jun 2019 11:47:43 -0400

On Thu, Jun 13, 2019 at 11:54:22PM +0200, Christoph Loibl wrote:
> I have no lab at hand (now) - but I am really curios how ie. Juniper (also
> other vendors) actually validate FS without a destination-prefix component
> (to be honest, I never tried this - but it is supposed to be easily
> verified).

I will somewhat coyly note that John's text does not come out of pure
protocol pedantry. :-)

Juniper's implementation doesn't do useful things when the dest-prefix is
absence and validation is on.  This was noted during some internal testing.
When we were approached for "what should we do, it's not in the spec", the
proposed text arose out of internal discussion. (Including "well, it's
effectively 0/0.)

The pedantic behavior would be to say "it's 0/0", but it leads to the
"originate default" as an answer.  This is not behavior we'd operationally
encourage and thus we are having this discussion.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 14 Jun 2019 17:49:31 +0200

> Juniper's implementation doesn't do useful things when the dest-prefix is
absence and validation is on.

I would classify this as deployment misconfiguration.

If you are using flow spec for other then DDoS use cases you should disable
validation.

Thx,
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 14 Jun 2019 11:54:51 -0400

Robert,

> If you are using flow spec for other then DDoS use cases you should disable

DDoS is mentioned as only one of the applications in the draft.  (See
Abstract, etc.)

The validation procedures don't have an "opt-out".

-oid does have such an opt-out.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 14 Jun 2019 18:01:18 +0200

> DDoS is mentioned as only one of the applications in the draft.  (See

Yes and second one is traffic filtering for L3VPNs. No more.

So both use cases rather use destination prefix (even if such prefix would
be just an RD part of the NLRI in the latter case).

But we all know that validation has been implemented by number of vendors
to be optional in flow spec - hence the former comment - for those use
cases which go beyond the two listed in base RFC5575 spec.

Thx,
R.

---

From: Christoph Loibl <[email-masked]>
Date: Tue, 18 Jun 2019 11:13:17 +0200

Hi IDR,

After some discussion on the list and also off-list I uploaded a new version of the draft (-17) that seems to have enough support from the WG (basically what John suggested initially). If there are very strong arguments against this change, please suggest a different fix to the problem John pointed out. John wanted to keep the discussion open until 28th June.

Cheers Christoph
  
OLD:

NEW: 

   A Flow Specification NLRI must be validated such that it is
   considered feasible if and only if all of the below is true:

      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 rule b).

---

From: John Scudder <[email-masked]>
Date: Mon, 24 Jun 2019 21:30:11 +0000

Hi All,

Just to reiterate, the -17 text Christoph uploaded will be what goes forward to the IESG unless there are any objections by Friday. The diff vs. version -16 is here, https://tools.ietf.org/rfcdiff?url2=draft-ietf-idr-rfc5575bis-17.txt

On Jun 18, 2019, at 2:13 AM, Christoph Loibl <[email-masked]<mailto:[email-masked]>> wrote:

Thanks to Christoph and the other authors for jumping on this.

—John