Minutes interim-2021-idr-01: Mon 10:00
minutes-interim-2021-idr-01-202106071000-00

IETF IDR Interim - Flowspec v2
June 7, 2021
Agenda
The current state of things:
•Motivations for Flowspec v2
•Incremental deployment of new Flowspec features
•Interactions with Flowspec v1

Discussion:
•How do we deal with the incremental deployment issues?
•Once we understand incremental deployment, what do we do about the protocol?

Motivations for a Flowspec v2
Original proposal draft-hares-idr-flowspec-v2-00
• Flowspec v1 routes were not safely “opaque”
• RFC 8955 removed this wording
• Move to a full TLV format
(PCEP did this when they borrowed Flowspec encodings)
• Introduces a new error modality: Well-formed, but invalid

Several Flowspec use cases popular at the time required explicit ordering of
rules. • Default sorting rules does well for DDoS • Default sorting rules
problematic for some firewall optimizers

Motivations for a Flowspec v2 (2)
Flowspec actions becoming more sophisticated with deeper interactions.
• Draft for v2 hand-waves “throw it into a Wide Community”.
• Stronger need for a way to remove ambiguity of behaviors when there’s
different rules.
• Flowspec interfaceset feature provides an example of sometimes match
criteria end up outside NLRI
• Conflicting types of redirection actions, for example.

Motivations for a Flowspec v2 (3)
Encoding challenges for first two points potentially addressable in Flowspec v1
• draft-haas-flowspec-capability-bits covers case for whether a given Flowspec
speaker is capable of decoding a feature (component)
• draft-haas-flowspec-term-order permits rule ordering in a simple way using
existing encodings

Do we possibly want to get rid of customer-injected eBGP Flow as a
use case to remove route validation complexity?

Incremental deployment of new Flowspec features
IDR discussion related to the draft-haas features has helped quantify some of
the incremental deployment issues:

Parsing the component, including new error handling requirements
Implementing the component in a filter
Rules with components that aren’t understood may result in “holes” in the
Flowspec term set. If the rules aren’t “independent”, mis-filtering may happen.

Incremental deployment of new Flowspec features (2)
Not Discussed, but Important:
• Component ID for new components can be critical for default sorting
of rules

Interactions with Flowspec v1
Operationally, the question is motivated by Flowspec v1 permitting multiple BGP
speakers in a Flowspec domain to inject routes.

• This was one of the problematic scenarios for term ordering
• A given Flowspec speaker may have both Flowspec v1 (RFC 8955)
routes, and routes with extensions. Those routes with extensions
could be a different SAFI or same SAFI with different format.
• Should the implemented filter be permitted to have contributors from both
types? • If the filters from the types are intended to be segregated, how
should they interact?

Discussion

Haibo: In which scenarios will the holes happen?
Jeff: The first question is that you would like an example for an independent
rules? Think if you have a flow specification rule that matches 10/8 that is
rate limiting with a specific host 10.1.1.1/32. If you lose the specific rule,
you will get the 10.1.1.1/32 at full rate. Jeff: The second question was the
partial deployment problem. Two ways that flow specification is distributed:
  RR plane that distributes routes
  Targeted distribution: Firewall controller that targets distributes the flow
  specification.
The challenging feature occurs in the RR plane that we may need a set of RR
plane (1 per AFI/SAFI) For example, the L2VPN is a different SAFI and it does
not need to distribute both SAFIs.

Jie Dong: I agree increment deployment features is an important capability. We
have some observation on the Flowspec deployments are in single domain or under
a single administrator. Maybe the unknown flowspec capability can be controlled
by administrator. When RR is used for the distribution, may need to consider
when the RR can propagate the flowspec routes with unkown components to other
nodes in the same domain. This may be similar to the behavior of RR on the
unkown Route Types in the EVPN case.

Jie Dong: Another observation is not all the hops along the flowspec
propagation path need to implement the filters. Maybe can consider the
distribution to targeted nodes. By limiting the scenarios to single domain, the
optional mechanisms for incremental deployment of new features can be further
discussed.

Jeff: It is valid that not every node needs to implement the filter. We have
problems with each device knowing how to apply the flow specification rules as
well as distribute. The main challenge is whether some flow specification
distribution safe to be applied only on some nodes in the network.

Jie Dong: So you mean for some type of rules, the inconsistency of the rules
may cause some problems.

Jeff: Simple DDOS rules can be [partially] distributed, but complex firewall
rules may

Action: Add an example on the mail list.

Christoph: Are we only discussing incremental deployment of new features?

Jeff: No. Other topics can also be discussed.

Christoph: We have multiple ways to decode the same information in flow
specification. This is not in the slides. There is no single set of NLRI to

Jeff: I am implementer/associated with an implementation that takes in one
format and rudely changes to another scope.

Jeff: Sergi you thought we should defer this work to v2?

Sergi: (no comment)

Donald: Seems to me like a compromise to clean-slate flowspec V2.

Sue: The real question is how to move this work forward. Do operators want V2,
or do they want the migration approach proposed by Jeff?

Jeff: Some features of V2 like term ordering can be done with incremental
extensions. BGP has been with v4 for a long time as we found the ways to make
incremental extensions to it.

Sue: If cannot decide （Clean-Slate or not）yet, we would like to take proposals
for both V1 and V2.

Jeff: Some feedback on the list shows some people prefer to do it in V2, as the
existing V1 mechanism works just fine.

Sue: how many people think the action ordering is something we should work on?

Christoph: The actions we use are rate limit, discard, and send traffic to
different VRFs. They can interoperate properly. The ordering of rules is a
problem and need to be solved. The ordering for DDoS case is someting
different. Prefer to have it in Flowspec v2.

Haibo: Popular actions are discard, remark DSCP, and redirect. Some operators
have the requirement to control the order of Flowspec rules. Jeff’s new draft
flowspec-term-order is working on this.

Warren: +1 to Christoph’s most common actions.

Sergey Fomin: Need to be careful about introducing new features regardless it
is in V1 or V2. the interoperability with existing V1 needs to be considered.
Prefer to leave the new features to V2.

Jeff: One of the nice thing of Flowspec V2 is to make the RR clear about the
encoding.

Sergey Fomin: in Flowspec v1 we already have fragmentations of different
flowspec components.

Sue: Appreciate your feedback, we will consider to solve the problem in v2.

Sergey Fomin: In the field the issue is the different implementations of
flowspec v1 in different vendors.

Sue: Do you have any comments about the 3 flowspec drafts we recently put to
IESG?

Christoph: We have the IPv4/v6 DDoS mitigation use cases in public routing and
VRF. Not sure if there is much to be added for the DDoS use cases. Can we say
we will use Flowspec V2 for new use cases, and leave the DDoS use case using V1?

Kotikalapudi Sriram: From security recommendations, the flowspec is used for
DDoS mitigation. Do not have much to add for now.

Sue: Look forward for your feedbacks on the list.

Kotikalapudi Sriram: Regarding the V2 with wide community, is it still on the
table?

Jeff: The flowspec nvo3 draft shows some requirement on this. we will see
further interactions between different functions.

Jeff: Regarding the new features, Juniper has one on the matching of payload,
and there is another one on service chaining. It is possible to have more once
we have v2. OTOH, the ordering feature of V2 is for the firewall cases. The
term-order draft is a minor change.

Sue: The conditions above highlight that for incremental deployment purposes
Flowspec domains may be segmented based on what components are supported within
that domain. How does that impact the use of the mechanism?

Jie: There are 3 types of ordering: 1) Flowspec rules ordering in Jeff’s
term-order draft 2) action ordering. 3) Components ordering. It may be helpful
to discuss the possible use cases of each so that people can have better
understanding about the requirements.

Linda: Mentions a draft which describes new way of use flow-specification (IPPM)

Jeff: Do we need extensions from flow-specification?

Sue: The action items: 1) in addition to the RR based distribution, also
consider the targeted distribution. 2) More feedbacks about the use cases.

Sue: Would like to see more feedbacks about the direction of V2. We will have
another interim on BGP autoconf in 2 weeks.

(Meeting adjourned.)