Skip to Content.
Sympa Menu

rare-users - Re: [RARE-users] [freertr] flowspec divert-* features ---- was: Re: Fwd: New Version Notification - draft-ietf-idr-bgp-ct-04.txt

Subject: RARE user and assistance email list

List archive

Re: [RARE-users] [freertr] flowspec divert-* features ---- was: Re: Fwd: New Version Notification - draft-ietf-idr-bgp-ct-04.txt


Chronological Thread 
  • From: "David Schmitz" <>
  • To: mc36 <>
  • Cc: "" <>, Niall Donaghy <>, Mohácsi János <>
  • Subject: Re: [RARE-users] [freertr] flowspec divert-* features ---- was: Re: Fwd: New Version Notification - draft-ietf-idr-bgp-ct-04.txt
  • Date: Tue, 13 Jun 2023 13:56:33 +0200 (CEST)
  • List-id: <freertr.groups.io>
  • Mailing-list: list ; contact

Hi Csaba,

On Tue, 13 Jun 2023, mc36 wrote:

Date: Tue, 13 Jun 2023 13:24:58 +0200
From: mc36 <>
To: David Schmitz <>
Cc: "" <>,
Niall Donaghy <>,
Mohácsi János <>
Subject: Re: [freertr] flowspec divert-* features ---- was: Re: Fwd: New
Version Notification - draft-ietf-idr-bgp-ct-04.txt

hmmmmmmmmmmmmmmmmm bth the more im thinkin' about thisss the more i "like" the idea.....

why nottt?! XDDDDD
Nice to hear that.


i just added thiss 2 the todo.txt and it's in the changelogg so it'll happen after i remove some easier/funnier stuffs b4... XDDDDD

https://github.com/rare-freertr/freeRtr/commit/fdea5b3521f50a7fcc78772d74fca8f0d1226565

^^^^^^^^^^^^^^^^^^^^^ is the files/etc to track forrr on the arrival of the bgp/vrf knobb....
Ok, great.


Best Regards
David


br,

cs


On 6/13/23 13:04, mc36 wrote:
hmmmm a day later and back 2 u againnnnn sooo,


normally u would not worry about the thread structures in java,

you just synchronized {anything} and the rest is up 2 the openjdk.org and kernel.org and thats all...


and you/we can always have a per bgp process then per vrf knob like "flowspec-diverts"

that turns this extra worker onn....... as it happened to flwspc-install and flwspc-advert b4....

XDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD


but to stick to the pre-agreed stuff, just lemme know when u have all the info i asked b4....

then we can have the -divert knobs in a week or so.......


br,

cs

On 6/12/23 15:08, David Schmitz wrote:
Hi Csaba,

On Mon, 12 Jun 2023, mc36 wrote:

Date: Mon, 12 Jun 2023 14:55:58 +0200
From: mc36 <>
To: David Schmitz <>,
"" <>
Cc: Niall Donaghy <>,
Moh csi J nos <>
Subject: Re: [freertr] flowspec divert-* features ---- was: Re: Fwd: New
Version Notification - draft-ietf-idr-bgp-ct-04.txt

hihi,

you're welcome and just let me know when things change about the divert-* needs at your side....
Ok, let's do it so.
I will keep you updated.


Best Regards
David


br,

cs

On 6/12/23 13:23, David Schmitz wrote:
Hi Csaba,

On Mon, 12 Jun 2023, mc36 wrote:

Date: Mon, 12 Jun 2023 12:18:50 +0200
From: mc36 <>
Reply-To: ,
To: David Schmitz <>,
"" <>
Cc: Niall Donaghy <>,
Moh csi J nos <>
Subject: Re: [freertr] flowspec divert-* features ---- was: Re: Fwd: New
Version Notification - draft-ietf-idr-bgp-ct-04.txt

anyway for your feature request (?), in that afi, the java code needs a new thread per bgp process

running 0-24 (eating cpu power *, electricity, memory, etc!!) and scan each flowspec bgp path (rule)

to see, if the mentioned rd/rt matches to a _current_ vrf and nexthop and what encap needs 4 that

and optionally export this to the dataplanes through the common api....

^^^ so i have not just legal/moral issues with the divert-* stuff but its above a fact u should consider...
I understand.
Thanks for your explanations and insights.

Regarding this need to extend the code and thread architecture of freertr
and the performance penalties which would be the result,
I suggest to not (yet) work on this on the, at least not on the short-term.


just read the flowspec v1 rfc yourself to see this verbed in a networker's (bgp) language.....

Best Regards
David


br,

cs


*: and for sure it'll have code parts that locks on the unicast/vpn/etc and the flowspec tables so it'll

in general slow down (lock=stop 4 everyone, cache flush, etc) the currently 1m route in 7sec performance.....



On 6/12/23 12:09, mc36 wrote:
yet another question that how many bytes and packets / sec u want to demo onn??

so do rare-team(mostly me) have to add this to the dpdk forwarder and decrease the spare buffer of

the cpu level1 instruction cache (cache misses, etc) or in the tofino (alex, khmm who builds??)

and then disable an other feature for that (an asic, with very limited code space), or whattt???

thanks,

cs

On 6/12/23 12:01, mc36 wrote:
to-->cc, mostly,

david,

even another question 4 u alone, without a cleaner in place whats

your plan to demo this out in between the two vrfs, dynamically?!?!?

thx,

cs

On 6/12/23 11:55, mc36 wrote:
i see so 4 your use case you need redirect to vrf and ip or both?

does geant have cleanup capacity ~= ebgp capacity, already or in the upcoming years or whats the plan with thattt???

in other words, at that point most if not all of these cleaners could be used inline and then you can use them as is...

even more fun, if geant somehow can make the in/out traffic symmetric then ip[46] inspect is already there in the dataplanes with tls/ssl logging....

thx,

cs

On 6/12/23 11:18, David Schmitz wrote:
Hi Csaba,

On Mon, 12 Jun 2023, mc36 wrote:

Date: Mon, 12 Jun 2023 11:08:31 +0200
From: mc36 <>
To: David Schmitz <>
Subject: Re: [freertr] flowspec divert-* features ---- was: Re: Fwd: New
Version Notification - draft-ietf-idr-bgp-ct-04.txt
>>
u're welcome! :)
A short explanation:

FoD is up-to-now not concerned with redirection.

But NeMo is:
Basically NeMo can combine using FlowSpec for dropping or rate-limit-ing on the routers
together with redirection to local firewalls (e.g., one firewall per router) for cleaning.
These local Firewalls are developed by DFN itself based on linux iptables and so on.


So, as we are looking forward for a show-case for both, FoD and NeMo,
redirection might be interesting on the long-term.
The setup of these local Firewall (on VMs) might require help and support by
the NeMo team, which is currently busy with other things.

Anyway, NeMo can work also with dropping or rate-limit-ing on the routers alone
and so for the short-term this is definitely enough.


Best Regards
David


On 6/12/23 11:05, David Schmitz wrote:
Hi Csaba,

On Sun, 11 Jun 2023, mc36 wrote:

Date: Sun, 11 Jun 2023 09:30:09 +0200
From: mc36 <>
Reply-To: ,
To: Kaliraj Vairavakkalai <>
Cc: "" <>,
David Schmitz <>,
Niall Donaghy <>,
Moh csi J nos <>
Subject: [freertr] flowspec divert-* features ---- was: Re: Fwd: New Version
Notification - draft-ietf-idr-bgp-ct-04.txt

hmmmm... anyway as its written and sent/archived/virusscanned on both sides,

at this point imho let me cc the list on thiss tooo :)))



david, please read throughly the quoted/forwarded emails, it may interest u too....
Ok, will do that.


Many Thanks.

Best Regards
David


if u have a question, lemme ask and pls remove kaliraj & janos from that conversation... :)



kaliraj: david is preparing a geant firewall on demand (fod) demo pod to showcase: https://github.com/GEANT/FOD

map.geant.org is yet another boring jun1per shop as i see their boxes in my racks

and in their core isis; they assigned sids for each of their pes' /32 and /128 an

index already, and from the segment base i see what they purchased.... :)))



niall: you're here once again just because geant is mentioned as my fav. uplink

isp to "default route to", and you're my fav. contact there.... :))))



janos is my local trustworthy boss of a boss of a boss, rfc author, head of development at niif.hu, as far as i know.... :))



br,

cs



On 6/11/23 08:18, mc36 wrote:
hihi in p2p,

morning, etc! yess i know that flowspec redirect* features are here to detect from netflow and cleanup in an off-ramp vrf..

but, here we have 5+ secret services and tried not once to approach us with the idea to mirror/sniff the clearnet vrf... :(((

so thats why im from full heart against these redirect* things in flowspec.... and as i heard from other telco guys, basically

no a single box could be sold without the li "feature" butt, we're routers4academia&research so its a big no from the me and imho from the whole team!

(we wont let out shitloadz to get backdoored by a purpose, etc!)

but, if you have any good idea about the redirect-ip stuff, then let me know....

after 2nd tough on the topic is still that on an ebgp peering there is no reason to rewrite the later3 nexthops especially if we're in mpls encapped,

on ibgp, one should locpref on ingress ebgp and never play dirty tricks to alter an afi from an other afi...

ddos never lasted here more than 5-10 minutes or so, and policer/drop is fine for that: you usually have a magnitude higher ebgp capacity than cleanup capacity

aaand on the internet, the packet delivery is best effort! so if someone buys a permanent ddos on the darkweb then you can still fine-tune the flowspec/interface policers...

br,

cs


On 6/11/23 05:58, Kaliraj Vairavakkalai wrote:
I understand Csaba. No issues. It is an optional thing asper CT draft. So no issues.

One of the ways I have seen this Flowspec with redirect-ip feature been used is for

DDoS protection, to redirect a flow to a firewall device within an administrative domain.

In that way, it can be used to protect users against bad actors as-well.

But yes, any tool can be used in both good or bad ways.

So I understand if you don t want to implement flowspec redirect-to-ip feature. Totally fine with me. :)

Thanks

Kaliraj


Juniper Business Use Only

*From: *mc36 <>
*Date: *Saturday, June 10, 2023 at 5:30 PM
*To: *Kaliraj Vairavakkalai <>
*Subject: *Re: Fwd: New Version Notification - draft-ietf-idr-bgp-ct-04.txt

[External Email. Be cautious of content]


so it's a danger-danger-nooodle and i clearly wont let them to spy on "my" childs.... :)

On 6/11/23 02:29, mc36 wrote:
imho this is 4 the secret services (read spies, lawful intercept, etc) and thats why, but pls change my mind...









I understand Csaba. No issues. It is an optional thing asper CT draft. So no issues.

One of the ways I have seen this Flowspec with redirect-ip feature been used is for

DDoS protection, to redirect a flow to a firewall device within an administrative domain.

In that way, it can be used to protect users against bad actors as-well.

But yes, any tool can be used in both good or bad ways.

So I understand if you don t want to implement flowspec redirect-to-ip feature. Totally fine with me. :)

Thanks

Kaliraj


Juniper Business Use Only

*From: *mc36 <>
*Date: *Saturday, June 10, 2023 at 5:30 PM
*To: *Kaliraj Vairavakkalai <>
*Subject: *Re: Fwd: New Version Notification - draft-ietf-idr-bgp-ct-04.txt

[External Email. Be cautious of content]


so it's a danger-danger-nooodle and i clearly wont let them to spy on "my" childs.... :)




hihi in p2p chitty-chat...




fwd/quoted:

"
Flowspec redirect-to-ip with Mapping community

clearly red _NO_, we only support flowspec policer (or drop) and that propagates to the dataplanes....

regarding the flowspec divert (ip/vrf) features, its clearly _not_ and _wont_ happen on the todo.txt....

(tbh i have a strong opinion against this all but lemme not take this to a phylosophical discusssion:))

((tbh i even dont get the idea why the hell one would divert to a different ip on a p2p ethernet))

(((( regading the divert-vrf stuff, i fvkkkin just nooo never ever!!!!! srry 4 the language!!! ))))

"






imho this is 4 the secret services (read spies, lawful intercept, shell controll box, rdp recorder, tls intercept, etc) and thats why, but pls change my mind...


so it's a danger-danger-nooodle and i clearly wont let them to spy on "my" childs.... :)


we normally trust each others, it's just them who dont trust heir own sisters and brothers... :(


thx,

cs






























--

David Schmitz

Boltzmannstrasse 1, 85748 Garching
Telefon: +49 89 35831-8765
Leibniz-Rechenzentrum, Germany
Mail:




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#1445): https://groups.io/g/freertr/message/1445
Mute This Topic: https://groups.io/mt/99460357/6413194
Group Owner:
Unsubscribe: https://groups.io/g/freertr/unsub []
-=-=-=-=-=-=-=-=-=-=-=-





Archive powered by MHonArc 2.6.24.

Top of Page