Custom rule

[uninth]

Port specification(s):

Range:

The lowest port numer for filtering is 0, while the largest port number is an unsigned short 2^16-1: 65535, as specified in RFC 793. Port 0 which is not a valid port may be set in a UDP or TCP package and transported 'over the wire', see Port Authority Database, Port 0

Filter specification(s):

For each rule only one of the following syntaxes are allowed:

• range: lower boundary - upper boundary, e.g. =80-8080
• any combination of: =port =port >=port <=port ... e.g. =80 =443 <=1023

The & sign is not accepted by Juniper: it breaks the BGP sesstion.

You may not specify both a range and something else.

Package length specification(s):

Here the length of an IP datagram is messured, so the range is between 20 and 65535 (bytes).

Range:

Size of Ethernet frame - 24 Bytes Size of IPv4 Header (without any options) - 20 bytes Size of TCP Header (without any options) - 20 Bytes So total size of empty TCP datagram - 24 + 20 + 20 = 64 bytes

Size of UDP header - 8 bytes So total size of empty UDP datagram - 24 + 20 + 8 = 52 bytes

But I think you can create an empty IP frame with 20 bytes

The maximum size of an IP datagram is 65535 bytes while jumbo frames may be 9038 bytes long see wikipedia.

I don't think we should impose an upper limit.

Filter specification(s):

• range: lower boundary - upper boundary, e.g. =20-9000
• any combination of: =length =length >=length <=length ... e.g. =348 =512 >=1470

Venlig hilsen / Best regards, Niels Thomas Haugård

-- Niels Thomas Haugård _ __/| Work E-mail: niels.thomas.haugaard@i2.dk \'x X' Private E-mail: thomas@haugaard.net =(o)= Private PGP key: ldap://keyserver.pgp.com U My desk isn't messy - it's encrypted |>o<|

On 22 Jun 2018, at 14.30, Ashokaditya notifications@github.com wrote:

Merged #36 https://github.com/deic-dk/gossamer/pull/36.

— You are receiving this because your review was requested. Reply to this email directly, view it on GitHub https://github.com/deic-dk/gossamer/pull/36#event-1695836607, or mute the thread https://github.com/notifications/unsubscribe-auth/AZKIqV2rXbXaaE2JauoorPWJWPiFJNJ0ks5t_ONjgaJpZM4Ux2u2.

[ashokaditya]

This is a precise list 👍 Thanks @uninth

[ashokaditya]

@uninth @loregood What do you think about rate limit? rate limit is in [1, 10^9] ?

[AndersMundtDue]

Rate limit is int >= 1

Anders Mundt Due Technician

---

From: Ashokaditya notifications@github.com Sent: 26 June 2018 13:44:56 To: deic-dk/gossamer Cc: Anders Mundt Due (DEIC); Review requested Subject: Re: [deic-dk/gossamer] Custom rule (#36)

@uninthhttps://github.com/uninth @loregoodhttps://github.com/loregood What do you think about rate limit? rate limit is in [1, 10^9] ?

— You are receiving this because your review was requested. Reply to this email directly, view it on GitHubhttps://github.com/deic-dk/gossamer/pull/36#issuecomment-400277816, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AZZvnqCeCjUB7mwroRcEo1BVKr-FharLks5uAh64gaJpZM4Ux2u2.

[ashokaditya]

@AndersMundtDue Is there no upper limit on the rate limit?

[ashokaditya]

@TanguiC any suggestions?

[AndersMundtDue]

there are plenty of upper limits, but they're not our concern ... int >= 1 is imho the best check for ratelimit.

The RFC has a type 0x8006 traffic-rate that can be transported, is has a IEEE.754.1985 float describing bytes per second and a traffic-rate of 0 should result in all traffic being blocked.

The 4 types that can be transported over BGP FlowSpec are:

" 0x8006 - Flow spec traffic-rate 0x8007 - Flow spec traffic-action 0x8008 - Flow spec redirect 0x8009 - Flow spec traffic-remarking "

But we're actually sending BGP FlowSpec to a juniper and they say:

"Limit the bandwidth on the flow route. Express the limit in bits per second (bps). Beginning with Junos OS Release 16.1R4, the rate-limit range is [0 through 1000000000000]."

So in that specific release they have an upper limit of 1Tb/s which is 10 times our current capacity, we're also running Junos 17.1 and planning to get to Junos 17.1R3 which may or may not have a different upper limit.

Still, I would say that all that is largely irrelevant for us and that int >0 would serve the website well as a simple check.

[AndersMundtDue]

juniper stuff is from https://www.juniper.net/documentation/en_US/junos/topics/concept/flow-routes-understanding.html in case you want to look :-)

[ashokaditya]

Thanks for the input @AndersMundtDue. @loregood suggested yesterday we have an upper limit of 10^11 which is 10 times less than Juniper's, just as you mention above. Shall we keep that for now if everyone agrees?

[ashokaditya]

Super! Tagged this conversation to #37