[Idr] Re: 2 week adoption call for draft-hares-ietf-idr-fsv2-ip-basic (6/1/2024 to 6/14/2024) - extended to 7/26

[Susan Hares <[e-mail]>]

Robert:

Removing user order of filter rules from the NLRI is not one of the options for this adoption call.  Please note that the focus is a minimal subset of the original draft from draft-ietf-idr-flowspec-v2.

You made a good point on the identifier.   draft-hares-idr-fsv2-ip-basic-03 – changes the identifier to a filter chain dependency.  For draft-hares-idr-fsv2-ip-basic-03, this field is not required and should be set to all zeros. Filter dependency is one of the two key concepts in draft-ietf-idr-flowspec-v2 that were not included in the draft-hares-idr-fsv2-ip-basic.

Thank you for commenting on the confusion caused by the language regarding matches on filters and actions in draft-hares-idr-fsv2-ip-basic-02. I will attempt to address that in the next version.  The confusion comes from two key concepts: Filter chains and action chains from draft-ietf-idr-flowspec-v2.

Both of these concepts require additional review by the IDR WG.  Therefore, these are NOT included in the base document. At this time we are simply saving a place-holder for this in the filter dependency in the NLRI.

1: Filter chains
The concept of Filter chains refers to chains of filters where certain filters may depend upon another filter  (see the presentation at IETF-120 on Friday). One can always do this by using the rule numbering in filters.  However, there was a request for rule ordering + dependent filters.

You want to catch packets with an IP TTL of 200 from the IP Source address 192.2.1.5 to port 10. After you catch these packets, you want to copy (for processing) and drop them from the router. This is due to a DDOS attack.

One way with 3 rules (filter and action) of:

  1.  Rule 1 – TTL >  200, action: rate-limit packets, mark dscp
  2.  Rule 2 – IP Source address of 195.2.1.5, UDP port 10, (copy, drop, and stop actions)
  3.  Rule 3 -  IP Destination address 192.2.1.6, drop


Another way would be to make Rule 2 dependent on Rule 1 matches.  This is not a problem with these 3 rules, but what if you added a filter for TTL < 20 to move close traffic toi another firewall.

One way with actions would be,

  1.  Rule 1 – TTL >  200, actions: rate-limit packets,  mark dscp go to rule 3.
  2.  Rule 2 – TTL < 20, action: redirect to 192.2.3.1
  3.  Rule 3 filters on the IP Source address of 195.2.1.5 and UDP port 10. The actions are copy,  redirect to IP 192.2.3.2, and terminate.
  4.  Rule 4 -  IP Destination address 192.2.1.6, drop

How do we engage this logic?  Is it useful?

B. Action Chains
We have the concept of sets of actions because multiple Communities can be associated with a match of a filter rule.  The Terminate flag – stops the processing on the actions.

The action chain in rule 1 is a) rate-limit packets and b) mark dscp.
The action chain in rule 3 is a) copy, b) redirect to 192.2.3.2 and c) stop processing actions.

What happens if the “rate limit” in rule 1 fails to occur on this firewall?  This action failure impacts the validity of the chain of events.  (Aka an Action chain failure).

Should the firewall “keep going” and mark dscp?  Should the processing go on to rule 3? The actions need to be common across vendors.

To your last question, on NLRI types

The current design is to share common processing (user ordering, filter chains, action chains) in the same NLRI for the following types of filters:

  1.  IP filters from FSv1 [filter components 1-13]
  2.  Extended IP filters from FSv2 – TTL, SRH (SID) and NRP-IP in IPv6
  3.  L2 Filters
  4.  MPLS filters
  5.  Tunnel filters

The segregation of filters by type allows vendors to implement a portion of the FSv2.

Thanks for sharing your opinion.

I’m sorry this got delayed due to my unexpected absence from work after June 15.

Sue






From: Robert Raszuk <[e-mail]>
Sent: Wednesday, June 12, 2024 5:08 AM
To: Susan Hares <[e-mail]>
Cc: [e-mail]
Subject: Re: [Idr] 2 week adoption call for draft-hares-ietf-idr-fsv2-ip-basic (6/1/2024 to 6/14/2024)

Hi Sue, My point was that ordering sometimes makes sense (injection of policy from central controller) and sometimes it does not (injection of policies from distributed network elements). With that sa
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tL2EzY2JkNzRhMzU2ZWFkMjNjMjA5ODdmNWRkYTQ2ZmUzLzE3MTgxODMyOTYuNDE=#key=5137615cd224d5bedbba6572e92a4b19>  FAQ<https://www.godaddy.com/help/report-email-with-advanced-email-security-40813>  GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky>

Hi Sue,

My point was that ordering sometimes makes sense (injection of policy from central controller) and sometimes it does not (injection of policies from distributed network elements).

With that said I would consider removing it from NLRI and ship in an extended community instead and therefore making it optional.

It would be also very useful to come up with a way to compute compatible ordering value from component chains automatically perhaps a bit building upon what is currently used as comparison recommendation in FSv1 (including the python pseudocode in RFC8955).

While we are at this I also find it questionable to include an identifier as part of NLRI.

See the fundamental problem with such fields in the NLRIs is that they make NLRIs unique while they are really opaque to NLRI substance which is set of match criteria.

The draft is also a bit confusing as it says that ordering applies to match and actions while it really only applies to match and actions have their own default ordering defined - so I am not sure  how they are user defined. Specifically I do not see how defined ACO would permit user to list user define action chain. I do see it helps to determin what to do on failure etc ...

This sentence from section 3.3.3 I think needs a bit of completion as well:

"For example, if the first action was copy (via a mirror action) and the second action is the packet."

Also a bit general question ... how do you plan to make sure future NLRI Types are supported under single SAFI capability ? Yes we have few of those typed NLRIs already, but at best I have seen recommendations to blindly drop if not supported - not sure this is best choice from protocol design POV - seems more like an action of last resort.

Many thx,
R,

On Tue, Jun 11, 2024 at 10:01 PM Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:
Robert:

The WG requirement for FSv2 was BGP:  a) simple upgrade from FSv1 with user priority on filters, and b) platform to grow from.   BGP is just using FSV2 to multicast the filters.

When the implementations of DDOS + other applications take this data and use it, there could be the “fun” you mention below.   It’s the art of the implementation.

But … did I miss your point?

Sue


From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, June 11, 2024 3:34 PM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] 2 week adoption call for draft-hares-ietf-idr-fsv2-ip-basic (6/1/2024 to 6/14/2024)


Hi Sue,

Then we run into the very same situation as today where few hundred flow spec originators would inject the same priority. Falling back to FSv1 ordering based on the binary treatment of chain of match components in such cases does not seems like huge improvement.

Now the fun starts where the node receiving new FSv2 rules would need to locally arbitrate on the priority when building the local TCAM table not only against existing FSv1 rules, but also with existing local ACL rules.

With high speed hardware pipeline based lookups this entire thing get's pretty interesting.

Many thx,
Robert



On Tue, Jun 11, 2024 at 8:50 PM Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:
Robert:

Given your example, the 1000 nodes could rate their filters as priority 1-10.  As they distribute their filters, they could

  1.  Set their DDOS filters as one  of the order 1-10 depending on the seriousness of the filters,
  2.  Let default ordering (FSv1 ordering) – ordering things per priority,

I hope this FSv2 examples shows that user ordering handle both your use case and the central controller.

Cheers, Sue


From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, June 11, 2024 12:02 PM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] 2 week adoption call for draft-hares-ietf-idr-fsv2-ip-basic (6/1/2024 to 6/14/2024)


Hi Sue,

I have one fundamental question in respect to addition of user ordering ...

From text of the subject draft we read:

   During the deployment of BGP FSv1 a number of issues were detected
   due to lack of consistent TLV encoding for rules for flow
   specifications, lack of user ordering of filter rules and/or actions,

Well ... please kindly observe that the primary basis of FlowSpec proposal was its distributed nature not a BGP based configuration or policy push from central oracle.

Scenario:

Let's  imagine that 1000 edge nodes are to notice some attacks and inject their flow spec DDoS descriptions into the network

Question:

How would those 1000 edge nodes detecting malicious attack patterns now synchronize with each other to inject Flow Spec rules with fixed ordering such that it would still network wide make sense ?

If FlowSpec v2 is aimed as protocol extension to be ONLY used from user operated controller as a central brain of the network rules let's make it very clear up front in the scope of v2.

Kind regards,
Robert


On Sat, Jun 1, 2024 at 11:32 AM Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:
Greetings:

This begins a 2 week IDR WG adoption call for draft-ietf-idr-fsv2-ip-basic-02.txt.

This draft provides a sub-set of the flow specification v2 work that provides:

  1.  Flow specification v2 – user ordering,
  2.  Flow specification v1 – filters, and
  3.  Flow specification v1 actions in Extended Community.

All FSv2 work would be required to implement this minimum subset.

All of this work comes from the IDR approved draft:
draft-ietf-idr-flowspec-v2-04.txt
https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-v2/<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org&t=h.eJxFjcsOwiAQRX_FsLYg0PeqvzJlBttUpRmoJjX-u8WN23Nuzn2LjW-iP4kppTX2SiEkSAxuIZYzJS8DXxUGp5DBpyKjYkYu_C284kqueBolziex5MiD0jHXl6qtO21UnIApDg_cJ-nCXYF1IzYl2KomQGOduXRt4ytEKGtPVulGt7q1pqtlqXOVcpXDSJwGhrhvizw-ssGf-aPPFxwnP44.MEUCIDEG6howNjsZHxIMwUIVqE1fjppIWXQGCZw_i0SfJAqdAiEA6UN4_YYyR7744uViGcuPRUZyNzJQo9GGA8QL4pBlhOA>

The purpose of this WG Adoption is to confirm that the minimum subset aligns with the IDR WG wishes.

Additional features that would be added to FSv2 are:

  1.  Additional IP filters,
  2.  Additional FSv2 Actions in Extended Communities
  3.  Additional FSv2 Actions in Community Path Attribute, and
  4.  Non-IP Filters, and
  5.  Non-IP Actions.

The FSv2 work will continue to have its interims on
6/3 (draft-hares-fsv2-ip-basic), 6/10 (more filters),  and 6/17 (actions + Non-IP work).

All Interims in June  (6/3, 6/10, and 6/17) start go from 10:00-11:30am EDT.

Cheerily, Sue Hares

_______________________________________________
Idr mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>