Subject: [Idr] draft-ietf-idr-rfc5575bis - duplicate types, improper lengths?

From: Jeffrey Haas <[email-masked]>
Date: Thu, 3 May 2018 10:16:38 -0400

IDR,

I'm having trouble getting a good search on the IETF site for these matters,
so please forgive me if this should have been answered in the archives.

Flowspec specifies a series of subcomponents for filtering.

I don't recall seeing any advice regarding dealing with duplicates.  At
best, the following is present:

:   All combinations of component types within a single NLRI are allowed,
:   even if the combination makes no sense from a semantical perspective.

A somewhat more minor point, some components use a common header with a
defined length.  Using Type 3 (IP Protocol) as an example:

:      len - length of the value field for this operand encodes 1 (00) -
:      4 (11) bytes.  Type 3 flow component values are always encoded as
:      single byte (len = 00).

The question being the semantic validity when the length is incorrect.
There are two cases here:
1. The value is still within the correct range.  E.g. 1-4 byte
   representations of the protocol nummber as long as the value is <= 255.
2. The value exceeds the correct range.  Syntactically correct, semantically
   incorrect.  Ignore filter, or treat as NLRI formatting issue with
   resultant treat-as-withdraw or session bounce depending on error-handling?

A final comment on future extensions:
The flowspec feature relies on implicit lengths in the sub-types.  A
negative consequence of this is that implementations that do not understand
a future sub-type cannot validate the correctness of the NLRI.  However, it
should still be propagated:

:   receiver.  Since a Flow Specification has the semantics of a logical
:   AND of all components, if a component is FALSE, by definition it
:   cannot be applied.  However, for the purposes of BGP route
:   propagation, this prefix should still be transmitted since BGP route
:   distribution is independent on NLRI semantics.

This means that failures will be detected potentially "far away".

-- Jeff

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 3 May 2018 11:35:29 -0400

> On May 3, 2018, at 10:16 AM, Jeffrey Haas <[email-masked]> wrote:
> 

That’s alarming, if "session bounce depending on error-handling”.

Session bounce “far away” was the AS4_PATH problem that induced the revised error-handling in RFC7606.

It would be a shame to design a feature (to have designed a feature?) that did not take advantage of the lessons learned and RFC7606.

—Sandy

---

From: Christoph Loibl <[email-masked]>
Date: Thu, 3 May 2018 21:47:30 +0200

Hi Jeff,

Thanks for asking those questions. See my comments (unfortunately some of them quite long) inline.

Christoph

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

> On 03.05.2018, at 16:16, Jeffrey Haas <[email-masked]> wrote:
> 
> IDR,
> 

Actually this is what you are looking for… No duplicates are possible/allowed following the rule below:

   Flow Specification components must follow strict type ordering by
   increasing numerical order.  A given component type may or may not be
   present in the specification, but if present, it MUST precede any
   component of higher numeric type value.

However, I totally agree with you that this is not very intuitive. In case of duplicate component types (types with equal numeric value) one of the duplicate components do NOT precede a component of higher numeric type value.

I would suggest to make this small change:

   Flow Specification components must follow strict type ordering by
   increasing numerical order.  A given component type may (exactly once) or may not be
   present in the specification, but if present, it MUST precede any
   component of higher numeric type value.

> There are two cases here:

In this case the idea was, that the length of a type-3 component MUST always be 1 (len=00). If this is not the case the NLRI encoding is syntactically incorrect.

>   representations of the protocol nummber as long as the value is <= 255.

Incorrect if len!=00 because type-3 flow components require len=00.

>   resultant treat-as-withdraw or session bounce depending on error-handling?

Since the allowed len field is defined for all the component-types this situation is not possible. IF the len field is correct to specification, there is no need to verify the range of the value, since it is within the correct range (if I did not miss anything here).

> should still be propagated:

This is true, but I think it is not the purpose of this draft to change this. RFC5575bis draft is meant to be compatible with what is out there, but at the same time to be more precise and increase interoperability, while not breaking too much (since most of the bigger vendors, after our interop initiative, already aligned their implementation with what we later published as this draft).

> :   distribution is independent on NLRI semantics.

I need to read this again. But the idea is that the implementation should only propagate syntactically correct NLRIs. Updates that are malformed are subject to error handling (notification, treat as withdraw). But we wanted to decouple the syntax from the semantics.

The reason for this decoupling is something that we observed frequently when we looked into flowspec implementations. Some implementations only propagated flowspec filters when they where actually able to program that particular filter into the data-plane. For IP-routing this perfectly makes sense: When you are not able to forward a specific packet to its destination it is a good idea not to propagate that particular route. With flowspec this is a different story. If you cannot apply a flowspec-filter in your data-plane I think there are still good reasons why the NLRI should still be propagated.

The reason why filters could not be applied were not always because of the NLRI not matching any packet. But often because the hardware did not support specific filters (ie. because of complexity) but also because the hardware did not support specific actions (since actions are encoded into the extended-communities, those may also get rewritten when propagated in the network, they may still be meaningful at some other place in the net).

> This means that failures will be detected potentially "far away”.

Yes and no. Semantical nonsense may be propagated but has no real operational impact (ie not matching packets, never resulting in any data-plane filters). But syntactical incorrect NLRIs (not decode-able) are not propagated at all (I will read this part again, I thought that it is clear that a NLRI that is syntactical incorrect cannot be propagated).

Christoph

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 3 May 2018 16:30:00 -0400

Christoph,

> On May 3, 2018, at 3:47 PM, Christoph Loibl <[email-masked]> wrote:
> 

>    component of higher numeric type value. 

... putting this in the -bis.  

I realize this is late in the publication game.

> Since the allowed len field is defined for all the component-types this situation is not possible. IF the len field is correct to specification, there is no need to verify the range of the value, s…

This is certainly a valid interpretation of the spec.  It does, however, violate Postel's law.

The issue of course is that if your implementation accepts a looser size type and it's within the proper semantic range, a downstream receiving exactly the same size may not accept it.  One's implementation might arguably accept the mis-sized values and reformat them on send.

> This is true, but I think it is not the purpose of this draft to change this.

No argument on this point.  But the realization also has the implication mentioned afterward.

> I need to read this again. But the idea is that the implementation should only propagate syntactically correct NLRIs. Updates that are malformed are subject to error handling (notification, treat a…

Based on the rules, you can't tell if it's syntactically correct if you receive a subcomponent that you do not recognize.

(This hits a common gripe of mine in protocols regarding implicit lengths.)

> The reason for this decoupling is something that we observed frequently when we looked into flowspec implementations. Some implementations only propagated flowspec filters when they where actually…

I agree.  And this tends to follow the principle within networks that it's okay for things like route reflectors to be dumb about some details since they're not in the forwarding path.

> Yes and no. Semantical nonsense may be propagated but has no real operational impact (ie not matching packets, never resulting in any data-plane filters). But syntactical incorrect NLRIs (not decod…

I suspect you'll find you are mistaken in this detail.  If you propagate things you don't understand (new component), it might be malformed.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 3 May 2018 22:44:48 +0200

> If you propagate things you don't understand (new component), it might
be malformed.

It depends how you treat new SAFI. If it is opaque to BGP (example: BGP-LS)
it shouldn't really matter if you fully understand content of all
attributes carried with given NLRI.

Likewise for flowspec you may observe that BGP carries flow NLRIs + takes
care of validation but what is described in match and actions are opaque to
BGP and only relevant to your data plane (ACL) components.

Thx.
/Robert.

On Thu, May 3, 2018 at 10:30 PM, Jeffrey Haas <[email-masked]> wrote:

> Actually this is what you are looking for… No duplicates are
> possible/allowed following the rule below:
>
> However, I totally agree with you that this is not very intuitive. In case
> of duplicate component types (types with equal numeric value) one of the
> duplicate components do NOT precede a component of higher numeric type
> value.
>
>
> In the scheme of BGP document pedantry... I can agree that this is a valid
> way of saying "no duplicates".  But this might be worth:
>
>
> In this case the idea was, that the length of a type-3 component MUST
> always be 1 (len=00). If this is not the case the NLRI encoding is
> syntactically incorrect.
>
> Since the allowed len field is defined for all the component-types this
> situation is not possible. IF the len field is correct to specification,
> there is no need to verify the range of the value, since it is within the
> correct range (if I did not miss anything here).
>
>
> The issue of course is that if your implementation accepts a looser size
> type and it's within the proper semantic range, a downstream receiving
> exactly the same size may not accept it.  One's implementation might
> arguably accept the mis-sized values and reformat them on send.
>
>
>
> I need to read this again. But the idea is that the implementation should
> only propagate syntactically correct NLRIs. Updates that are malformed are
> subject to error handling (notification, treat as withdraw). But we wanted
> to decouple the syntax from the semantics.
>
>
> Based on the rules, you can't tell if it's syntactically correct if you
> receive a subcomponent that you do not recognize.
>
> The reason for this decoupling is something that we observed frequently
> when we looked into flowspec implementations. Some implementations only
> propagated flowspec filters when they where actually able to program that
> particular filter into the data-plane. For IP-routing this perfectly makes
> sense: When you are not able to forward a specific packet to its
> destination it is a good idea not to propagate that particular route. With
> flowspec this is a different story. If you cannot apply a flowspec-filter
> in your data-plane I think there are still good reasons why the NLRI should
> still be propagated.
>
>
> I agree.  And this tends to follow the principle within networks that it's
> okay for things like route reflectors to be dumb about some details since
> they're not in the forwarding path.
>
>
> Yes and no. Semantical nonsense may be propagated but has no real
> operational impact (ie not matching packets, never resulting in any
> data-plane filters). But syntactical incorrect NLRIs (not decode-able) are
> not propagated at all (I will read this part again, I thought that it is
> clear that a NLRI that is syntactical incorrect cannot be propagated).
>
>
> I suspect you'll find you are mistaken in this detail.  If you propagate
> things you don't understand (new component), it might be malformed.
>
> -- Jeff
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 3 May 2018 17:18:24 -0400

> On May 3, 2018, at 4:44 PM, Robert Raszuk <[email-masked]> wrote:
> 
> > If you propagate things you don't understand (new component), it might be malformed. 
> 
> It depends how you treat new SAFI. If it is opaque to BGP (example: BGP-LS) it shouldn't really matter if you fully understand content of all attributes carried with given NLRI. 
> 
> Likewise for flowspec you may observe that BGP carries flow NLRIs + takes care of validation but what is described in match and actions are opaque to BGP and only relevant to your data plane (ACL) components. 

Let me make sure I have this crystal clear correct, Robert:

You're advocating "don't syntactically validate flowspec NLRI"?

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 3 May 2018 23:26:39 +0200

> You're advocating "don't syntactically validate flowspec NLRI"

Depends what you call as NLRI :)

For me NLRI is a field in MP_REACH  so sure you should validate MP_REACH
and other mandatory BGP attributes before propagating them. However for
optional attributes as long as their total length is fine I don't think
there is any mandate to syntactically validate any fields *embedded* within
them before BGP propagation. They should be rather opaque to BGP.

Otherwise the entire idea of optional transitive would be rather
questionable don't you think ?

Thx,
R.

On Thu, May 3, 2018 at 11:18 PM, Jeffrey Haas <[email-masked]> wrote:

> It depends how you treat new SAFI. If it is opaque to BGP (example:
> BGP-LS) it shouldn't really matter if you fully understand content of all