- NANOG - lists.nanog.org

Fwd: Re: The role of Internet governance in sanctions
by surfer＠mauigateway.com 10 Mar '22

10 Mar '22

Using a few emails... - otoh, i would likely close such meager services as i provide to russian - I think it is a colossal mistake to weaponize the Internet. - Keeping the rest of the internet as functional as possible It is not "Russia" doing this. It is the Russian government doing this to the dismay of many of the Russian people. 20,000+ have already left Russia over this. If we don't keep the internet up and functional as best we can and start to block or otherwise stop/slow the flow of traffic, it is not the gov't mules that suffer, rather it is the regular, everyday Russian population that suffers. Many (most?) of the regular Russian folks want access to the global internet for info that is not gov't controlled. They can't get that with TV, radio or print media, but they can get that with the internet until the gov't blocks it. So, my 'vote' is "keep the internet up" to the best of our abilities and block/slow no one as much as possible. scott

1 0

RE: WISPA (was Making Use of 240/4 NetBlock)
by Travis Garrison 10 Mar '22

10 Mar '22

I will be attending also. We should try to do a meetup of the NANOG members Thank you Travis Garrison -----Original Message----- From: NANOG <nanog-bounces+tgarrison=netviscom.com(a)nanog.org> On Behalf Of Dave Taht Sent: Wednesday, March 9, 2022 1:25 PM To: Tim Howe <tim.h(a)bendtel.com> Cc: NANOG <nanog(a)nanog.org> Subject: Re: V6 still not supported (was Making Use of 240/4 NetBlock) I am going to attend the WISPA conference in New Orleans next week. (anyone going)

4 3

Re: 202203090732.AYC Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: Making Use of 240/4 NetBlock)
by Abraham Y. Chen 10 Mar '22

10 Mar '22

Dear Mel & Bill: 0) Thank you for your kind advice. 1) To be honest, I am a bit of lost with multiple comments about my eMail Header at the same time. Especially, some seem not in agreement with the other. Rather than opening up a discussion thread, such as "eMail Header Rules" that for sure will distract us from the real topic on the table, I have sent a request to Valerie Wittkop (Program Director) for a copy of the "official" rules for me to follow. Regards, Abe (2022-03-09 23:13) On 2022-03-09 14:23, Abraham Y. Chen wrote: > On 2022-03-09 13:16, Mel Beckman wrote: >> Alternatively, just use BCC. There is no reason for you to tell us >> who else you want to hear what you say. There’s nothing wrong with >> CCing, and nothing in the rules against it, but your recipients may >> not appreciate you distributing their email addresses on this list, >> to which they are not a member. >> >> -mel beckman >> >>> On Mar 9, 2022, at 9:29 AM, William Herrin <bill(a)herrin.us> wrote: >>> >>> >>> Mr. Chen: >>> >>> Would you please stop changing the subject line with an added date >>> stamp every time you post? It fouls threaded email readers and is >>> most inconsiderate. >>> >>> In addition, I respectfully encourage you to trim the recipients to >>> just the mailnig list and the specific individual to whom you are >>> sending a reply. >>> >>> Thanks, >>> Bill Herrin >>> >>> >>> On Wed, Mar 9, 2022 at 9:19 AM William Herrin <bill(a)herrin.us> wrote: >>> >>> Mr. Chen: >>> >>> Would you please stop changing the subject line with an added >>> date stamp every time you post? It fouls threaded email readers >>> and is most inconsiderate. >>> >>> Thanks, >>> Bill Herrin >>> >>> >>> On Wed, Mar 9, 2022 at 9:09 AM Abraham Y. Chen >>> <aychen(a)avinta.com> wrote: >>> >>> Dear John: >>> >>> 1) Thanks for your comment on how eMail headers could be >>> used. >>> >>> Dear Bill: >>> >>> 2) I am glad that you agree that it should be a viable >>> discussion on making use of the 240/4 netblock, while >>> waiting for IPv6 to deliver its promises. >>> >>> 3) As to your question about where does IPv6 stand today >>> and where is it heading, I like to highlight a recent APNIC >>> blog that you may have read. It also appeared on CircleID. >>> After a long recount of the history, the author seems to >>> hint that 1995 may be the new starting point for looking >>> forward. >>> >>> https://blog.apnic.net/2022/02/21/another-year-of-the-transition-to-ipv6/?u… >>> <https://blog.apnic.net/2022/02/21/another-year-of-the-transition-to-ipv6/?u…> >>> >>> >>> https://circleid.com/posts/20220220-another-year-of-the-transition-to-ipv6 >>> >>> 4) We fully realize that the EzIP approach is quite >>> unorthodox. As such, we received numerous quick criticisms >>> in the past. With the proposal now put together, we do hope >>> colleagues on this list will take the time to review its >>> specifics. I look forward to comments and critiques on its >>> merits. >>> >>> Regards, >>> >>> >>> Abe (2022-03-09 12:08) >>> >>> >>> Message: 7 >>> Date: 8 Mar 2022 15:32:36 -0500 >>> From: "John Levine"<johnl(a)iecc.com> <mailto:johnl@iecc.com> >>> To:nanog@nanog.org >>> Subject: Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: >>> 202203071610.AYC Re: Making Use of 240/4 NetBlock) >>> Message-ID:<20220308203237.53E7038B1B83(a)ary.qy> <mailto:20220308203237.53E7038B1B83@ary.qy> >>> Content-Type: text/plain; charset=utf-8 >>> >>> It appears that Anne Mitchell<amitchell(a)isipp.com> <mailto:amitchell@isipp.com> said: >>> >>>>> Cc: NANOG<nanog(a)nanog.org> <mailto:nanog@nanog.org>, Greg Skinner<gregskinner0(a)icloud.com> <mailto:gregskinner0@icloud.com>, "Karandikar, Abhay"<Director(a)iitk.ac.in> <mailto:Director@iitk.ac.in>, Rama Ati >>>> <rama_ati(a)outlook.com> <mailto:rama_ati@outlook.com>, Bob Corner GMAIL<bobbiecorner(a)gmail.com> <mailto:bobbiecorner@gmail.com>, "Hsing, T. Russell"<tHsing(a)ieee.org> <mailto:tHsing@ieee.org>, "Chen, Henry C.J." >>>> <hcjchen(a)avinta.com> <mailto:hcjchen@avinta.com>, ST Hsieh<uschinaeetc(a)gmail.com> <mailto:uschinaeetc@gmail.com>, "Chen, Abraham Y."<AYChen(a)alum.mit.edu> <mailto:AYChen@alum.mit.edu> >>>> This is a whole lot of cc:s to people who aren't even part of this group/list. One wonders with this many cc:s, how many bcc:s there also were, and to whom. >>> >>> There are several thousand people on the NANOG list, and public web archives. I don't think this >>> is a useful question. >>> >>> FWIW, I also don't think that repurposing 240/4 is a good idea. To be useful it would require >>> that every host on the Internet update its network stack, which would take on the order of >>> a decade, to free up some space that would likely be depleted in a year or two. It's basically >>> the same amount of work as getting everything to work on IPv6. >>> >>> R's, >>> John >>> >>> >>> ------------------------------ >>> >>> Message: 8 >>> Date: Tue, 8 Mar 2022 13:11:58 -0800 >>> From: William Herrin<bill(a)herrin.us> <mailto:bill@herrin.us> >>> To: John Levine<johnl(a)iecc.com> <mailto:johnl@iecc.com> >>> Cc:"nanog(a)nanog.org" <mailto:nanog@nanog.org> <nanog(a)nanog.org> <mailto:nanog@nanog.org> >>> Subject: Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: >>> 202203071610.AYC Re: Making Use of 240/4 NetBlock) >>> Message-ID: >>> <CAP-guGVCXC_8H+wgriM=Vv0bqPg4+arw0pXhcQhh7rccrxVxEg(a)mail.gmail.com> <mailto:CAP-guGVCXC_8H+wgriM=Vv0bqPg4+arw0pXhcQhh7rccrxVxEg@mail.gmail.com> >>> Content-Type: text/plain; charset="UTF-8" >>> >>> On Tue, Mar 8, 2022 at 12:34 PM John Levine<johnl(a)iecc.com> <mailto:johnl@iecc.com> wrote: >>> >>>> FWIW, I also don't think that repurposing 240/4 is a good idea. To be useful it would require >>>> that every host on the Internet update its network stack, >>> >>> Hi John, >>> >>> That's incorrect and obviously so. While repurposing 240/4 as general >>> purpose Internet addresses might require that level of effort, other >>> uses such as local LAN addressing would only require the equipment on >>> that one lan to be updated -- a much more attainable goal. >>> >>> Reallocating 240/4 as unpurposed unicast address space would allow >>> some standards-compliant uses to become practical before others. A few >>> quite quickly. >>> >>> >>>> which would take on the order of >>>> a decade, to free up some space that would likely be depleted in a year or two. It's basically >>>> the same amount of work as getting everything to work on IPv6. >>> >>> Is it not past time we admit that we have no real idea what the >>> schedule or level of effort will be for making IPv6 ubiquitous? This >>> year it was more than last year and next year it'll probably be more >>> than this year. The more precise predictions all seem to have fallen >>> flat. >>> >>> Regards, >>> Bill Herrin >>> >>> >>> -- William Herrin bill(a)herrin.us https://bill.herrin.us/ >>> ------------------------------ >>> >>> >>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> >>> Virus-free. www.avast.com >>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> >>> >>> >>> >>> >>> -- >>> William Herrin >>> bill(a)herrin.us >>> <https://bill.herrin.us/> >>> https://bill.herrin.us/ >>> >>> >>> >>> -- >>> William Herrin >>> bill(a)herrin.us >>> <https://bill.herrin.us/> >>> https://bill.herrin.us/ > > -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

NANOG 85 Call for Presentations + More
by Nanog News 09 Mar '22

09 Mar '22

*NANOG 85: Call For Presentations * *Are you a top mind in the industry? *Do you have what it takes to spark our imagination, encourage dialogue, + drive new solutions to our greatest networking challenges? We are now accepting proposals for in-person or remote presentations at all sessions of NANOG 85 taking place in Montréal, QC, Canada on June 6 - 8, 2022. Presentations may cover current technologies, soon-to-be deployed technologies, and/or industry innovation. *Requested Topics: * June 6 is the 10 year anniversary of World IPv6 Launch Day! We are actively seeking talks about IPv6. Additionally, based on feedback from our survey results, we have seen numerous requests for the following topics: - Network Automation - Tutorials (IPv6, BGP, Segment Routing, DNS) - Security (developments in, problems/solutions, various protocols) Don’t wait! Presentation abstracts and draft slides should be submitted no later than *Monday, April 25, 2022.* *MORE INFO <https://www.nanog.org/program/call-presentations/>* *NANOG 84 Pictures Now Available* All the unforgettable moments of NANOG 84 are captured in the archives. View the full NANOG 84 photo album today. Download your favorite picture, share on social and tag us! #WeAreNANOG *NANOG 84 PHOTO ALBUM <https://www.flickr.com/photos/nanog/albums/with/72177720297019307>* *Monthly LinkedIn Poll Questions * *We Want Your Feedback!* *NANOG believes in community in its truest sense. * We want to continue the conversation with you. Therefore, we will be hosting monthly LinkedIn Polls to facilitate space for your feedback. Have a question you would like to be polled? Contact us today. Have you joined our thriving LinkedIn community page: NANOG — A Community-Moderated Group? Join now. <https://www.linkedin.com/groups/40718/> *FOLLOW US * <https://www.linkedin.com/company/nanog/posts/?feedView=all>

1 0

Re: 202203090732.AYC Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: Making Use of 240/4 NetBlock)
by William Herrin 09 Mar '22

09 Mar '22

Mr. Chen: Would you please stop changing the subject line with an added date stamp every time you post? It fouls threaded email readers and is most inconsiderate. In addition, I respectfully encourage you to trim the recipients to just the mailnig list and the specific individual to whom you are sending a reply. Thanks, Bill Herrin On Wed, Mar 9, 2022 at 9:19 AM William Herrin <bill(a)herrin.us> wrote: > Mr. Chen: > > Would you please stop changing the subject line with an added date stamp > every time you post? It fouls threaded email readers and is most > inconsiderate. > > Thanks, > Bill Herrin > > > On Wed, Mar 9, 2022 at 9:09 AM Abraham Y. Chen <aychen(a)avinta.com> wrote: > >> Dear John: >> >> 1) Thanks for your comment on how eMail headers could be used. >> >> Dear Bill: >> >> 2) I am glad that you agree that it should be a viable discussion on >> making use of the 240/4 netblock, while waiting for IPv6 to deliver its >> promises. >> >> 3) As to your question about where does IPv6 stand today and where is >> it heading, I like to highlight a recent APNIC blog that you may have read. >> It also appeared on CircleID. After a long recount of the history, the >> author seems to hint that 1995 may be the new starting point for looking >> forward. >> >> >> https://blog.apnic.net/2022/02/21/another-year-of-the-transition-to-ipv6/?u… >> >> >> >> https://circleid.com/posts/20220220-another-year-of-the-transition-to-ipv6 >> >> 4) We fully realize that the EzIP approach is quite unorthodox. As >> such, we received numerous quick criticisms in the past. With the proposal >> now put together, we do hope colleagues on this list will take the time >> to review its specifics. I look forward to comments and critiques on its >> merits. >> >> Regards, >> >> >> Abe (2022-03-09 12:08) >> >> >> Message: 7 >> Date: 8 Mar 2022 15:32:36 -0500 >> From: "John Levine" <johnl(a)iecc.com> <johnl(a)iecc.com> >> To: nanog(a)nanog.org >> Subject: Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: >> 202203071610.AYC Re: Making Use of 240/4 NetBlock) >> Message-ID: <20220308203237.53E7038B1B83(a)ary.qy> <20220308203237.53E7038B1B83(a)ary.qy> >> Content-Type: text/plain; charset=utf-8 >> >> It appears that Anne Mitchell <amitchell(a)isipp.com> <amitchell(a)isipp.com> said: >> >> Cc: NANOG <nanog(a)nanog.org> <nanog(a)nanog.org>, Greg Skinner <gregskinner0(a)icloud.com> <gregskinner0(a)icloud.com>, "Karandikar, Abhay" <Director(a)iitk.ac.in> <Director(a)iitk.ac.in>, Rama Ati >> >> <rama_ati(a)outlook.com> <rama_ati(a)outlook.com>, Bob Corner GMAIL <bobbiecorner(a)gmail.com> <bobbiecorner(a)gmail.com>, "Hsing, T. Russell" <tHsing(a)ieee.org> <tHsing(a)ieee.org>, "Chen, Henry C.J."<hcjchen(a)avinta.com> <hcjchen(a)avinta.com>, ST Hsieh <uschinaeetc(a)gmail.com> <uschinaeetc(a)gmail.com>, "Chen, Abraham Y." <AYChen(a)alum.mit.edu> <AYChen(a)alum.mit.edu> >> >> This is a whole lot of cc:s to people who aren't even part of this group/list. One wonders with this many cc:s, how many bcc:s there also were, and to whom. >> >> There are several thousand people on the NANOG list, and public web archives. I don't think this >> is a useful question. >> >> FWIW, I also don't think that repurposing 240/4 is a good idea. To be useful it would require >> that every host on the Internet update its network stack, which would take on the order of >> a decade, to free up some space that would likely be depleted in a year or two. It's basically >> the same amount of work as getting everything to work on IPv6. >> >> R's, >> John >> >> >> ------------------------------ >> >> Message: 8 >> Date: Tue, 8 Mar 2022 13:11:58 -0800 >> From: William Herrin <bill(a)herrin.us> <bill(a)herrin.us> >> To: John Levine <johnl(a)iecc.com> <johnl(a)iecc.com> >> Cc: "nanog(a)nanog.org" <nanog(a)nanog.org> <nanog(a)nanog.org> <nanog(a)nanog.org> >> Subject: Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: >> 202203071610.AYC Re: Making Use of 240/4 NetBlock) >> Message-ID: >> <CAP-guGVCXC_8H+wgriM=Vv0bqPg4+arw0pXhcQhh7rccrxVxEg(a)mail.gmail.com> <CAP-guGVCXC_8H+wgriM=Vv0bqPg4+arw0pXhcQhh7rccrxVxEg(a)mail.gmail.com> >> Content-Type: text/plain; charset="UTF-8" >> >> On Tue, Mar 8, 2022 at 12:34 PM John Levine <johnl(a)iecc.com> <johnl(a)iecc.com> wrote: >> >> FWIW, I also don't think that repurposing 240/4 is a good idea. To be useful it would require >> that every host on the Internet update its network stack, >> >> Hi John, >> >> That's incorrect and obviously so. While repurposing 240/4 as general >> purpose Internet addresses might require that level of effort, other >> uses such as local LAN addressing would only require the equipment on >> that one lan to be updated -- a much more attainable goal. >> >> Reallocating 240/4 as unpurposed unicast address space would allow >> some standards-compliant uses to become practical before others. A few >> quite quickly. >> >> >> >> which would take on the order of >> a decade, to free up some space that would likely be depleted in a year or two. It's basically >> the same amount of work as getting everything to work on IPv6. >> >> Is it not past time we admit that we have no real idea what the >> schedule or level of effort will be for making IPv6 ubiquitous? This >> year it was more than last year and next year it'll probably be more >> than this year. The more precise predictions all seem to have fallen >> flat. >> >> Regards, >> Bill Herrin >> >> >> -- >> William Herrinbill@herrin.ushttps://bill.herrin.us/ >> >> >> ------------------------------ >> >> >> >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. >> www.avast.com >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> >> <#m_1889185439734392099_m_-9011500040057407468_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> > > > -- > William Herrin > bill(a)herrin.us > <https://bill.herrin.us/> > https://bill.herrin.us/ > -- William Herrin bill(a)herrin.us <https://bill.herrin.us/> https://bill.herrin.us/

2 2

202203081821.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock
by Abraham Y. Chen 09 Mar '22

09 Mar '22

Hi, Stephen: 1) First, logistics: Since I have been waiting for the moderation of my first posting on NANOG, could I assume that you are sending me this personal eMail as a Moderator? 2) Perhaps the material provided in my writing was not sufficient, you seem to be expressing concerns from other perspectives. As concisely characterized by one of the "Internet fathers", the EzIP is an overlay network relative to the current Internet. As such, the EzIP deployment is pretty much independent of the hurdles that the current Internet equipment or convention may impose on it. That is, we can start the EzIP deployment leaving everything in the current Internet alone. This is because each EzIP deployment module, called RAN (Regional Area Network) is tethered via one IPv4 public address onto the Internet core. Since each RAN appears to be a private network, it can be set up according to its own requirements. That is, each RAN can make use of any desired IPv4 technology, while leaving others aside. As long as the packets on that single access path between the RAN and the Internet conform to the Internet conventions, the deployment of the EzIP proposal should work. 3) " ... if you plan on endpoint computers (such as those in homes) to use the 240/4 netblock. ... ": No, we do not. As presented by the RAN demonstration cited by the whitepaper, one of the primary criteria of the EzIP proposal is not to affect the current private network setups. Although, other than Windows OS based products, there are more and more IoTs do support 240/4 netblock. Even some Internet routers appear to do so, as well. 4) " ... DD-WRT project? ... ": EzIP does not have any ambition to alter or replace the existing Internet equipment in any sense. Fortunately, we can deploy our solution without such complication due to the overlay characteristics. Our main goal is to demonstrate that "*/there exists/*" one feasible configuration that can operate EzIP in parallel to the existing Internet for providing equivalent services. From such a skeletal reference, one can expand to larger deployments, as well as put on desired features and capabilities. For example, we have utilized OpenWrt 19.07.3 to demonstrate the feasibility of the EzIP scheme. Since the enabling technique is "disabling the program code that has been disabling the use of the 240/4 netblock", any other projects such as DD-WRT can replicate it just as well, if so inclined. 5) "... Firewalls ... NIST ... ": Since EzIP is only identifying the additional address resources from the "Reserve" and suggesting how to use it, I am not clear why high level functionalities such as security related firewall tasks get involved here. Do NIST Guidelines specify blocking any packet with the 240/4 netblock address? I failed to spot such. Since there is no natural division between the 240/4 netblock from the rest of IPv4 address pool, I can't see any reason to single this netblock out in the firewall related tasks anyway. Do you know the reason why? I would appreciate very much if you could elaborate your concerns. 6) By the way, the EzIP's RAN is actually very much the same as CG-NAT or CDN, architecturally. The only difference is that EzIP Project manged to identify a larger usable address pool enabling the practice of static addressing to simplify operation logistics, mitigate cyber insecurity, etc. I look forward to your thoughts. Regards, Abe (2022-03-09 23:28 EST) On 2022-03-08 13:08, Stephen Satchell wrote: > On 3/7/22 2:14 PM, Abraham Y. Chen wrote: >> In a nutshell, EzIP proposes to disable the program codes in >> current routers that have been disabling the use of the 240/4 >> NetBlock. The cost of this software engineering should be minimal. >> The EzIP deployment architecture is the same as that of the existing >> CG-NAT (Carrier Grade Network Address Translation). Consequently, >> there is no need to modify any hardware equipment. There is an online >> setup description (Reference II), called RAN (Regional Area Network), >> that demonstrates the feasibility of this approach. > > You have another surface that will need to dealt with if you plan on > endpoint computers (such as those in homes) to use the 240/4 netblock. > You will need to talk to the authors of firewall books and web sites > to update the examples to remove all-traffic blocks on 240/4. Then > individual administrations, not just ISP/Service-Provider, will need > to know to modify any home-brew firewalls to open all addresses except > 255.255.255.255 (and perhaps 240.0.0.0). > > That includes my publications about firewall configurations. > > If you haven't already, you will need to include makers of access > points and companies such as SonicWALL. Have you talked to pfSense? > DD-WRT project? UFW project? firewalld project? The Berkeley Packet > Filter project? How about authors of the NIST _Guidelines on > Firewalls and Firewall Policy_ publication > (https://www.govinfo.gov/content/pkg/GOVPUB-C13-f52fdee3827e2f5d903fa8b4b66d…) > > I wish you luck. And that's only the things I found in English. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

VoLTE and SRTP
by Michael Thomas 09 Mar '22

09 Mar '22

Hi, I was reading an article on why Russia hasn't taken out Ukraine's mobile networks and one of the premises was that they could use it to eavesdrop on calls. Depending on how old their infrastructure is, that doesn't make sense as I would assume that along with e2e SIP that they'd be using SRTP with the SRTP keys exchanged using DTLS which is my understanding of the way they are secured. My understanding could be wrong though, or either outdated, or not uniformly deployed. The other thing that's weird is that the same article says they want to keep it up so they can use their bandwidth too which strikes me as sort of a crazy assumption in a war, but that's not much of an operational issue. https://www.politico.com/news/2022/03/07/ukraine-phones-internet-still-work… Mike

5 6

Fwd: Upwork Suspending Operations in Russia and Belarus
by Callan Banner 08 Mar '22

08 Mar '22

Nanog to suspend work in Belarus and Russia. How do you all feel about this? Senseless antagonization or correctly applied pressure? ---------- Forwarded message --------- From: Hayden Brown, Upwork President & CEO <upwork(a)t.upwork.com> Date: Tue, Mar 8, 2022 at 12:51 PM Subject: Upwork Suspending Operations in Russia and Belarus To: <me(a)callan.im> A message from our CEO [image: Upwork] <https://link.t.upwork.com/ls/click?upn=VqS90m2f8fx8n-2F1K6AZcGXfLgLUteWUSWn…> Dear Callan, As the world’s work marketplace, Upwork’s mission is to create economic opportunities so people have better lives. In our more than 20 years of doing business, we have worked hard to bring our marketplace to more people, with the belief that when people have the ability to innovate their careers and work, they can reach their full potential. Russian President Vladimir Putin’s war against Ukraine has challenged our mission, values, and our operational ability to bring economic empowerment to those who seek it. *Upwork has begun suspending operations in Russia and Belarus and will take full effect by May 1, 2022.* The first step will be shutting down Upwork’s support for new business generation in Russia and Belarus. Over the next few days, freelancers and clients in Russia and Belarus will no longer be able to sign up for new accounts, initiate new contracts, and be visible in search. We honor the relationships that exist between our customers and recognize the swift adjustments that they will need to make as they process this announcement. As such, existing contracts with talent and clients in the region will remain open, with final billing due by May 1, 2022. We made this decision with the utmost consideration. From the beginning of the war, Upwork has been fervently working to support the safety, security, and well-being of our many team members in the region, as well as the business needs of our customers. We fully understand the significant impact this decision has on our Upwork community in Russia and Belarus, and we want these customers to know that if and when they are able to relocate to regions where we operate, we will be eager to support them in continuing their work on our platform. Additionally, should the geopolitical situation in Russia and Belarus change, we hope to be able to resume operations. We are heartbroken and horrified by the invasion of Ukraine. Upwork is concurrently working on measures – both immediate and rolling out soon – to further support Ukrainian freelancers and the Ukrainian community, including: • A $1 million donation to Direct Relief International <https://link.t.upwork.com/ls/click?upn=VqS90m2f8fx8n-2F1K6AZcGWG3CACp-2BoZj…> in support of the Ukrainian population. • Product enhancements to make it easier for Ukrainian freelancers to preserve the careers they have worked so hard to establish, whether or not they are currently able to work. • Programs to make it easier for clients to maintain their existing relationships with and provide financial assistance to talent in Ukraine. • A $100,000 matching program for donations from our own team members to aid in humanitarian relief in Ukraine. While we continue to navigate these crucial decisions and actions, you can view communications via our Community Resources Page <https://link.t.upwork.com/ls/click?upn=VqS90m2f8fx8n-2F1K6AZcGXdU-2Bum2rQJX…>, which we are updating frequently with new developments and FAQs. Our hearts and support go out to all those affected by this senseless aggression against Ukraine. We hope that a path to peace is ahead for Ukraine, and that we are able to bring our mission back to Russia and Belarus in the future. Sincerely, Hayden Brown President & CEO Upwork Notification settings <https://link.t.upwork.com/ls/click?upn=VqS90m2f8fx8n-2F1K6AZcGbPcv3ag7rzlW2…> | Privacy Policy <https://link.t.upwork.com/ls/click?upn=VqS90m2f8fx8n-2F1K6AZcGbPcv3ag7rzlW2…> | Contact Support <https://link.t.upwork.com/ls/click?upn=VqS90m2f8fx8n-2F1K6AZcGXNDCXp0TSAFOu…> 655 Montgomery Street, Suite 490, Dpt 17022, San Francisco, CA 94111 © 2022. Upwork® Inc. -- Callan Banner *Product Lead + Technical Advisor * phone: 7744021029 site: callan.im scheduling: *callan.im/calendar <http://callan.im/calendar>*

4 3

Spoofer Report for NANOG for Feb 2022
by CAIDA Spoofer Project 08 Mar '22

08 Mar '22

In response to feedback from operational security communities, CAIDA's source address validation measurement project (https://spoofer.caida.org) is automatically generating monthly reports of ASes originating prefixes in BGP for systems from which we received packets with a spoofed source address. We are publishing these reports to network and security operations lists in order to ensure this information reaches operational contacts in these ASes. This report summarises tests conducted within usa, can. Inferred improvements during Feb 2022: ASN Name Fixed-By 26554 US-SIGNAL 2022-02-01 32440 LONI 2022-02-09 19230 NANOG 2022-02-17 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Feb 2022: ASN Name First-Spoofed Last-Spoofed 54825 PACKET 2016-04-15 2022-02-26 19230 NANOG 2016-06-13 2022-02-17 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2022-02-24 20412 CLARITY-TELECOM 2016-09-30 2022-02-26 6181 FUSE-NET 2016-10-10 2022-02-28 22898 ATLINK 2016-12-16 2022-02-27 63296 AWBROADBAND 2017-09-01 2022-02-22 33452 RW 2018-09-19 2022-02-26 5078 ONENET-AS-1 2020-04-06 2022-02-05 398836 NP-NETWORKS 2021-03-12 2022-02-25 56207 Converge 2021-03-26 2022-02-20 22191 WILKES-COMM 2021-06-25 2022-02-24 63457 EMPIRE-CONNECT 2021-09-08 2022-02-24 212934 AS_POTVIN 2021-10-03 2022-02-28 22773 ASN-CXA-ALL-CCI-22773-RDC 2021-10-24 2022-02-23 394437 PSLIGHTWAVE 2021-12-02 2022-02-24 62887 WHITESKY-COMMUNICATIONS 2021-12-03 2022-02-02 54201 WEWORK-MANAGEMENT-LLC 2021-12-16 2022-02-25 7896 NU 2022-01-12 2022-02-24 396919 BLADE-GLOBAL 2022-01-16 2022-02-24 Further information for these tests where we received spoofed packets is available at: https://spoofer.caida.org/recent_tests.php?country_include=usa,can&no_block… Please send any feedback or suggestions to spoofer-info(a)caida.org

1 0

SATCOM terminals under attack in Europe
by Hank Nussbacher 08 Mar '22

08 Mar '22

https://www.reversemode.com/2022/03/satcom-terminals-under-attack-in-europe… -Hank

2 1