Fwd: [APRICOT-PC-Chairs] APRICOT 2022 Call for Presentations

[Mark Tinka]

FYI.

Mark.

 Forwarded Message 
Subject:[APRICOT-PC-Chairs] APRICOT 2022 Call for Presentations
Date:   Thu, 7 Oct 2021 21:16:43 +1000
From:   Philip Smith 
Reply-To:   APRICOT PC Chairs 
Organization:   Asia Pacific Regional Conference on Operational Technologies
To: ap...@apops.net
CC: APRICOT PC Chairs 



Hi everyone,

Please find below the call for presentations for APRICOT 2022! :-)

Best wishes,

philip
--

APRICOT 2022
21st February - 3rd March, Online
https://2022.apricot.net

CALL FOR PRESENTATIONS
==

The APRICOT 2022 Programme Committee is now seeking contributions for
Presentations and Tutorials for the APRICOT 2022 Conference.

We are looking for presenters who would:

- Offer a technical tutorial on an appropriate topic;
- Participate in the technical conference sessions as a speaker;
- Convene and chair panel sessions of relevant topics;

Please submit on-line at:

http://papers.apricot.net/user/login.php?event=142

Tutorials will take place during the week of 21st February.
Conference sessions and the Peering Forum will take place on the week
of 28th February. All APRICOT 2022 session times will be one hour
long, with up to four sessions scheduled per day.

CONFERENCE MILESTONES
-

Call for Papers Opens: Now
Initial Draft Programme: 6th December 2021
Final Deadline for Submissions: 31st January 2022
Final Program Published: 7th February 2022
Final Slides Received: 14th February 2022

*SLOTS ARE FILLED ON A FIRST COME, FIRST SERVED BASIS, REGARDLESS OF
PUBLISHED DEADLINES*

PROGRAMME CONTENT
-

The APRICOT Conference Programme consists of three parts, these being
Tutorials, the Peering Forum, and Conference Sessions.

Topics proposed must be relevant to Internet Operations and Technologies:

- IPv4 / IPv6 Routing and Operations
- Internet backbone operations
- Routing Security, including RPKI and MANRS
- Peering, Interconnects and IXPs
- Network Function Virtualisaton
- Network Automation/Programming
- Content Distribution Network technology & operations
- Research on Internet Operations and Deployment
- Network infrastructure security
- IPv6 deployment on fixed and Wireless/Cellular networks
- DNS / DNSSEC
- Access and Transport Technologies
- Content & Service Delivery and "Cloud Computing"


PEERING FORUM
-

Due to APRICOT 2022 being held online, the PC will only accept Peering
Personals prior to the event starting. Submissions must be of a
single slide listing the operator's PeeringDB entry. Please refer to
https://tinyurl.com/y46954n5 for how to create a successful Peering
Personal presentation.


CfP SUBMISSION
--

Draft slides for both tutorials and conference sessions MUST be
provided with CfP submissions otherwise the submission will be
rejected immediately. For work in progress, the most current
information available at time of submission is acceptable.

All draft and complete slides must be submitted in PDF format only.
Slides must be of original work, preferably not presented before at
other venues, with all company confidential marks removed.

Final slides are to be provided by the specified deadline for
publication on the APRICOT website.

Prospective presenters should note that the majority of speaking slots
will be filled well before the final submission deadline. The PC may,
at their discretion, retain a limited number of slots up to the final
submission deadline for presentations that are exceptionally timely,
important, or of critical operational importance. Every year we turn
away submissions, due to filling up all available programme slots
before the deadline. Presenters should endeavour to get material to
the PC sooner rather than later.

For any questions or concerns, please email the PC Chairs.

We look forward to receiving your presentation proposals.

Mark Tinka, Tugsorshikh Badarch & Marijana Novakovic
Co-Chairs, APRICOT 2022 Programme Committee
--

--
To unsubscribe from this group and stop receiving emails from it, send an email 
topc-chairs+unsubscr...@apricot.net.

Re: strange scam? email claiming to be from the fbi

[Sander Steffann]

> Quite a bit of discussion on the outages mailing list. It was an exploited 
> HTML form on the FBI site.

That's a flashback to the '90s :)
Sander

Re: strange scam? email claiming to be from the fbi

[Jay Hennigan]

Quite a bit of discussion on the outages mailing list. It was an 
exploited HTML form on the FBI site.


The text reminds me of the Turboencabulator data sheet.


Full body of the email:
Our intelligence monitoring indicates exfiltration of several of your 
virtualized clusters in a sophisticated chain attack. We tried to 
blackhole the transit nodes used by this advanced persistent threat 
actor, however there is a huge chance he will modify his attack with 
fastflux technologies, which he proxies trough multiple global 
accelerators. We identified the threat actor to be Vinny Troia, whom is 
believed to be affiliated with the extortion gang TheDarkOverlord, We 
highly recommend you to check your systems and IDS monitoring. Beware 
this threat actor is currently working under inspection of the NCCIC, as 
we are dependent on some of his intelligence research we can not 
interfere physically within 4 hours, which could be enough time to cause 
severe damage to your infrastructure.

Stay safe,
U.S. Department of Homeland Security | Cyber Threat Detection and 
Analysis | Network Analysis Group



--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

Re: strange scam? email claiming to be from the fbi

[Richard]

> Date: Monday, November 15, 2021 10:14:30 -0500
> From: Christopher Morrow 
>
> https://www.washingtonpost.com/nation/2021/11/14/fbi-hack-email-cyb
> erattack/
> 
> On Mon, Nov 15, 2021, 09:56 Glenn McGurrin wrote:
> 
>> I had a bit of an odd one this morning, I received two emails
>> through contacts listed in whois subject: "Urgent: Threat actor in
>> systems" from "e...@ic.fbi.gov".  I was all set to ignore them as
>> an odd bit of spam but did a quick check on the headers and was
>> surprised to see it had valid dkim and spf and was from an actual
>> FBI IP, queue real worry starting.  Luckily it looks like it was a
>> case of something being hacked on the FBI's end as calling they
>> immediately knew what I was calling about and said they had dealt
>> with the compromised equipment.  Further googling after that call
>> shows a few more reports of this ex.
>> https://twitter.com/spamhaus/status/1459450061696417792 and

Seems it wasn't an actual "intrusion" [into an fbi email system],
rather simply taking advantage of a very badly configured web site to
send out the messages [from an fbi machine].

Re: strange scam? email claiming to be from the fbi

[Bill Woodcock]

> On Nov 13, 2021, at 5:02 PM, Glenn McGurrin via NANOG  wrote:
> 
> I had a bit of an odd one this morning

It’s this:

https://www.engadget.com/fbi-email-server-hack-221052368.html

-Bill



signature.asc
Description: Message signed with OpenPGP

strange scam? email claiming to be from the fbi

[Glenn McGurrin via NANOG]

I had a bit of an odd one this morning, I received two emails through 
contacts listed in whois subject: "Urgent: Threat actor in systems" from 
"e...@ic.fbi.gov".  I was all set to ignore them as an odd bit of spam 
but did a quick check on the headers and was surprised to see it had 
valid dkim and spf and was from an actual FBI IP, queue real worry 
starting.  Luckily it looks like it was a case of something being hacked 
on the FBI's end as calling they immediately knew what I was calling 
about and said they had dealt with the compromised equipment.  Further 
googling after that call shows a few more reports of this ex. 
https://twitter.com/spamhaus/status/1459450061696417792 and 
https://www.newsweek.com/fbi-email-system-reportedly-hacked-fake-dhs-cyberattack-messages-1648966 
but I'd figured to mention it here so others don't get caught quite as 
off guard.


Best guess I can come up with is it's an attempt to ruin the person 
mentioned in the email's name and/or promote the name of the mentioned 
gang.  The specifics seem off for trying to get someone swatted given if 
you thought this was real what local agency would want to storm a 
federal operation with swat agents, and if you thought this was all 
fake, then you wouldn't go either.  That or create FUD for any other 
warnings issued and distract from something else going on.



Full body of the email:

Our intelligence monitoring indicates exfiltration of several of your 
virtualized clusters in a sophisticated chain attack. We tried to 
blackhole the transit nodes used by this advanced persistent threat 
actor, however there is a huge chance he will modify his attack with 
fastflux technologies, which he proxies trough multiple global 
accelerators. We identified the threat actor to be Vinny Troia, whom is 
believed to be affiliated with the extortion gang TheDarkOverlord, We 
highly recommend you to check your systems and IDS monitoring. Beware 
this threat actor is currently working under inspection of the NCCIC, as 
we are dependent on some of his intelligence research we can not 
interfere physically within 4 hours, which could be enough time to cause 
severe damage to your infrastructure.

Stay safe,
U.S. Department of Homeland Security | Cyber Threat Detection and 
Analysis | Network Analysis Group

Re: Validating multi-path in production?

[Tom Beecher]

It sounds like you want something like this:

https://github.com/facebookarchive/fbtracert

We have an internal tool that works on generally similar principles, works
pretty well.

( I have no relationship with Facebook; I just always remember their presos
on UDPinger and FBTracert from my first NANOG meeting for whatever reason.
:) )

On Sun, Nov 14, 2021 at 11:21 AM Adam Thompson 
wrote:

> The problem I'm looking to solve is the logical opposite, I think: I want
> to demonstrate that no links are malfunctioning in such a way that packets
> on a certain path are getting silently dropped.  Which has some "proving a
> negative" aspects to it, unfortunately.
> I think the only way I can demonstrate it is to determine that every
> single multi-path/hashed-member link is working, which is... hard.
> Especially if I need to deal with the combinatoric explosion - I *think* I
> can skip that part.
> -Adam
>
> Get Outlook for Android 
> --
> *From:* James Bensley 
> *Sent:* Sunday, November 14, 2021 5:29:25 AM
> *To:* Adam Thompson ; nanog 
> *Subject:* Re: Validating multi-path in production?
>
> On Fri, 12 Nov 2021 at 16:54, Adam Thompson 
> wrote:
>
> The best I've come up with so far is to have two test systems (typically
> VMs) that use adjacent IP addresses and adjacent MAC addresses, and test
> both inbound and outbound to/from those, blindly trusting/hoping that
> hashing algorithms will *probably* exercise both paths.
>
>
> If the goal is to test that traffic *is* being distributed across multiple
> links based on traffic headers, then you can definable roll your own. I
> think the problem is orchestrating it (feeding your topology data into the
> tool, running the tool, getting the results out, and interpreting the
> results etc).
>
> A coupe of public examples:
> https://github.com/facebookarchive/UdpPinger
> https://www.youtube.com/watch?v=PN-4JKjCAT0
>
> If you do roll your own, you need to taylor the tests to your topology and
> your equipment. For example, you can have two VMs as you mentioned, each at
> opposite ends of the network. Then, if your network uses a 5-tuple for ECMP
> inside the core for example, you could send many flows between the two VMs,
> rotating the sauce port for example, to ensure all links in a LAG or all
> ECMP paths are used.
>
> It's tricky to know the hashing algo for every type of device you have in
> your network, and for each traffic type for each device type, if you have a
> multi vendor network. Also, if your network carries a mix of IPv4, IPv6,
> PPP, MPLS L3 VPNs, MPLS L2 VPNs, GRE, GTP, IPSEC, etc. The number of
> permutations of tests you need to run and the result sets you need to
> parse, grows very rapidly.
>
> Cheers,
> James.
>