Re: DDoS attack with blackmail

[Brandon Svec via NANOG]

I’m also curious if they did as promised.

I read this today:
https://beta.darkreading.com/threat-intelligence/-fancy-lazarus-criminal-group-launches-ddos-extortion-campaign

Best.

On Wed, Jun 9, 2021 at 8:35 AM Edvinas Kairys 
wrote:

> Hey,
>
> Did you get the attack promised ? after 1 week after notice ?
>
> Today we've been warned and got some udp flood for 3 hours.
>
> On Tue, May 25, 2021 at 2:14 PM Jean St-Laurent via NANOG 
> wrote:
>
>> I don’t believe that these companies are complicit at high level.
>>
>> My guess is that there are some business salesmen working there that
>> needs to fulfill their monthly quota of new clients.
>>
>>
>>
>> What is usually common, is that when face by a DDoS for the first time
>> without the  proper tooling, it sounds like it’s an impossible task to
>> solve. The knowledge on internet is pretty limited on the topic.
>>
>> It takes months and sometimes years to configure all the DDoS gates.
>> Rolland’s ppt is a nice place to start as it has valuable knowledge. It’s
>> just tough to figure out what is best for you.
>>
>>
>>
>> The truth is, it will be more beneficial to your organisation in the
>> medium/long term if you start learning and improving your DDoS defenses now
>> than to rely 100% on DDoS mitigators.
>>
>> These companies are fantastic when you protect slow assets like Credit
>> card transactions. The customer don’t really care if his transaction to
>> validate the CC takes 4 seconds instead of 3.
>>
>>
>>
>> In the end, DDoS mitigations is not more complex than what you are used
>> to do daily. Protect your routers, protect the control-plane, protect the
>> SSH lines, etc. It’s just a different kind of protections.
>>
>>
>>
>> Let me know if you need some advices or hints, because I’ve spent some
>> freaking long hours fighting them and together we have a better chance to
>> win and not pay ransom from blackmails.
>>
>> I don’t have all the answers on DDoS, but maybe I have the one that you
>> are looking for.
>>
>>
>>
>> The moment you become very resilient to DDoS attacks, your customers will
>> thank you and also support staff that will see the DDoS bounce like
>> mosquitoes on the windshield of your car at 90 Mph.
>>
>>
>>
>> Start learning now and start improving your DDoS. This won’t go away
>> anytime soon.
>>
>>
>>
>> Jean
>>
>>
>>
>>
>>
>> *From:* jim deleskie 
>> *Sent:* May 24, 2021 12:38 PM
>> *To:* Jean St-Laurent 
>> *Cc:* NANOG Operators' Group 
>> *Subject:* Re: DDoS attack with blackmail
>>
>>
>>
>> While I have no design to engage in over email argument over how much
>> latency people can actually tolerate, I will simply state that most people
>> have a very poor understanding of it and how much additional latency is
>> really introduced by DDoS mitigation.
>>
>>
>>
>> As for implying that DDoS mitigation companies are complicit or involved
>> in attacks, while not the first time i heard that crap it's pretty
>> offensive to those that work long hours for years dealing with the
>> garbage.  If you honestly believe anyone your dealing with is involved with
>> launching attacks you clearly have not done your research into potential
>> partners.
>>
>>
>>
>>
>>
>>
>>
>> On Sat., May 22, 2021, 11:20 a.m. Jean St-Laurent via NANOG, <
>> nanog@nanog.org> wrote:
>>
>> Some industries can’t afford that extra delay by DDoS mitigation vendors.
>>
>>
>>
>> The video game industry is one of them and there might be others that
>> can’t tolerate these extra ms. Telemedicine, video-conference, fintech, etc.
>>
>>
>>
>> As a side note, my former employer in video game was bidding for these
>> vendors offering DDoS protection. While bidding, we were hit with abnormal
>> patterns. As soon as we chose one vendors those very tricky DDoS patterns
>> stopped.
>>
>> I am not saying they are working on both side, but still the coincidence
>> was interesting. In the end, we never used them because they were not able
>> to perfectly block the threat without impacting all the others projects.
>>
>>
>>
>> I think these mitigators are nice to have as a very last resort. I
>> believe what is more important for Network Operators is: to be aware of
>> this, to be able to detect it, mitigate it and/or minimize the impact. It’s
>> like magic, where did that rabbit go?
>>
>>
>>
>> The art of war taught me everything there is to know about DDoS attacks
>> even if it was written some 2500 years ago.
>>
>>
>>
>> I suspect that the attack that impacted Baldur’s assets was a very easy
>> DDoS to detect and block, but can’t confirm.
>>
>>
>>
>> @Baldur: do you care to share some metrics?
>>
>>
>>
>> Jean
>>
>>
>>
>> *From:* NANOG  *On Behalf Of *Jean
>> St-Laurent via NANOG
>> *Sent:* May 21, 2021 10:52 AM
>> *To:* 'Lady Benjamin Cannon of Glencoe, ASCE' ; 'Baldur
>> Norddahl' 
>> *Cc:* 'NANOG Operators' Group' 
>> *Subject:* RE: DDoS attack with blackmail
>>
>>
>>
>> I also recommend book Art of War from Sun Tzu.
>>
>>
>>
>> All the answers to your questions are in that 

RE: AT Fiber Line / NOT MIS

[Dennis Burgess]

Called Cascaded Router configuration on The POS router they gave .. their 
support and their support “Supervisor” could not make it work.  I just did .. 
FUN.


[LTI-Full_175px]
Dennis Burgess, Mikrotik Certified Trainer
MTCNA, MTCRE, MTCWE, MTCTCE, MTCINE, MTCSE, HE IPv6 Sage, Cambium ePMP Certified
Author of "Learn RouterOS- Second Edition”
Link Technologies, Inc -- Mikrotik & WISP Support Services
Office: 314-735-0270  Website: 
http://www.linktechs.net
Create Wireless Coverage’s with www.towercoverage.com

From: Alex Conner 
Sent: Thursday, June 10, 2021 2:01 PM
To: Dennis Burgess 
Cc: TJ Trout ; nanog@nanog.org
Subject: Re: AT Fiber Line / NOT MIS

Yep; but even IP Passthrough, routed subnet, etc. all count as NAT sessions 
against the internal NAT table.

BTW, that's the feature you're looking for - routed subnet. That will pass your 
/26 to another network device over an RFC1918 subnet. The steps depend on what 
particular gateway hardware they have, but a quick Google of the gateway model 
and "routed subnet" should get you to the right spot. Assuming of course the 
other service limitations aren't a dealbreaker.

On Thu, Jun 10, 2021 at 2:54 PM Dennis Burgess 
mailto:dmburg...@linktechs.net>> wrote:
Ya not wishing to do NAT...
Sent from mobile device..


From: Alex Conner mailto:he...@codatory.com>>
Sent: Thursday, June 10, 2021 1:49:27 PM
To: TJ Trout mailto:t...@pcguys.us>>
Cc: Dennis Burgess mailto:dmburg...@linktechs.net>>; 
nanog@nanog.org 
mailto:nanog@nanog.org>>
Subject: Re: AT Fiber Line / NOT MIS

Bonus points, the small business fiber has extremely limited NAT session limits 
(depends on hardware, but not greater than 16,000 sessions) and everything 
counts. Cold loading CNN.com (an AT company) in a default config without an 
adblocker will use close to 3000, which will saturate and cause errors on some 
of their gateway hardware (NVG595). If you want to use it for any serious 
purpose, stick a tunnel out to a real connection.

On Thu, Jun 10, 2021 at 2:43 PM TJ Trout 
mailto:t...@pcguys.us>> wrote:
Yeah not going to happen on U-verse

On Thu, Jun 10, 2021 at 11:32 AM Dennis Burgess 
mailto:dmburg...@linktechs.net>> wrote:

Guess their broadband stuff☹





Dennis Burgess

Author of "Learn RouterOS- Second Edition”

Link Technologies, Inc -- Mikrotik & WISP Support Services

Office: 314-735-0270  Website: 
http://www.linktechs.net

Create Wireless Coverage’s with 
www.towercoverage.com

Need MikroTik Cloud Management: https://cloud.linktechs.net



From: TJ Trout mailto:t...@pcguys.us>>
Sent: Thursday, June 10, 2021 1:12 PM
To: Dennis Burgess mailto:dmburg...@linktechs.net>>
Cc: nanog@nanog.org
Subject: Re: AT Fiber Line / NOT MIS



call back, i dont think that's accurate. What is the specific product?



On Thu, Jun 10, 2021 at 7:25 AM Dennis Burgess 
mailto:dmburg...@linktechs.net>> wrote:

I have a ATT fiber line for a customer that has a 300/300 circuit, but its not 
a MIS they are telling me we cannot route a /26 (they have allocated) to my 
device behind it.  ☹  Any options?





Dennis Burgess

Mikrotik : Trainer, Network Associate, Routing Engineer, Wireless Engineer, 
Traffic Control Engineer, Inter-Networking Engineer, Security Engineer, 
Enterprise Wireless Engineer

Hurricane Electric: IPv6 Sage Level

Cambium: ePMP



Author of "Learn RouterOS- Second Edition”

Link Technologies, Inc -- Mikrotik & WISP Support Services

Office: 314-735-0270  Website: 
http://www.linktechs.net

Create Wireless Coverage’s with 
www.towercoverage.com

Need MikroTik Cloud Management: https://cloud.linktechs.net

How did we do today?

Re: Technical resources for Open Access Fiber Networks?

[Brandon Martin]

On 6/9/21 8:16 PM, Mark Leonard wrote:
Not so long ago I learned about Open Access Fiber Networks.  I'm quite 
curious about how these are actually implemented.  I'm able to find 
boatloads of marketing material and management-targeted boilerplate, but 
I've not yet been able to find any technical resources.


My first thoughts were:
* Are these just massive VPLS networks?
* Are they just giant L2 networks?

I can't imagine that either of the above would scale particularly well.

I'm looking for any books / papers / config guides / magic tomes / etc 
on the subject.


Can anyone point me in the right direction?


I think part of why you're not finding a lot of technical information is 
that things built under the name "open access network" come in all 
shapes, colors, and sizes.


Things I've seen:

* Fully open glass: Point-to-point fiber from central location(s) to 
each individual service point.  Providers co-lo at the central 
location(s) and bring their own backhaul to them (which the open network 
operator may offer turnkey separately) and buy usage of the fiber from 
the open network operator.  They can run whatever they want on it.  CPE 
is provided by the service provider.  Multiple strands can enable 
multiple service providers simultaneously at the same customer prem, but 
the number of fibers grows reeeally fast.


* Central split open PON: Each service point has one or two fibers to 
central split cabinets in the field, and service providers buy customer 
glass to the splitter cabinet, space in the splitter cabinet for 
passives, and backhaul glass to each cabinet in areas they want to 
serve.  They run whatever they want on it via co-location in central 
PoPs which need not be active for everyone in the facility (could be 
another layer of a hierarchical split), but the cost/availability of the 
baukhaul glass generally implies a PON architecture (but it could be 
e.g. WDM-PON since you can put whatever you want at the field split 
locations).  CPE is provided by the service provider.  Multiple strands 
between the field split and customer prem, if available, enables the 
customer to buy service from multiple providers with each provider 
having their own glass path and CPE.


* Open L2 access: Could be active-E, xPON, or some mix.  The open 
network operator hands off customer services on either a 
VLAN/VLL-per-customer basis or just adds customers to your VLAN/VPLS(s) 
on demand.  Service providers establish either a central NNI (open 
network operator handles regional backhaul) or co-locates with their own 
backhaul as above.  This architecture favors customers being able to buy 
service from multiple provides at once via a multi-port CPE ONT handled 
by the open network operator, but sometimes that responsibility gets 
delegated out to the service provider.  The open network operator is 
responsible for bandwidth management, etc.


* Private label of central services: There's fundamentally just one 
network (per type of service, e.g. IP, linear video, voice, etc.), and 
service providers just private label it.  They may or may not even get 
separate blocks of number resources.  The open network operator is 
really responsible for everything except maybe end-user billing.


Most people seem to be focusing on open L2 type systems as it provides 
the most rapid deployment of service with lots of "providers", but it 
requires you have a competent administrator of the open-access network 
which is often not the case.  I've also seen open glass (of both forms) 
especially with geographically larger deployments.  I've had munis and 
HOAs inquire about all types.  I'm not sure I've ever seen anyone 
actually deploy the private label only variety since it doesn't actually 
provide much beyond just directly selling the whole-stack service 
yourself, but it's been talked about.


A lot of DSL got deployed back in the day on a similar basis with 
service providers either co-locating in COs and buying dry pairs or 
re-selling someone else's DSL product (could be the ILEC or someone who 
already co-lo'd DSLAMs) with backhaul over ATM on a VPI-per-customer 
basis to a central NNI.


Linear video has proven to be problematic on them since it's 
difficult/expensive to get retrans rights for small geographic areas 
which can make it tough to get providers willing to come in and offer it 
without some exclusivity arrangements.  Thankfully, demand for linear 
video is rapidly dropping as people abandon it entirely or switch to 
over-the-top alternatives.


My general "favorite" where someone does want to do open access is the 
central split open PON model with ample excess fiber on both the 
backhaul and customer legs, but it is situational of course.

--
Brandon Martin

RE: Technical resources for Open Access Fiber Networks?

[Tony Wicks]

In New Zealand we have a nationwide government sponsored FTTH open access 
network based on GPON and XGSPON. There are local access companies (LFC or 
Local Fibre Company) that handover double tagged layer2 that the various 
service providers (RSP or Retail Service Provider) can either pick up 
themselves in each region or pay a third party to backhaul to where they need 
to get to. This has resulted in a very competitive market to the retail 
consumer (very low margin to the retail service provider, this has resulted in 
broadband often being a “loss leader” used to bundle other 
phone/power/entertainment services).  Technically each end user has an ONT 
provided by the LFC and the RSP leases a layer2 service on a per-port basis 
that is delivered double tagged at the service provider handover point. This 
means each 1gig or 10gig port on the ONT can be used to present a different RSP 
service to the end user if desired. The handover point (10G/100G with or 
without LAG) can provide 4096x4096 possible layer2 services to end user ports.

 

The end result of this is almost ubiquitous high quality 100/20, 1000/500 up to 
4000/4000 being available to the end user. Retail for an unlimited 1000/500 
service to the end user is about 70USD/month with 4000/4000 (XGSPON) being 
about $130USD/month. Here’s a speedtest from my primary home workstation - 
https://www.speedtest.net/my-result/d/f44bc96e-ec2d-4446-8f23-d32aa6282350 

 

I work for a company that provides backhaul from the various regions around the 
country to the various retail service providers. We take the double tagged LFC 
handovers and transport them over MPLS to where the various service providers 
want them delivered to. Normally we will hand them over triple tagged with the 
third tag added to represent each handover point and the first two tags being 
preserved from the LFC handover. This works pretty well overall.

 

 

 

From: NANOG  On Behalf Of Mark Leonard
Sent: Thursday, 10 June 2021 12:16 pm
To: North American Network Operators' Group 
Subject: Technical resources for Open Access Fiber Networks?

 

Hi NANOG,

 

Not so long ago I learned about Open Access Fiber Networks.  I'm quite curious 
about how these are actually implemented.  I'm able to find boatloads of 
marketing material and management-targeted boilerplate, but I've not yet been 
able to find any technical resources.

 

My first thoughts were:

* Are these just massive VPLS networks?

* Are they just giant L2 networks?

 

I can't imagine that either of the above would scale particularly well.

 

I'm looking for any books / papers / config guides / magic tomes / etc on the 
subject.

 

Can anyone point me in the right direction?

 

Thanks,

Mark

Re: AT Fiber Line / NOT MIS

[Alex Conner via NANOG]

Yep; but even IP Passthrough, routed subnet, etc. all count as NAT sessions
against the internal NAT table.

BTW, that's the feature you're looking for - routed subnet. That will pass
your /26 to another network device over an RFC1918 subnet. The steps depend
on what particular gateway hardware they have, but a quick Google of the
gateway model and "routed subnet" should get you to the right spot.
Assuming of course the other service limitations aren't a dealbreaker.

On Thu, Jun 10, 2021 at 2:54 PM Dennis Burgess 
wrote:

> Ya not wishing to do NAT...
>
> Sent from mobile device..
>
> --
> *From:* Alex Conner 
> *Sent:* Thursday, June 10, 2021 1:49:27 PM
> *To:* TJ Trout 
> *Cc:* Dennis Burgess ; nanog@nanog.org <
> nanog@nanog.org>
> *Subject:* Re: AT Fiber Line / NOT MIS
>
> Bonus points, the small business fiber has extremely limited NAT session
> limits (depends on hardware, but not greater than 16,000 sessions) and
> *everything *counts. Cold loading CNN.com (an AT company) in a default
> config without an adblocker will use close to 3000, which will saturate and
> cause errors on some of their gateway hardware (NVG595). If you want to use
> it for any serious purpose, stick a tunnel out to a real connection.
>
> On Thu, Jun 10, 2021 at 2:43 PM TJ Trout  wrote:
>
> Yeah not going to happen on U-verse
>
> On Thu, Jun 10, 2021 at 11:32 AM Dennis Burgess 
> wrote:
>
> Guess their broadband stuff☹
>
>
>
>
>
> *[image: LTI-Full_175px]*
>
> *Dennis Burgess*
>
>
> Author of "Learn RouterOS- Second Edition”
>
> *Link Technologies, Inc* -- Mikrotik & WISP Support Services
>
> *Office*: 314-735-0270  Website: http://www.linktechs.net
>
> Create Wireless Coverage’s with www.towercoverage.com
>
> Need MikroTik Cloud Management: https://cloud.linktechs.net
>
>
>
> *From:* TJ Trout 
> *Sent:* Thursday, June 10, 2021 1:12 PM
> *To:* Dennis Burgess 
> *Cc:* nanog@nanog.org
> *Subject:* Re: AT Fiber Line / NOT MIS
>
>
>
> call back, i dont think that's accurate. What is the specific product?
>
>
>
> On Thu, Jun 10, 2021 at 7:25 AM Dennis Burgess 
> wrote:
>
> I have a ATT fiber line for a customer that has a 300/300 circuit, but its
> not a MIS they are telling me we cannot route a /26 (they have allocated)
> to my device behind it.  ☹  Any options?
>
>
>
>
>
> *Dennis Burgess*
>
>
> * Mikrotik : **Trainer, Network Associate, Routing Engineer, Wireless
> Engineer, Traffic Control Engineer, Inter-Networking Engineer, Security
> Engineer, Enterprise Wireless Engineer*
>
> *Hurricane Electric: **IPv6 Sage Level*
>
> *Cambium: **ePMP*
>
>
>
> Author of "Learn RouterOS- Second Edition”
>
> *Link Technologies, Inc* -- Mikrotik & WISP Support Services
>
> *Office*: 314-735-0270  Website: http://www.linktechs.net
>
> Create Wireless Coverage’s with www.towercoverage.com
>
> Need MikroTik Cloud Management: https://cloud.linktechs.net
>
> *How did we do today?*
>
>
> 
>
>
>
>

Re: AT Fiber Line / NOT MIS

[Dennis Burgess]

Ya not wishing to do NAT...

Sent from mobile device..


From: Alex Conner 
Sent: Thursday, June 10, 2021 1:49:27 PM
To: TJ Trout 
Cc: Dennis Burgess ; nanog@nanog.org 
Subject: Re: AT Fiber Line / NOT MIS

Bonus points, the small business fiber has extremely limited NAT session limits 
(depends on hardware, but not greater than 16,000 sessions) and everything 
counts. Cold loading CNN.com (an AT company) in a default config without an 
adblocker will use close to 3000, which will saturate and cause errors on some 
of their gateway hardware (NVG595). If you want to use it for any serious 
purpose, stick a tunnel out to a real connection.

On Thu, Jun 10, 2021 at 2:43 PM TJ Trout 
mailto:t...@pcguys.us>> wrote:
Yeah not going to happen on U-verse

On Thu, Jun 10, 2021 at 11:32 AM Dennis Burgess 
mailto:dmburg...@linktechs.net>> wrote:

Guess their broadband stuff☹





[LTI-Full_175px]

Dennis Burgess

Author of "Learn RouterOS- Second Edition”

Link Technologies, Inc -- Mikrotik & WISP Support Services

Office: 314-735-0270  Website: 
http://www.linktechs.net

Create Wireless Coverage’s with 
www.towercoverage.com

Need MikroTik Cloud Management: https://cloud.linktechs.net



From: TJ Trout mailto:t...@pcguys.us>>
Sent: Thursday, June 10, 2021 1:12 PM
To: Dennis Burgess mailto:dmburg...@linktechs.net>>
Cc: nanog@nanog.org
Subject: Re: AT Fiber Line / NOT MIS



call back, i dont think that's accurate. What is the specific product?



On Thu, Jun 10, 2021 at 7:25 AM Dennis Burgess 
mailto:dmburg...@linktechs.net>> wrote:

I have a ATT fiber line for a customer that has a 300/300 circuit, but its not 
a MIS they are telling me we cannot route a /26 (they have allocated) to my 
device behind it.  ☹  Any options?





Dennis Burgess

Mikrotik : Trainer, Network Associate, Routing Engineer, Wireless Engineer, 
Traffic Control Engineer, Inter-Networking Engineer, Security Engineer, 
Enterprise Wireless Engineer

Hurricane Electric: IPv6 Sage Level

Cambium: ePMP



Author of "Learn RouterOS- Second Edition”

Link Technologies, Inc -- Mikrotik & WISP Support Services

Office: 314-735-0270  Website: 
http://www.linktechs.net

Create Wireless Coverage’s with 
www.towercoverage.com

Need MikroTik Cloud Management: https://cloud.linktechs.net

How did we do today?

Re: AT Fiber Line / NOT MIS

[Alex Conner via NANOG]

Bonus points, the small business fiber has extremely limited NAT session
limits (depends on hardware, but not greater than 16,000 sessions) and
*everything *counts. Cold loading CNN.com (an AT company) in a default
config without an adblocker will use close to 3000, which will saturate and
cause errors on some of their gateway hardware (NVG595). If you want to use
it for any serious purpose, stick a tunnel out to a real connection.

On Thu, Jun 10, 2021 at 2:43 PM TJ Trout  wrote:

> Yeah not going to happen on U-verse
>
> On Thu, Jun 10, 2021 at 11:32 AM Dennis Burgess 
> wrote:
>
>> Guess their broadband stuff☹
>>
>>
>>
>>
>>
>> *[image: LTI-Full_175px]*
>>
>> *Dennis Burgess*
>>
>>
>> Author of "Learn RouterOS- Second Edition”
>>
>> *Link Technologies, Inc* -- Mikrotik & WISP Support Services
>>
>> *Office*: 314-735-0270  Website: http://www.linktechs.net
>>
>> Create Wireless Coverage’s with www.towercoverage.com
>>
>> Need MikroTik Cloud Management: https://cloud.linktechs.net
>>
>>
>>
>> *From:* TJ Trout 
>> *Sent:* Thursday, June 10, 2021 1:12 PM
>> *To:* Dennis Burgess 
>> *Cc:* nanog@nanog.org
>> *Subject:* Re: AT Fiber Line / NOT MIS
>>
>>
>>
>> call back, i dont think that's accurate. What is the specific product?
>>
>>
>>
>> On Thu, Jun 10, 2021 at 7:25 AM Dennis Burgess 
>> wrote:
>>
>> I have a ATT fiber line for a customer that has a 300/300 circuit, but
>> its not a MIS they are telling me we cannot route a /26 (they have
>> allocated) to my device behind it.  ☹  Any options?
>>
>>
>>
>>
>>
>> *Dennis Burgess*
>>
>>
>> * Mikrotik : **Trainer, Network Associate, Routing Engineer, Wireless
>> Engineer, Traffic Control Engineer, Inter-Networking Engineer, Security
>> Engineer, Enterprise Wireless Engineer*
>>
>> *Hurricane Electric: **IPv6 Sage Level*
>>
>> *Cambium: **ePMP*
>>
>>
>>
>> Author of "Learn RouterOS- Second Edition”
>>
>> *Link Technologies, Inc* -- Mikrotik & WISP Support Services
>>
>> *Office*: 314-735-0270  Website: http://www.linktechs.net
>>
>> Create Wireless Coverage’s with www.towercoverage.com
>>
>> Need MikroTik Cloud Management: https://cloud.linktechs.net
>>
>> *How did we do today?*
>>
>>
>> 
>>
>>
>>
>>

Re: AT Fiber Line / NOT MIS

[TJ Trout]

Yeah not going to happen on U-verse

On Thu, Jun 10, 2021 at 11:32 AM Dennis Burgess 
wrote:

> Guess their broadband stuff☹
>
>
>
>
>
> *[image: LTI-Full_175px]*
>
> *Dennis Burgess*
>
>
> Author of "Learn RouterOS- Second Edition”
>
> *Link Technologies, Inc* -- Mikrotik & WISP Support Services
>
> *Office*: 314-735-0270  Website: http://www.linktechs.net
>
> Create Wireless Coverage’s with www.towercoverage.com
>
> Need MikroTik Cloud Management: https://cloud.linktechs.net
>
>
>
> *From:* TJ Trout 
> *Sent:* Thursday, June 10, 2021 1:12 PM
> *To:* Dennis Burgess 
> *Cc:* nanog@nanog.org
> *Subject:* Re: AT Fiber Line / NOT MIS
>
>
>
> call back, i dont think that's accurate. What is the specific product?
>
>
>
> On Thu, Jun 10, 2021 at 7:25 AM Dennis Burgess 
> wrote:
>
> I have a ATT fiber line for a customer that has a 300/300 circuit, but its
> not a MIS they are telling me we cannot route a /26 (they have allocated)
> to my device behind it.  ☹  Any options?
>
>
>
>
>
> *Dennis Burgess*
>
>
> * Mikrotik : **Trainer, Network Associate, Routing Engineer, Wireless
> Engineer, Traffic Control Engineer, Inter-Networking Engineer, Security
> Engineer, Enterprise Wireless Engineer*
>
> *Hurricane Electric: **IPv6 Sage Level*
>
> *Cambium: **ePMP*
>
>
>
> Author of "Learn RouterOS- Second Edition”
>
> *Link Technologies, Inc* -- Mikrotik & WISP Support Services
>
> *Office*: 314-735-0270  Website: http://www.linktechs.net
>
> Create Wireless Coverage’s with www.towercoverage.com
>
> Need MikroTik Cloud Management: https://cloud.linktechs.net
>
> *How did we do today?*
>
>
> 
>
>
>
>

RE: AT Fiber Line / NOT MIS

[Dennis Burgess]

Guess their broadband stuff☹


[LTI-Full_175px]
Dennis Burgess

Author of "Learn RouterOS- Second Edition”
Link Technologies, Inc -- Mikrotik & WISP Support Services
Office: 314-735-0270  Website: 
http://www.linktechs.net
Create Wireless Coverage’s with www.towercoverage.com
Need MikroTik Cloud Management: https://cloud.linktechs.net

From: TJ Trout 
Sent: Thursday, June 10, 2021 1:12 PM
To: Dennis Burgess 
Cc: nanog@nanog.org
Subject: Re: AT Fiber Line / NOT MIS

call back, i dont think that's accurate. What is the specific product?

On Thu, Jun 10, 2021 at 7:25 AM Dennis Burgess 
mailto:dmburg...@linktechs.net>> wrote:
I have a ATT fiber line for a customer that has a 300/300 circuit, but its not 
a MIS they are telling me we cannot route a /26 (they have allocated) to my 
device behind it.  ☹  Any options?


Dennis Burgess

Mikrotik : Trainer, Network Associate, Routing Engineer, Wireless Engineer, 
Traffic Control Engineer, Inter-Networking Engineer, Security Engineer, 
Enterprise Wireless Engineer
Hurricane Electric: IPv6 Sage Level
Cambium: ePMP

Author of "Learn RouterOS- Second Edition”
Link Technologies, Inc -- Mikrotik & WISP Support Services
Office: 314-735-0270  Website: 
http://www.linktechs.net
Create Wireless Coverage’s with 
www.towercoverage.com
Need MikroTik Cloud Management: https://cloud.linktechs.net
How did we do today?

Re: NAT devices not translating privileged ports

[Fernando Gont via NANOG]

Hi, Jean,

On Thu, 2021-06-10 at 08:23 -0400, Jean St-Laurent wrote:
> Let's start with this example. When I click sync my clock in windows,
> this happened. 
> 
> On the inside or Private side
> 08:15:07.434344 IP 192.168.254.205.123 > 13.86.101.172.123: NTPv3,
> Client, length 48
> 08:15:07.473681 IP 13.86.101.172.123 > 192.168.254.205.123: NTPv3,
> Server, length 48
> 
> You are indeed right that the client must use UDP port 123. Is the
> RFC saying must or should on the client SRC port? I'm not sure.

Section 9.1 ("Peer Process Variables") of [RFC5905] SAYS:

  dstport: UDP port number of the client, ordinarily the NTP port
  number PORT (123) assigned by the IANA.  This becomes the source
  port number in packets sent from this association.


That said, as noted in 
https://datatracker.ietf.org/doc/html/draft-ietf-ntp-port-randomization-06#section-5
 , other client implementations don't bind the local port to 123, and
hence assign an ephemeral port.



> But, on the Public, this happened.
> 08:15:07.434381 IP 192.2XX.XXX.58291 > 13.86.101.172.123: NTPv3,
> Client, length 48
> 08:15:07.473656 IP 13.86.101.172.123 > 192.2XX.XXX.58291: NTPv3,
> Server, length 48
> 
> // Public ip obfuscated. I know, it indeed starts with 192.2. It's
> EBOX in Canada.
> 
> What we see on the public side, is that a network device did a NAT
> translation of the SRC UDP port to 58921. My clock synced perfectly.
> 
> So your goal is to find the devices that don't follow this behaviour,
> right?

> No. The goal of our I-D is that NTP clients randomize their source
> port -- there's no need for clients to use port 123, and using that
> port on the client side has negative security implications.

Thanks,
-- 
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531

Re: AT Fiber Line / NOT MIS

[TJ Trout]

call back, i dont think that's accurate. What is the specific product?

On Thu, Jun 10, 2021 at 7:25 AM Dennis Burgess 
wrote:

> I have a ATT fiber line for a customer that has a 300/300 circuit, but its
> not a MIS they are telling me we cannot route a /26 (they have allocated)
> to my device behind it.  ☹  Any options?
>
>
>
>
>
> *[image: LTI-Full_175px]*
>
> *Dennis Burgess*
>
>
> * Mikrotik : **Trainer, Network Associate, Routing Engineer, Wireless
> Engineer, Traffic Control Engineer, Inter-Networking Engineer, Security
> Engineer, Enterprise Wireless Engineer*
>
> *Hurricane Electric: **IPv6 Sage Level*
>
> *Cambium: **ePMP*
>
>
>
> Author of "Learn RouterOS- Second Edition”
>
> *Link Technologies, Inc* -- Mikrotik & WISP Support Services
>
> *Office*: 314-735-0270  Website: http://www.linktechs.net
>
> Create Wireless Coverage’s with www.towercoverage.com
>
> Need MikroTik Cloud Management: https://cloud.linktechs.net
>
> *How did we do today?*
>
> [image: Gold Star]
> [image:
> Green Light]
> [image:
> Yellow Light]
> [image:
> Red Light]
> 
>
>
>

Re: irrd 4.1.2 deployed at NTT

[Randy Bush]

> this change means that NTT's IRR mirror service will now use RPKI
> Validated ROAs to filter out invalid IRR objects! This filtering
> strategy is similar to RIPE-731.
> 
> Creation of RPKI ROAs will trigger deletion of conflicting IRR
> objects, this helps clean up stale objects. Existing RPKI ROAs help
> prevent future creation of unauthorized IRR objects.

cool!

what stands between my current world and when i can remove my irrd
instance and when i can remove (which) objects from the ripe whois?

< psa >

15-20 years back, when designing early rpki deployment, folk wanted the
irr to be equally if not more authoritative than the rpki.  trust what
you are already familiar with.  some where downright rabid about irr /
whois rulz.

the pendulum swings.

while i confess to helping to create this rpki origin validation
thingie, i would warn that it is pretty rigid.  notice how many xnog
threads we see about broken dnssec or just dns meaning my.mtv is mot
reachable?  this is analogous, except it is at the routing layer.

recommended actions:

   get your roas correct and monitor their correctness

   use an external service which ensures your roa data are propagating
   correctly globally

   use reliable and correct relying party softweare; there is crap
   out there

   monitor your routers to ensure that they are getting current relying
   party data

   familiarize your noc and engs with a toolset to provide assurance
   of and debug all of the above

i am sure there are more things to do; and hope that wiser folk will
expand, comment, and correct.

randy

---
ra...@psg.com
`gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
signatures are back, thanks to dmarc header butchery

Re: A survey on BGP MRAI timer values in practice

[Adam Thompson]

My question at this point is, what slow global convergence?  When I (or any of 
my downstreams) adjusts a prefix, I nearly always see global propagation in 
well under 60 seconds.  Among networks where I can check, at least.
I understand it could be technically possible to see near-instantaneous global 
convergence in more like <5sec, but... on a global scale, neither I nor my 
customers care about the difference between 5s and 60s.  Do other people need 
<60s propagation?
-Adam

From: NANOG  on behalf of Mark 
Tinka 
Sent: June 10, 2021 02:36
To: nanog@nanog.org 
Subject: Re: A survey on BGP MRAI timer values in practice



On 6/10/21 08:26, Saku Ytti wrote:

> I don't understand the question, but the way I read the question it
> may be unanswerable even if I did understand it. As the reader would
> self-define negligible and well acceptable and answer yes/no based on
> the definition they used, which might be different to the definition
> writer intended.

It's possible we've become accustom to a slow, global BGP, due to a
perception of fragility (and complexity), which favours stability over
speed.

I suppose the size of the current BGP and the nature of the FSM it lends
itself to does some to account for those perceptions.

At a per-ISP level, it is not impossible to speed up (i)BGP convergence.
On a global scale, taking the least common denominator to allow for all
manner of network we don't know about, allowing the ship a wide turn in
BGP waters, at least on a perceptive level, seems like an unsigned
social agreement amongst autonomous systems.

Ultimately, I feel we aren't talking enough about this, and hopefully,
this thread gets us to that point.

Mark.

Re: NAT devices not translating privileged ports

[Blake Hudson]

On 6/10/2021 4:04 AM, Fernando Gont wrote:

Hi, Blake,

Thanks a lot for your comments! In-line


On Fri, 2021-06-04 at 11:13 -0500, Blake Hudson wrote:

Current gen Cisco ASA firewalls have logic so that if the connection
from a private host originated from a privileged source port, the
NAT
translation to public IP also uses an unprivileged source port (not
necessarily the same source port though).

Did you actaully mean "...also uses a *privileged port*"?


Yes I did. Thanks.


I found out that this behavior can cause issues when you have devices
on
your network that implement older DNS libraries or configs using UDP
53
as a source and destination port for their DNS lookups. Occasionally
the
source port gets translated to one that ISC BIND servers have in a
blocklist (chargen, echo, time, and a few others) and the query is
ignored. As I recall, this behavior is hard coded so patching and
recompiling BIND is required to work around it.

I forget what the older ASA behavior was. It may have been to leave
the
source port unchanged through the NAT process (I think this is what
you
mean by "not translated"). In that case the client doesn't implement
source port randomization and the NAT doesn't "upgrade" the
connection
to a random source port so I don't really see it as an issue.

The issue would be that if the port is not translated, and multiple
systems in the internal real of the NAT try to use the same privileged
port (say, 123) simultaneously, things wouldn't work.




Not quite. If multiple devices behind a NAT use SRC=123 & DST = 123 for 
connections, their connections will still work most of the time. First, 
if the connections are to different destinations there would be no NAT 
conflict. Second, if the connections occur at different times, there 
would be no NAT conflict. Third, if there was a NAT conflict (meaning 
connections using the same SRC port, DST port, and DST host at the same 
time) the NAT device would see this and would either adjust the 
translation to use a different SRC port (in which case the connection 
succeeds) or may drop/reject the connection (in which case the client 
would eventually retry).


So saying "things wouldn't work" or "you won't be able to have multiple 
NTP clients behind the same firewall" is not true. Saying that "the 
number of simultaneous connections is limited" when behind a NAT would 
be more accurate. _But this statement is true of any one-to-many NAT_. 
Most NTP clients utilize multiple NTP servers, often from a pool of 
available servers, and initiate connections rather infrequently so I do 
not expect this to be a problem in practice unless there are thousands 
of NTP clients behind a single NAT accessing a common NTP server (and 
that NAT does not do a good job of dealing with collisions).


I do, however, agree that clients should probably use ephemeral ports 
when making any outbound connections as this provides more entropy for 
NAT as well as for connection security. This extends to NTP.

AT Fiber Line / NOT MIS

[Dennis Burgess]

I have a ATT fiber line for a customer that has a 300/300 circuit, but its not 
a MIS they are telling me we cannot route a /26 (they have allocated) to my 
device behind it.  ☹  Any options?


[LTI-Full_175px]
Dennis Burgess

Mikrotik : Trainer, Network Associate, Routing Engineer, Wireless Engineer, 
Traffic Control Engineer, Inter-Networking Engineer, Security Engineer, 
Enterprise Wireless Engineer
Hurricane Electric: IPv6 Sage Level
Cambium: ePMP

Author of "Learn RouterOS- Second Edition”
Link Technologies, Inc -- Mikrotik & WISP Support Services
Office: 314-735-0270  Website: 
http://www.linktechs.net
Create Wireless Coverage’s with www.towercoverage.com
Need MikroTik Cloud Management: https://cloud.linktechs.net
How did we do today?
[Gold 
Star][Green
 
Light][Yellow
 
Light][Red
 
Light]

Technical resources for Open Access Fiber Networks?

[Mark Leonard]

Hi NANOG,

Not so long ago I learned about Open Access Fiber Networks.  I'm quite
curious about how these are actually implemented.  I'm able to find
boatloads of marketing material and management-targeted boilerplate, but
I've not yet been able to find any technical resources.

My first thoughts were:
* Are these just massive VPLS networks?
* Are they just giant L2 networks?

I can't imagine that either of the above would scale particularly well.

I'm looking for any books / papers / config guides / magic tomes / etc on
the subject.

Can anyone point me in the right direction?

Thanks,
Mark

RE: NAT devices not translating privileged ports

[Jean St-Laurent via NANOG]

Let's start with this example. When I click sync my clock in windows, this 
happened. 

On the inside or Private side
08:15:07.434344 IP 192.168.254.205.123 > 13.86.101.172.123: NTPv3, Client, 
length 48
08:15:07.473681 IP 13.86.101.172.123 > 192.168.254.205.123: NTPv3, Server, 
length 48

You are indeed right that the client must use UDP port 123. Is the RFC saying 
must or should on the client SRC port? I'm not sure.

But, on the Public, this happened.
08:15:07.434381 IP 192.2XX.XXX.58291 > 13.86.101.172.123: NTPv3, Client, length 
48
08:15:07.473656 IP 13.86.101.172.123 > 192.2XX.XXX.58291: NTPv3, Server, length 
48

// Public ip obfuscated. I know, it indeed starts with 192.2. It's EBOX in 
Canada.

What we see on the public side, is that a network device did a NAT translation 
of the SRC UDP port to 58921. My clock synced perfectly.

So your goal is to find the devices that don't follow this behaviour, right?

Jean


-Original Message-
From: Fernando Gont  
Sent: June 10, 2021 7:09 AM
To: j...@ddostest.me; nanog@nanog.org
Subject: Re: NAT devices not translating privileged ports

Hi, Jean,

On Thu, 2021-06-10 at 06:54 -0400, Jean St-Laurent via NANOG wrote:
> Hi Fernando,
> 
> NTP sounds simple but it could be very complex when you dig deep down 
> and/or get lost in details.
> Here are 2 things to consider:
> 
> 1. NTP clients can query NTP servers by using SRC UDP ports > 1024. 

This is indeed the case we're addressing. The NTP spec mandates srt port=123, 
even for client-to-server cases.

Re: Can't Port from a Particular Rate Center

[Jason Canady]

Another trick I've used is to use a separate number and forward the old 
number to the new.  Set the caller ID to the original number, test 911.  
You may want to run the 911 with the new number instead though.  With 
this setup, you can try porting again down the road, but at least you 
have a solution in the current time.


On 6/10/21 7:32 AM, Ray Orsini wrote:
If there's wireless you can always try porting to wireless. We do that 
in a few rate centers

OIT Website  
Ray Orsini​
Chief Executive Officer
OIT, LLC

	*305.967.6756 x1009*  	 | 		*305.571.6272* 



	*r...@oit.co*  	 | 	https://www.oit.co 
 	* www.oit.co* 


 oit.co/ray

Facebook 


LinkedIn 


Twitter 


YouTube 

*Headed to ASCII: Ohio on June 16th - 17th?Come meet the OITVOIP family!
​​Find your city and register for FREE using code "OIT" 
https://go.oit.co/ASCII2021* 



*From:* NANOG  on behalf of Peter 
Beckman 

*Sent:* Thursday, June 10, 2021 12:33:45 AM
*To:* Mike Hammett 
*Cc:* NANOG Operators' Group 
*Subject:* EXTERNAL: Re: Can't Port from a Particular Rate Center
CAUTION: This email originated from outside of the organization. Do 
not click links or open attachments unless you recognize the sender 
and know the content is safe. If you are unsure, please forward this 
email to the CSE team for review.



I had this happen to me recently.

Customer came in with a number that had very little coverage, but our
carrier had a 1,000 block in the same ratecenter, so we held out some 
hope.


Once we dug into it, the 1,000 block was designated for a different
"service offering" with the carrier. They were not offering portability in
that Ratecenter, despite having coverage, or even hardware or leased
hardware there.

So we had to send the customer off. There really were only about 5 
carriers

serving the Ratecenter, 3 of them wireless, one very local, and our
carrier.

If your carrier decides not to port a number, even when they seem to be
present in the ratecenter in question, they are not required by any law or
rule to port, AFAIK.

If a company will port in, the other carrier must (IMHO) port out. If not,
then you can't port. There may be some subtleties to that, but this is my
understanding.

Fun!

Beckman

On Wed, 9 Jun 2021, Mike Hammett wrote:

> I first asked on a list much more narrow in scope, but failing to get
> sufficient data points, I've expanded my scope.
>
> Assuming the number isn't held by someone exempt from porting, what 
would

> prevent someone from being able to port a number from a particular rate
> center in a LATA they have coverage in?
>
> We picked up a particular carrier for our out-of-area needs and the 
first

> thing we throw at them in a LATA we know they have coverage in, they
> can't do. They have a non-useful reason why. It doesn't appear to have
> moved to a state where they contacted the losing provider as the 
response

> was very fast, so my provider rejected the port, not theirs.
>
> When I started at this company (where we do our own porting), I made 
sure

> to port a bunch of numbers from all over our LATA to see what would
> happen. All successful. That seems to indicate that it doesn't matter
> which xLEC or tandem currently serves that number, it can move 
elsewhere.

>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com 
>
> Midwest-IX
> http://www.midwest-ix.com 
>
>

---
Peter Beckman Internet Guy
beck...@angryox.com http://www.angryox.com/ 
---

Re: EXTERNAL: Re: Can't Port from a Particular Rate Center

[Ray Orsini]

If there's wireless you can always try porting to wireless. We do that in a few 
rate centers


Ray Orsini
Chief Executive Officer
OIT, LLC
 305.967.6756 x1009 |  305.571.6272
 r...@oit.co |  www.oit.co
 oit.co/ray
Headed to ASCII: Ohio on June 16th - 17th? Come meet the OITVOIP family!
​​Find your city and register for FREE using code "OIT" 
https://go.oit.co/ASCII2021
From: NANOG  on behalf of Peter Beckman 

Sent: Thursday, June 10, 2021 12:33:45 AM
To: Mike Hammett 
Cc: NANOG Operators' Group 
Subject: EXTERNAL: Re: Can't Port from a Particular Rate Center

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe. If you are unsure, please forward this email to the CSE team for 
review.


I had this happen to me recently.

Customer came in with a number that had very little coverage, but our
carrier had a 1,000 block in the same ratecenter, so we held out some hope.

Once we dug into it, the 1,000 block was designated for a different
"service offering" with the carrier. They were not offering portability in
that Ratecenter, despite having coverage, or even hardware or leased
hardware there.

So we had to send the customer off. There really were only about 5 carriers
serving the Ratecenter, 3 of them wireless, one very local, and our
carrier.

If your carrier decides not to port a number, even when they seem to be
present in the ratecenter in question, they are not required by any law or
rule to port, AFAIK.

If a company will port in, the other carrier must (IMHO) port out. If not,
then you can't port. There may be some subtleties to that, but this is my
understanding.

Fun!

Beckman

On Wed, 9 Jun 2021, Mike Hammett wrote:

> I first asked on a list much more narrow in scope, but failing to get
> sufficient data points, I've expanded my scope.
>
> Assuming the number isn't held by someone exempt from porting, what would
> prevent someone from being able to port a number from a particular rate
> center in a LATA they have coverage in?
>
> We picked up a particular carrier for our out-of-area needs and the first
> thing we throw at them in a LATA we know they have coverage in, they
> can't do. They have a non-useful reason why. It doesn't appear to have
> moved to a state where they contacted the losing provider as the response
> was very fast, so my provider rejected the port, not theirs.
>
> When I started at this company (where we do our own porting), I made sure
> to port a bunch of numbers from all over our LATA to see what would
> happen. All successful. That seems to indicate that it doesn't matter
> which xLEC or tandem currently serves that number, it can move elsewhere.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
>

---
Peter Beckman  Internet Guy
beck...@angryox.com http://www.angryox.com/
---

Re: NAT devices not translating privileged ports

[Fernando Gont via NANOG]

Hi, Jean,

On Thu, 2021-06-10 at 06:54 -0400, Jean St-Laurent via NANOG wrote:
> Hi Fernando,
> 
> NTP sounds simple but it could be very complex when you dig deep down
> and/or get lost in details. 
> Here are 2 things to consider:
> 
> 1. NTP clients can query NTP servers by using SRC UDP ports > 1024. 

This is indeed the case we're addressing. The NTP spec mandates srt
port=123, even for client-to-server cases.



> In your case, it sounds like you want to achieve NTP server to NTP
> server, but you mention NTP clients behind NAT devices. 

Nope. We simply recommend to randomize the source port for client-to-
server cases.

So in the quoted section we make the case that requiring src port=123
clients doesnt really make sense:
1) if the NAT translates the port, the server won-t see src 123 anyway
2) if the NAT doesn't translate the port, you won't be able to ahve
multiple NTP clients behind the same firewall.



> Can you give us more details on what kind of communication you need
> here? From what I understand client to server should work just fine
> with any NAT devices. 
> 
> Maybe you meant multiple NTP servers behind the same NAT to external
> NTP servers

Please let me know if what I wrote above clarifies our intent.

Thanks!

Regards,
-- 
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531

RE: NAT devices not translating privileged ports

[Jean St-Laurent via NANOG]

Hi Fernando,

NTP sounds simple but it could be very complex when you dig deep down and/or 
get lost in details. 
Here are 2 things to consider:

1. NTP clients can query NTP servers by using SRC UDP ports > 1024. 
2. NTP servers cannot query/sync/communicate to  another NTP server when using 
SRC UDP port > 1024.

In short, server to server wants SRC and DST UDP 123.  The query and the 
response will be fully 123 when server to server.

In your case, it sounds like you want to achieve NTP server to NTP server, but 
you mention NTP clients behind NAT devices. 

Because multiple clients behind the same NAT devices should work. Multiple NTP 
servers behind the same NAT and wanting to use other NTP server *should* not 
work.

Can you give us more details on what kind of communication you need here? From 
what I understand client to server should work just fine with any NAT devices. 

Maybe you meant multiple NTP servers behind the same NAT to external NTP server?

Thanks
Jean

Re: NAT devices not translating privileged ports

[Fernando Gont via NANOG]

Hi, Bjørn,

On Thu, 2021-06-10 at 12:10 +0200, Bjørn Mork wrote:
> Fernando Gont via NANOG  writes:
> 
> > What has been reported to us is that some boxes do not translate
> > the
> > src port if it's a privileged port.
> > 
> > IN such scenarios, NTP implementations that always use src
> > port=123,
> > dst port=123 might be in trouble if there are multiple NTP clients
> > behind the same NAT device
> 
> This problem used to be very common for 500/udp.  Ref
> https://datatracker.ietf.org/doc/html/rfc3715#section-2.3

THanks a lot for the link! -- this is indeed a good read.  I'm curious
if there exists something similar for UDP/123?


FWIW, we have this IETF I-D on NTP port randomization: 
https://datatracker.ietf.org/doc/html/draft-ietf-ntp-port-randomization-06
 , which has this section on the same kind of behavior, but for the NTP
port:

 cut here 
3.4.  Effect on NAT devices

  Some NAT devices will not translate the source port of a packet when
  a privileged port number is employed.  In networks where such NAT
  devices are employed, use of the NTP well-known port for the client
  port will essentially limit the number of hosts that may successfully
  employ NTP client implementations.

  In the case of NAT devices that will translate the source port even
  when a privileged port is employed, packets reaching the external
  realm of the NAT will not employ the NTP well-known port as the local
  port, since the local port will normally be translated by the NAT
  device possibly, but not necessarily, with a random port.
 cut here 

So I'm trying to find some reference that documents such behavior for
the NTP case

Thanks!

Regards,
-- 
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531

Re: NAT devices not translating privileged ports

[Bjørn Mork]

Fernando Gont via NANOG  writes:

> What has been reported to us is that some boxes do not translate the
> src port if it's a privileged port.
>
> IN such scenarios, NTP implementations that always use src port=123,
> dst port=123 might be in trouble if there are multiple NTP clients
> behind the same NAT device

This problem used to be very common for 500/udp.  Ref
https://datatracker.ietf.org/doc/html/rfc3715#section-2.3


Bjørn

Re: NAT devices not translating privileged ports

[Fernando Gont via NANOG]

Hi, Jean,

On Fri, 2021-06-04 at 08:36 -0400, Jean St-Laurent wrote:
> I believe all devices will translate a privileged ports, but it won't
> translate to the same number on the other side. It will translate to
> an unprivileged port. Is it what you meant or really there are some
> devices that will not translate at all a privileged port?

What has been reported to us is that some boxes do not translate the
src port if it's a privileged port.

IN such scenarios, NTP implementations that always use src port=123,
dst port=123 might be in trouble if there are multiple NTP clients
behind the same NAT device

Thanks!

Regards,
--
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531

Re: NAT devices not translating privileged ports

[Fernando Gont via NANOG]

Hi, Blake,

Thanks a lot for your comments! In-line


On Fri, 2021-06-04 at 11:13 -0500, Blake Hudson wrote:
> Current gen Cisco ASA firewalls have logic so that if the connection 
> from a private host originated from a privileged source port, the
> NAT 
> translation to public IP also uses an unprivileged source port (not 
> necessarily the same source port though).

Did you actaully mean "...also uses a *privileged port*"?



> 
> I found out that this behavior can cause issues when you have devices
> on 
> your network that implement older DNS libraries or configs using UDP
> 53 
> as a source and destination port for their DNS lookups. Occasionally
> the 
> source port gets translated to one that ISC BIND servers have in a 
> blocklist (chargen, echo, time, and a few others) and the query is 
> ignored. As I recall, this behavior is hard coded so patching and 
> recompiling BIND is required to work around it.
> 
> I forget what the older ASA behavior was. It may have been to leave
> the 
> source port unchanged through the NAT process (I think this is what
> you 
> mean by "not translated"). In that case the client doesn't implement 
> source port randomization and the NAT doesn't "upgrade" the
> connection 
> to a random source port so I don't really see it as an issue. 

The issue would be that if the port is not translated, and multiple
systems in the internal real of the NAT try to use the same privileged
port (say, 123) simultaneously, things wouldn't work.



Thanks,
-- 
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531

Re: A survey on BGP MRAI timer values in practice

[Mark Tinka]

On 6/10/21 08:26, Saku Ytti wrote:


I don't understand the question, but the way I read the question it
may be unanswerable even if I did understand it. As the reader would
self-define negligible and well acceptable and answer yes/no based on
the definition they used, which might be different to the definition
writer intended.


It's possible we've become accustom to a slow, global BGP, due to a 
perception of fragility (and complexity), which favours stability over 
speed.


I suppose the size of the current BGP and the nature of the FSM it lends 
itself to does some to account for those perceptions.


At a per-ISP level, it is not impossible to speed up (i)BGP convergence. 
On a global scale, taking the least common denominator to allow for all 
manner of network we don't know about, allowing the ship a wide turn in 
BGP waters, at least on a perceptive level, seems like an unsigned 
social agreement amongst autonomous systems.


Ultimately, I feel we aren't talking enough about this, and hopefully, 
this thread gets us to that point.


Mark.

Re: A survey on BGP MRAI timer values in practice

[Saku Ytti]

On Wed, 9 Jun 2021 at 20:43, Randy Bush  wrote:

> are we confident that in the global context, not just within an isp,
> there is negligible, well acceptable, oscillation?

I don't understand the question, but the way I read the question it
may be unanswerable even if I did understand it. As the reader would
self-define negligible and well acceptable and answer yes/no based on
the definition they used, which might be different to the definition
writer intended.

-- 
  ++ytti