Re: 24x7 vs 24x7x365 Re: Constant Abuse Reports / Borderline Spamming from RiskIQ
On 2020-04-18, at 03:08, Rich Kulawiec wrote: > > 24x7x365 thus means every hour of 7 years. YES, I know, I know. Clearly, it means the NOC only operates in the seven years of great abundance that precede the seven years of famine (Genesis 41:29 etc.). I think I have seen such NOCs before :-) Grüße, Carsten
Re: 24x7 vs 24x7x365 Re: Constant Abuse Reports / Borderline Spamming from RiskIQ
Rich. I am truly sorry. also this was great thank you. -Ben > On Apr 17, 2020, at 6:09 PM, Rich Kulawiec wrote: > > (since it's Friday and we're all stressed) > > I can't believe that out of everything I wrote that we're going to discuss > the semantics of this, but then again: yes I can. I should have known. > I should have known. I. Should. Have. Known. *bangs head on desk* > *reaches for scotch* Alrighty then: > > 24x7 means every hour of the week, as in "24 by 7". > > 24x365 means every hour of the year. (modulo those with 366 days >but please let's not go there because this is bad enough) >(oh wait, too late, someone upthread already went there) >(and then leap seconds reared their ugly head, oh good grief) > > 24x7x365 thus means every hour of 7 years. YES, I know, I know. > > 60x24x7...no. NO. I will not go there. Nor will you. Just stop. >I swear I will turn this car around *right now*. > > Yeah, I know it's in common use. Like any number of other things in > common use (e.g., "going forward" -- really? like there's another > direction to go?) it's...annoying. > > I suspect that someone who just wasn't thinking started this in an > attempt to out-promote people who merely said 24x7 or 24x365, and it > propagated outwards. If that hypothesis is correct and there is thus > a patient 0 for this epidemic, I very much want to find them and pummel > them with a bag of Oxford commas. > > rsk
Re: 24x7 vs 24x7x365 Re: Constant Abuse Reports / Borderline Spamming from RiskIQ
On Fri, Apr 17, 2020 at 6:09 PM Rich Kulawiec wrote: > 24x7 means every hour of the week, as in "24 by 7". > > 24x365 means every hour of the year. (modulo those with 366 days > but please let's not go there because this is bad enough) > (oh wait, too late, someone upthread already went there) > (and then leap seconds reared their ugly head, oh good grief) > > 24x7x365 thus means every hour of 7 years. YES, I know, I know. If we're gonna do this, let's at least inform the discussion with a few citations: https://www.lawinsider.com/dictionary/24x7x365 https://www.macmillandictionary.com/us/buzzword/entries/24-7-365.html https://en.wikipedia.org/wiki/24/7_service Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: 24x7 vs 24x7x365 Re: Constant Abuse Reports / Borderline Spamming from RiskIQ
(since it's Friday and we're all stressed) I can't believe that out of everything I wrote that we're going to discuss the semantics of this, but then again: yes I can. I should have known. I should have known. I. Should. Have. Known. *bangs head on desk* *reaches for scotch* Alrighty then: 24x7 means every hour of the week, as in "24 by 7". 24x365 means every hour of the year. (modulo those with 366 days but please let's not go there because this is bad enough) (oh wait, too late, someone upthread already went there) (and then leap seconds reared their ugly head, oh good grief) 24x7x365 thus means every hour of 7 years. YES, I know, I know. 60x24x7...no. NO. I will not go there. Nor will you. Just stop. I swear I will turn this car around *right now*. Yeah, I know it's in common use. Like any number of other things in common use (e.g., "going forward" -- really? like there's another direction to go?) it's...annoying. I suspect that someone who just wasn't thinking started this in an attempt to out-promote people who merely said 24x7 or 24x365, and it propagated outwards. If that hypothesis is correct and there is thus a patient 0 for this epidemic, I very much want to find them and pummel them with a bag of Oxford commas. rsk
RE: attribution
From version 6.3.1, IOS XR supports "if community length" in route-policy. Regards, Jakob. -Original Message- Date: Fri, 17 Apr 2020 12:29:33 +0100 From: On the point of as-path length limit, Yes I know of at least one tier-1 that does it and since I left some 8 years back I do it everywhere I go. In addition to the above (best common practice, id' say) -on junos you can do community length limiting -and on cisco you can do attribute filtering -hence my question to this forum some time back about whether folks do filter all the "experiments" for the sake of running a successful business (paraphrasing...) adam
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 18 Apr, 2020 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 806496 Prefixes after maximum aggregation (per Origin AS): 306294 Deaggregation factor: 2.63 Unique aggregates announced (without unneeded subnets): 393395 Total ASes present in the Internet Routing Table: 67775 Prefixes per ASN: 11.90 Origin-only ASes present in the Internet Routing Table: 58227 Origin ASes announcing only one prefix: 24284 Transit ASes present in the Internet Routing Table:9548 Transit-only ASes present in the Internet Routing Table:293 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 43 Max AS path prepend of ASN ( 27978) 31 Prefixes from unregistered ASNs in the Routing Table: 1135 Number of instances of unregistered ASNs: 1138 Number of 32-bit ASNs allocated by the RIRs: 31315 Number of 32-bit ASNs visible in the Routing Table: 25896 Prefixes from 32-bit ASNs in the Routing Table: 119373 Number of bogon 32-bit ASNs visible in the Routing Table:21 Special use prefixes present in the Routing Table:1 Prefixes being announced from unallocated address space:887 Number of addresses announced to Internet: 2854764032 Equivalent to 170 /8s, 40 /16s and 62 /24s Percentage of available address space announced: 77.1 Percentage of allocated address space announced: 77.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.5 Total number of prefixes smaller than registry allocations: 271711 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 212063 Total APNIC prefixes after maximum aggregation: 62008 APNIC Deaggregation factor:3.42 Prefixes being announced from the APNIC address blocks: 205066 Unique aggregates announced from the APNIC address blocks:85529 APNIC Region origin ASes present in the Internet Routing Table: 10525 APNIC Prefixes per ASN: 19.48 APNIC Region origin ASes announcing only one prefix: 2927 APNIC Region transit ASes present in the Internet Routing Table: 1567 Average APNIC Region AS path length visible:4.5 Max APNIC Region AS path length visible: 25 Number of APNIC region 32-bit ASNs visible in the Routing Table: 5590 Number of APNIC addresses announced to Internet: 766930816 Equivalent to 45 /8s, 182 /16s and 111 /24s APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-141625 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:235932 Total ARIN prefixes after maximum aggregation: 108500 ARIN Deaggregation factor: 2.17 Prefixes being announced from the ARIN address blocks: 233397 Unique aggregates announced from the ARIN address blocks:118491 ARIN Region origin ASes present in the Internet Routing Table:18432 ARIN Prefixes per ASN:12.66 ARIN
Re: BIRD / BGP-ORR experiences?
On 16 Apr 2020, at 22:35, Mark Tinka wrote: > > > >> On 15/Apr/20 19:07, Saku Ytti wrote: >> >> >> Don't run Cisco ORR RR or have IGP next-hops :/ > > Does it break NEXT_HOP=self in Cisco-land? > > Mark. We’re testing ORR at the moment as part of core upgrades (XRv on ESXi), and next-hop self not only works, it’s required for ORR to work properly I’ve not noticed any major issues with it yet but it’s still early days in terms of our deployment
Re: Constant Abuse Reports / Borderline Spamming from RiskIQ
On Wed, Apr 15, 2020 at 11:33:58PM -0400, Ross Tajvar wrote: > Can you give some examples of the things you mention above? I'm not doing > much in terms of customer filtering and would be interested to hear what > others consider best practice. Sure. These are just examples and are by no means exhaustive. Also, some will work better than others depending on who you are, what services you offer, where you are, etc. There's no substitute for human judgment seasoned with experience. 1. Let's start with a timely one. Whenever there's a national or global crisis, scammers begin registering domains to exploit it. For instance: Thousands of COVID-19 scam and malware sites are being created on a daily basis https://www.zdnet.com/article/thousands-of-covid-19-scam-and-malware-sites-are-being-created-on-a-daily-basis/ [I'll omit the long rant about why ICANN is responsible for this and should be ashamed of what they've not only allowed, but encouraged.] That story contains a link to a repository where somebody is tracking these. I pulled that list a month ago and there were 7500 entries. Now there are over 25,000. (Caveat for anybody doing the same: note carefully the methodology. There are legitimate domains/subdomains/hosts in there, although they're rapidly being swamped by the bogus ones. So don't just blindly use the data: filter out the 1-2% of legitimate entries.) So, if it's April 2020, and a customer comes to you and wants to set up web service for a domain or fifty that have "covid", "corona", "virus", etc., in their names: they're probably up to something. 2. There are longstanding versions of (1) as well. Domains with strings in them like "bulk", "seo", "credit", etc., or domains with variations on the names of financial institutions, or domains which are typos of well-known domains, etc., are all suspect. *That doesn't mean they're all bogus.* It just means that a human being should give them closer scrutiny before the process goes forward. 3. Look at the diversity of their domains. This sort of is a rehash of what I said in (2), but: if all their domains are about one or two topics, yeah, it's probably someone with a business and a hobby or something like that. But if they have domains that suggest they're running 17 different businesses, then look closer. 4. Look at whether they've been, that is, where they were hosted previously, by checking their DNS history. If they've hopped through four different hosts in the last seven months, something is going on. (Note: a few months ago a bunch of cheap VPS services all simultaneously ceased operations. If they were on one of those, then they may have just been caught up in the mess, so don't count that against them.) 5. Check Spamhaus. 6. Find out how many domains they have. People doing legitimate things may have 5 or 17 or something like that. People who have 5,000 are up to something. (Note: I've been doing research in this area for many years. I know of zero instances where registrants with thousands of domains were doing something legitimate. There may still be a counterexample out there, but I haven't seen it yet.) 7. MLM (multi-level marketing) is a red flag. So is Bitcoin et.al. 8. A business putatively located in Iowa but with contact email addresses @163.com or @yandex.com is dubious. Same for other incongruous information: it might really be okay, or it might be a hint that they're up to something. Most of these are just indicators: they're not definitive. And there are counterexamples all over the place. Plus, this list isn't exhaustive: like I said they're just examples. That's why I said at the beginning that there's no substitute for human judgment seasoned with experience. That takes time and probably more than a few bad experiences. But it's worth it, because it's easier to solve problems before you have them. ---rsk
RE: attribution
> Christopher Morrow > Sent: Tuesday, April 14, 2020 2:51 AM > > On Mon, Apr 13, 2020 at 7:38 PM Brandon Martin > wrote: > > > > On 4/13/20 4:31 PM, Randy Bush wrote: > > > it seems a lot of folk think prepending acrually works. > > > > I mean, there's prepending and then there's prepending 50+ times... > > Has the latter EVER been useful in any way, shape, or form? > > for ~4 yrs or so there's been possible problems with as-paths longer than ~50 > (I think, i can't recall the exact vendor bug) so, folk should have already > been > denying announcements with longer than ~soemthing-like-45 asn in the > path.. right? :) > >From memory this was one of the two accidents (someone prepending their AS 255 >times and an university announcing special unheard-of attribute) that >triggered the good work around RFC 7606 - Revised Error Handling for BGP >UPDATE Messages. And why Randy and we all can enjoy messages like Apr 12 17:57:42 r0.iad rpd[1752]: Prefix Send failed ! 103.148.41.0/24 bgp_rt_trace_too_big_message:1209 path attribute too big. Cannot build update. Or RP/0/RSP0/CPU0:Jan 18 00:22:41.029 : bgp[1058]: %ROUTING-BGP-3-MALFORM_UPDATE : Malformed UPDATE message received from neighbor x.x.x.x (VRF: INTERNET) - message length 87 bytes, error flags 0x0040, action taken "DiscardAttr". Error details: "Error 0x0040, Field "Attr-unexpected", Attribute 128 (Flags 0xe0, Length 18), Data [e0801200]". NLRIs: [IPv4 Unicast] <> While our BGP sessions keep on working just fine and either the update is treated as withdraw or the attribute is deleted. On the point of as-path length limit, Yes I know of at least one tier-1 that does it and since I left some 8 years back I do it everywhere I go. In addition to the above (best common practice, id' say) -on junos you can do community length limiting -and on cisco you can do attribute filtering -hence my question to this forum some time back about whether folks do filter all the "experiments" for the sake of running a successful business (paraphrasing...) adam
Re: UDP/123 policers & status
On 4/17/2020 2:01 AM, Ragnar Sundblad wrote: > > I thought we were talking about control traffic. I expect there will be a TCP control traffic option. I expect there will continue to be a UDP control traffic option. These are "mechanisms", there will be a reasonable default policy (that will change and evolve over time), and there will be a mechanism to allow the local admins to implement their local policy choices. > If you want to do some NTP time comparison mode with larger responses > than requests, I agree that TCP is likely not a good option. I still don't see why, in the general case, some here think we must force a smaller request packet to be padded just so a possibly larger response packet will provide no amplification. Basic packets are of a known and identical size. Before the 7822 braindamage (my opinion of 7822), EFs *required* MACs. Post 7822 they don't, but even so, if people implement EFs and don't include (disable?) "protection" they've pretty much made their choice. But we're speaking in generalities here. What new or proposed packet content would trigger a larger response that would not require an authenticated request in the first place? And I just realized this is the NANOG list and not the NTP list, so I'm happy to stop. H -- > Ragnar > >> On 17 Apr 2020, at 10:44, Harlan Stenn wrote: >> >> NTP uses UDP for time. >> >> I'm not sure what you're talking about. >> >> H >> >> On 4/17/20 1:32 AM, Ragnar Sundblad wrote: >>> >>> On 17 Apr 2020, at 01:28, Harlan Stenn wrote: I found this as an unsent draft - I hope I didn't send it before. On 3/30/2020 2:01 AM, Ragnar Sundblad wrote: > > >> On 30 Mar 2020, at 08:18, Saku Ytti wrote: >> >> On Mon, 30 Mar 2020 at 01:58, Ragnar Sundblad wrote: >> >>> A protocol with varying packet size, as the NTS protected NTP is, >>> can easily have the bad property of having responses larger than the >>> requests if not taken care. Don’t you see that? >> >> Why? Why not pad requests to guarantee attenuation vector until >> authenticity of packets can be verified? > > Right, and NTS does that. There is more to NTP than NTS. Are y'all seriously recommending that NTP always sends a max-sized packet as a client request so the client/server can send back an identical response? That's just wasting huge amounts of bandwidth to save the possibility of a possibly larger response. >>> >>> If there is no sender verification, yes. It doesn’t have to be larger >>> than the maximum response size. >>> >>> Another option is to use TCP - the handshake solves the problem. >>> And just becase a responbse may be larger, that doesn't necessarily translate into an amplification vector. >>> >>> If there is no sender verification, it generally does. >>> In what case does it not? >>> The alternative seems to be that the client sends a smaller request and is ready when the response from the server is "Send your request again, but this time pad it to NNN bytes so I can respond with the same sized packet"? >>> >>> Sure, that is one way! >>> Or - Here are the first N entries, send another request for the >>> next batch, optionally: there are M entries in total. >>> Or - TCP. >>> There likely are many other options. >>> >>> Ragnar >>> >>> >> >> -- >> Harlan Stenn >> http://networktimefoundation.org - be a member! > > -- Harlan Stenn http://networktimefoundation.org - be a member!
IS-IS Error (FRR)
Hi all. I'm almost there getting IS-IS to work without issue. I'm now faced with the following error log: 2020/04/17 10:02:01 ISIS: IS-IS bpf: could not transmit packet on em0: Input/output error 2020/04/17 10:02:01 ISIS: [EC 67108865] ISIS-Snp (1): Send L2 PSNP on em0 failed This repeats every second. Anyone know what this could be? Systems is FreeBSD-12.1-RELEASE-p3. Despite the error, IS-IS is running and routing is good, talking to a Cisco IOS XE implementation on the other side. So the error is throwing me off. No feedback from the Slack feed, Google doesn't say much, and waiting to hear back from the FRR list. Mark.
Re: UDP/123 policers & status
I thought we were talking about control traffic. If you want to do some NTP time comparison mode with larger responses than requests, I agree that TCP is likely not a good option. Ragnar > On 17 Apr 2020, at 10:44, Harlan Stenn wrote: > > NTP uses UDP for time. > > I'm not sure what you're talking about. > > H > > On 4/17/20 1:32 AM, Ragnar Sundblad wrote: >> >> >>> On 17 Apr 2020, at 01:28, Harlan Stenn wrote: >>> >>> I found this as an unsent draft - I hope I didn't send it before. >>> >>> On 3/30/2020 2:01 AM, Ragnar Sundblad wrote: > On 30 Mar 2020, at 08:18, Saku Ytti wrote: > > On Mon, 30 Mar 2020 at 01:58, Ragnar Sundblad wrote: > >> A protocol with varying packet size, as the NTS protected NTP is, >> can easily have the bad property of having responses larger than the >> requests if not taken care. Don’t you see that? > > Why? Why not pad requests to guarantee attenuation vector until > authenticity of packets can be verified? Right, and NTS does that. >>> >>> There is more to NTP than NTS. >>> >>> Are y'all seriously recommending that NTP always sends a max-sized >>> packet as a client request so the client/server can send back an >>> identical response? That's just wasting huge amounts of bandwidth to >>> save the possibility of a possibly larger response. >> >> If there is no sender verification, yes. It doesn’t have to be larger >> than the maximum response size. >> >> Another option is to use TCP - the handshake solves the problem. >> >>> And just becase a responbse may be larger, that doesn't necessarily >>> translate into an amplification vector. >> >> If there is no sender verification, it generally does. >> In what case does it not? >> >>> The alternative seems to be that the client sends a smaller request and >>> is ready when the response from the server is "Send your request again, >>> but this time pad it to NNN bytes so I can respond with the same sized >>> packet"? >> >> Sure, that is one way! >> Or - Here are the first N entries, send another request for the >> next batch, optionally: there are M entries in total. >> Or - TCP. >> There likely are many other options. >> >> Ragnar >> >> > > -- > Harlan Stenn > http://networktimefoundation.org - be a member!
Re: UDP/123 policers & status
NTP uses UDP for time. I'm not sure what you're talking about. H On 4/17/20 1:32 AM, Ragnar Sundblad wrote: > > >> On 17 Apr 2020, at 01:28, Harlan Stenn wrote: >> >> I found this as an unsent draft - I hope I didn't send it before. >> >> On 3/30/2020 2:01 AM, Ragnar Sundblad wrote: >>> >>> On 30 Mar 2020, at 08:18, Saku Ytti wrote: On Mon, 30 Mar 2020 at 01:58, Ragnar Sundblad wrote: > A protocol with varying packet size, as the NTS protected NTP is, > can easily have the bad property of having responses larger than the > requests if not taken care. Don’t you see that? Why? Why not pad requests to guarantee attenuation vector until authenticity of packets can be verified? >>> >>> Right, and NTS does that. >> >> There is more to NTP than NTS. >> >> Are y'all seriously recommending that NTP always sends a max-sized >> packet as a client request so the client/server can send back an >> identical response? That's just wasting huge amounts of bandwidth to >> save the possibility of a possibly larger response. > > If there is no sender verification, yes. It doesn’t have to be larger > than the maximum response size. > > Another option is to use TCP - the handshake solves the problem. > >> And just becase a responbse may be larger, that doesn't necessarily >> translate into an amplification vector. > > If there is no sender verification, it generally does. > In what case does it not? > >> The alternative seems to be that the client sends a smaller request and >> is ready when the response from the server is "Send your request again, >> but this time pad it to NNN bytes so I can respond with the same sized >> packet"? > > Sure, that is one way! > Or - Here are the first N entries, send another request for the > next batch, optionally: there are M entries in total. > Or - TCP. > There likely are many other options. > > Ragnar > > -- Harlan Stenn http://networktimefoundation.org - be a member!
Re: UDP/123 policers & status
> On 17 Apr 2020, at 01:28, Harlan Stenn wrote: > > I found this as an unsent draft - I hope I didn't send it before. > > On 3/30/2020 2:01 AM, Ragnar Sundblad wrote: >> >> >>> On 30 Mar 2020, at 08:18, Saku Ytti wrote: >>> >>> On Mon, 30 Mar 2020 at 01:58, Ragnar Sundblad wrote: >>> A protocol with varying packet size, as the NTS protected NTP is, can easily have the bad property of having responses larger than the requests if not taken care. Don’t you see that? >>> >>> Why? Why not pad requests to guarantee attenuation vector until >>> authenticity of packets can be verified? >> >> Right, and NTS does that. > > There is more to NTP than NTS. > > Are y'all seriously recommending that NTP always sends a max-sized > packet as a client request so the client/server can send back an > identical response? That's just wasting huge amounts of bandwidth to > save the possibility of a possibly larger response. If there is no sender verification, yes. It doesn’t have to be larger than the maximum response size. Another option is to use TCP - the handshake solves the problem. > And just becase a responbse may be larger, that doesn't necessarily > translate into an amplification vector. If there is no sender verification, it generally does. In what case does it not? > The alternative seems to be that the client sends a smaller request and > is ready when the response from the server is "Send your request again, > but this time pad it to NNN bytes so I can respond with the same sized > packet"? Sure, that is one way! Or - Here are the first N entries, send another request for the next batch, optionally: there are M entries in total. Or - TCP. There likely are many other options. Ragnar
