Amprnet? (was Re: [anti-abuse-wg] Yet another BGP hijacking towards AS16509)

[Ellenor Agnes Bjornsdottir]

Wasn't 44/8 the space for AMPRNet?

I looked it up and they sold part of it to Amazon. Ok. Got it.

Possible that a potential highjack could be a good faith radio ham who
hasn't somehow been updated on the sale of that space? Or more likely to
be a malicious highjack?

On 8/23/22 02:05, Siyuan Miao wrote:

Amazon was only announcing 44.224.0.0/11  at first.

https://bgp.tools/prefix/44.235.216.0/24

On Tue, Aug 23, 2022 at 4:03 AM Ronald F. Guilmette
 wrote:

In message
,
Siyuan Miao  wrote:

>Hjacking didn't last too long. AWS started announcing a more specific
>announcement to prevent hijacking around 3 hours later. Kudos to
Amazon's
>security team :-)

Sorry.  I'm missing something here.  If the hijack was of
44.235.216.0/24 , then
how did AWS propagate a "more specific" than that?


Regards,
rfg

--

To unsubscribe from this mailing list, get a password reminder, or
change your subscription options, please visit:
https://lists.ripe.net/mailman/listinfo/anti-abuse-wg

Re: IPv6 on Lumen/CL

[Mel Beckman]

You should get a status response within 24 hours. I would call in to the 
support hotline, (800) 829-0420, and ask for a status update.

-mel via cell

> On Aug 29, 2022, at 4:03 PM, Nathan Anderson  wrote:
> 
> We have a circuit on AS209 that was originally provisioned v4-only.  I'm now 
> trying to get Lumen to turn v6 up on it.  How long does this typically take?  
> I've had a configuration ticket open for nearly 3 biz days now with no 
> movement (or even acknowledgement).  For anybody who has gone through this 
> with them, is this unusual or nah?
> 
> When they do get around to it, what can I expect in terms of how they will 
> prefer to set this up?  Separate BGP session running over v6 itself, or 
> modify existing session to have it also carry v6 NLRIs?
> 
> Thanks,
> 
> -- Nathan

IPv6 on Lumen/CL

[Nathan Anderson]

We have a circuit on AS209 that was originally provisioned v4-only.  I'm now 
trying to get Lumen to turn v6 up on it.  How long does this typically take?  
I've had a configuration ticket open for nearly 3 biz days now with no movement 
(or even acknowledgement).  For anybody who has gone through this with them, is 
this unusual or nah?

When they do get around to it, what can I expect in terms of how they will 
prefer to set this up?  Separate BGP session running over v6 itself, or modify 
existing session to have it also carry v6 NLRIs?

Thanks,

-- Nathan

Re: VZ FIOS and Intel TCP IPv6 Checksum Offload problems

[Niels Bakker]

* br...@2mbit.com (Brie) [Mon 29 Aug 2022, 19:38 CEST]:

On 8/29/22 10:59 AM, Christopher Morrow wrote:
Uhm, this includes various versions of the intel pro 1000 card... 
so that's a TON of gear, to include like lenovo laptops, for 
instance. I'd wager that this is super common in the field.

The PDF in the download says;
  "Products Affected: All 1gbe and 10gbe intel ethernet controllers"


So I keep seeing this being pushed as a problem with clients...  but 
isn't it the ONT that is bugged out and appending the extra data 
after the checksum is already there (as Bill Herrin points out)?


I know it's asking a lot to expect networking equipment vendors to 
fix their gear, but...


Unless I'm totally not understanding the bug, which is entirely (and 
likely).


Here's my speculation on what was happening at Casa Sean.

The Ethernet frame has a length header. The IP frame has a length 
header. Ideally, the IP frame fits completely into the Ethernet frame, 
leaving room for the other required Ethernet bits but nothing more.


I vaguely recall there being some equipment that interpreted the 
minimum MTU requirement in IPv6 as meaning that there was a minimum 
packet size, not a minimum for the *maximum* packet size. Perhaps the 
fiber NTU padded the Ethernet frame up to the minimum MTU, sending 
along a bunch of junk bytes, without otherwise touching the IP packet.


The NIC would then perhaps forget that there were a bunch of junk 
bytes attached to the end of the frame beyond where the IP packet 
would end, and calculate the Ethernet checksum based on the IP packet 
length header, discarding otherwise valid frames as a result.


I've had my own run-ins over the years with supposed checksum 
offloading absolutely not happening on other brands, so implementation 
errors appear to be relatively common.



-- Niels.

Re: VZ FIOS and Intel TCP IPv6 Checksum Offload problems

[Brie]

On 8/29/22 10:59 AM, Christopher Morrow wrote:

Uhm, this includes various versions of the intel pro 1000 card... so
that's a TON of gear,
to include like lenovo laptops, for instance. I'd wager that this is
super common in the field.
The PDF in the download says;
   "Products Affected: All 1gbe and 10gbe intel ethernet controllers"



So I keep seeing this being pushed as a problem with clients...  but 
isn't it the ONT that is bugged out and appending the extra data after 
the checksum is already there (as Bill Herrin points out)?


I know it's asking a lot to expect networking equipment vendors to fix 
their gear, but...


Unless I'm totally not understanding the bug, which is entirely (and 
likely).



--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

Re: VZ FIOS and Intel TCP IPv6 Checksum Offload problems

[Christopher Morrow]

On Mon, Aug 29, 2022 at 12:00 PM Sean Donelan  wrote:
>
> On Sat, 27 Aug 2022, Michael Thomas wrote:
> >> In some situations where a client machine is connected via some specific
> >> Optical Network Terminals (ONTs), and data is appended after the packet
> >> checksum, the network adapter can drop receive packets when using TCP-IPv6
> >> Checksum Offload for receive traffic.
> >>
> >
> > My reaction is "offload from what"? Isn't this all done in silicon?
>
> Because the interoperability flaw is in silicon, it can't be easily fixed
> in either the legacy wired Intel ethernet controller or fiber ONT.  Would
> need to replace the hardware to fix the silicon.
>
> Need to disable the hardware IPv6 TCP checksum offload, so its not mangled
> or dropped at the silicon layers anymore.
>
> Its annoyingly intermittent and not visible with client-based Wireshark
> because the corruption occurs in the hardware controller.

Uhm, this includes various versions of the intel pro 1000 card... so
that's a TON of gear,
to include like lenovo laptops, for instance. I'd wager that this is
super common in the field.
The PDF in the download says;
  "Products Affected: All 1gbe and 10gbe intel ethernet controllers"

One wonders if this is a case of the 'mac addresses that start with 4
or 6 fail' problem?
(the pdf has zero words about what the actual problem is)

Re: VZ FIOS and Intel TCP IPv6 Checksum Offload problems

[Sean Donelan]

On Sat, 27 Aug 2022, Michael Thomas wrote:
In some situations where a client machine is connected via some specific 
Optical Network Terminals (ONTs), and data is appended after the packet 
checksum, the network adapter can drop receive packets when using TCP-IPv6 
Checksum Offload for receive traffic.




My reaction is "offload from what"? Isn't this all done in silicon?


Because the interoperability flaw is in silicon, it can't be easily fixed 
in either the legacy wired Intel ethernet controller or fiber ONT.  Would 
need to replace the hardware to fix the silicon.


Need to disable the hardware IPv6 TCP checksum offload, so its not mangled 
or dropped at the silicon layers anymore.


Its annoyingly intermittent and not visible with client-based Wireshark 
because the corruption occurs in the hardware controller.

Re: email spam

[Nick Boyce]

> especially as it's *known* that email is not a reliable method of 
> communication

That's the problem - it is *not* known by most ordinary folks that
email is not reliable.  They all think it *is* reliable.

Nick


On Wed, 24 Aug 2022 at 17:34, Anne Mitchell  wrote:
>
>
>
> > On Aug 23, 2022, at 8:52 PM, Suresh Ramasubramanian  
> > wrote:
> >
> > If you have something business critical, let alone anything that affects 
> > child safety, pick up a phone and call, or send an officer over to the 
> > school.
>
> 100%.  Belt and suspender approach.  If between 2020 and 2022 any child was 
> actually harmed by the guy, their parents are going to have a good lawsuit 
> (which sucks, because it would be much better to have no harmed child, of 
> course, but in my _academic_ opinion (i.e. this is not legal advice) the PD 
> was really, *really* negligent here, especially as it's *known* that email is 
> not a reliable method of communication, and if you aren't requiring an 
> acknowledgement that's on *you*).
>
> --
> Anne P. Mitchell, Attorney at Law
> CEO Institute for Social Internet Public Policy
> Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
> Author: The Email Deliverability Handbook
> Board of Directors, Denver Internet Exchange
> Dean Emeritus, Cyberlaw & Cybersecurity, Lincoln Law School
> Prof. Emeritus, Lincoln Law School
> Chair Emeritus, Asilomar Microcomputer Workshop
> Counsel Emeritus, eMail Abuse Prevention System (MAPS)
>