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

[Jeffrey Haas <[e-mail]>]

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