Re: Strange IPSEC traffic
On Nov 14, 2023, at 00:12, Shawn L via NANOG wrote: The destination address is always one of our customer's ip addresses. Attackers will sometimes use synthetic ESP, AH, GRE, or other protocols in DDoS attacks, because organizations often only think about TCP/UDP/ICMP in terms of ACLs, DDoS defense mechanisms, etc. Roland Dobbins
Re: Am I the only one who thinks this is disconcerting?
It can’t be legacy space, there is no such thing in IPv6. Legacy status only refers to IPv4 blocks that were issued by the predecessors to the current registry system and have not yet been placed under RIR contract. Owen > On Nov 13, 2023, at 12:57, Matt Corallo wrote: > > I'd be very curious to see a lawsuit over an IP hijack that isn't interfering > with the operation of any of Cogent's services and is restoring service to > HE's customers. Doubly so if they prepend aggressively to avoid it being a > preferred path (Cogent currently announces a /48 for the C root server, and I > assume there's ~nothing else in that block, but dunno). > > IANAL and really have no idea what the basis for that would be? I guess if > its legacy space you might argue its property and theft? > > Matt > > On 11/13/23 12:38 PM, Ryan Hamel wrote: >> Matt, >> Why would HE hijack Cogent's IP space? That would end in a lawsuit and >> potentially even more de-peering between them. >> Ryan Hamel >> >> *From:* NANOG on behalf of Matt >> Corallo >> *Sent:* Monday, November 13, 2023 11:32 AM >> *To:* Bryan Fields ; nanog@nanog.org >> *Subject:* Re: Am I the only one who thinks this is disconcerting? >> Caution: This is an external email and may be malicious. Please take care >> when clicking links or opening attachments. >> On 11/8/23 2:23 PM, Bryan Fields wrote: >>> On 11/8/23 2:25 PM, o...@delong.com wrote: Seems irresponsible to me that a root-server (or other critical DNS provider) would engage in a peering war to the exclusion of workable DNS. >>> >>> I've brought this up before and the root servers are not really an IANA >>> function IIRC. There's not >>> much governance over them, other than what's on root-servers.org. I think >>> a case could be made that >>> C is in violation of the polices on that page and RFC 7720 section 3. >>> >>> Basically none of the root servers want to change this and thus it's never >>> going to change. DNS >>> will fail and select another to talk to, and things will still work. >> At what point does HE just host a second C root and announce the same IPv6s? >> Might irritate Cogent, >> but its not more "bad" than Cogent failing to uphold the requirements for >> running a root server. >> Matt
Re: Am I the only one who thinks this is disconcerting?
On 11/13/23 12:57 PM, Matt Corallo wrote: I'd be very curious to see a lawsuit over an IP hijack that isn't interfering with the operation of any of Cogent's services and is restoring service to HE's customers. Doubly so if they prepend aggressively to avoid it being a preferred path (Cogent currently announces a /48 for the C root server, and I assume there's ~nothing else in that block, but dunno). IANAL and really have no idea what the basis for that would be? I guess if its legacy space you might argue its property and theft? Oh, duh, we're talking about v6, no such thing as legacy. I guess ARIN might have something to say, but its definitely a questionable case to care about. Let them hash it out, for all ARIN should care. Matt On 11/13/23 12:38 PM, Ryan Hamel wrote: Matt, Why would HE hijack Cogent's IP space? That would end in a lawsuit and potentially even more de-peering between them. Ryan Hamel *From:* NANOG on behalf of Matt Corallo *Sent:* Monday, November 13, 2023 11:32 AM *To:* Bryan Fields ; nanog@nanog.org *Subject:* Re: Am I the only one who thinks this is disconcerting? Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. On 11/8/23 2:23 PM, Bryan Fields wrote: On 11/8/23 2:25 PM, o...@delong.com wrote: Seems irresponsible to me that a root-server (or other critical DNS provider) would engage in a peering war to the exclusion of workable DNS. I've brought this up before and the root servers are not really an IANA function IIRC. There's not much governance over them, other than what's on root-servers.org. I think a case could be made that C is in violation of the polices on that page and RFC 7720 section 3. Basically none of the root servers want to change this and thus it's never going to change. DNS will fail and select another to talk to, and things will still work. At what point does HE just host a second C root and announce the same IPv6s? Might irritate Cogent, but its not more "bad" than Cogent failing to uphold the requirements for running a root server. Matt
Re: Am I the only one who thinks this is disconcerting?
I'd be very curious to see a lawsuit over an IP hijack that isn't interfering with the operation of any of Cogent's services and is restoring service to HE's customers. Doubly so if they prepend aggressively to avoid it being a preferred path (Cogent currently announces a /48 for the C root server, and I assume there's ~nothing else in that block, but dunno). IANAL and really have no idea what the basis for that would be? I guess if its legacy space you might argue its property and theft? Matt On 11/13/23 12:38 PM, Ryan Hamel wrote: Matt, Why would HE hijack Cogent's IP space? That would end in a lawsuit and potentially even more de-peering between them. Ryan Hamel *From:* NANOG on behalf of Matt Corallo *Sent:* Monday, November 13, 2023 11:32 AM *To:* Bryan Fields ; nanog@nanog.org *Subject:* Re: Am I the only one who thinks this is disconcerting? Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. On 11/8/23 2:23 PM, Bryan Fields wrote: On 11/8/23 2:25 PM, o...@delong.com wrote: Seems irresponsible to me that a root-server (or other critical DNS provider) would engage in a peering war to the exclusion of workable DNS. I've brought this up before and the root servers are not really an IANA function IIRC. There's not much governance over them, other than what's on root-servers.org. I think a case could be made that C is in violation of the polices on that page and RFC 7720 section 3. Basically none of the root servers want to change this and thus it's never going to change. DNS will fail and select another to talk to, and things will still work. At what point does HE just host a second C root and announce the same IPv6s? Might irritate Cogent, but its not more "bad" than Cogent failing to uphold the requirements for running a root server. Matt
Re: Appropriate venue to find out about the state of art of spear phishing defense?
On 11/13/23 12:29 PM, Mel Beckman wrote: We use KnowBe4.com's user training. That's really the only way you can fight this, since its a human problem, not a technical one. These guys provide fully automated, AI based (well, who knows what that means) simulated phishing attacks, largely to give users real-world practical experience detecting and fending off attacks. You get a report card on each users to, so you know where the weaknesses are in your staff knowledge. Their training regimen includes some pretty good self-guided instructional videos. DMARC, SPF, digitally-signed emails, encryption, none of that matters if a user can be tricked into letting the crooks in the front door. I think that both are needed, to be honest. The signatures can be a tool in the user's arsenal but if they are clueless and gullible there isn't much you can do about that. Mike
Re: Am I the only one who thinks this is disconcerting?
Matt, Why would HE hijack Cogent's IP space? That would end in a lawsuit and potentially even more de-peering between them. Ryan Hamel From: NANOG on behalf of Matt Corallo Sent: Monday, November 13, 2023 11:32 AM To: Bryan Fields ; nanog@nanog.org Subject: Re: Am I the only one who thinks this is disconcerting? Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. On 11/8/23 2:23 PM, Bryan Fields wrote: > On 11/8/23 2:25 PM, o...@delong.com wrote: >> Seems irresponsible to me that a root-server (or other critical DNS >> provider) would engage in a >> peering war to the exclusion of workable DNS. > > I've brought this up before and the root servers are not really an IANA > function IIRC. There's not > much governance over them, other than what's on root-servers.org. I think a > case could be made that > C is in violation of the polices on that page and RFC 7720 section 3. > > Basically none of the root servers want to change this and thus it's never > going to change. DNS > will fail and select another to talk to, and things will still work. At what point does HE just host a second C root and announce the same IPv6s? Might irritate Cogent, but its not more "bad" than Cogent failing to uphold the requirements for running a root server. Matt
Re: Appropriate venue to find out about the state of art of spear phishing defense?
We use KnowBe4.com's user training. That's really the only way you can fight this, since its a human problem, not a technical one. These guys provide fully automated, AI based (well, who knows what that means) simulated phishing attacks, largely to give users real-world practical experience detecting and fending off attacks. You get a report card on each users to, so you know where the weaknesses are in your staff knowledge. Their training regimen includes some pretty good self-guided instructional videos. DMARC, SPF, digitally-signed emails, encryption, none of that matters if a user can be tricked into letting the crooks in the front door. -mel From: NANOG on behalf of Michael Thomas Sent: Monday, November 13, 2023 11:40 AM To: nanog@nanog.org Subject: Appropriate venue to find out about the state of art of spear phishing defense? I know this is only tangentially relevant to nanog, but I'm curious if anybody knows where I can ask what orgs do to combat spear phishing? Spear phishing doesn't require that you deploy DMARC since you can know your own policy even if you aren't comfortable publishing it to the world. tia, Mike
Appropriate venue to find out about the state of art of spear phishing defense?
I know this is only tangentially relevant to nanog, but I'm curious if anybody knows where I can ask what orgs do to combat spear phishing? Spear phishing doesn't require that you deploy DMARC since you can know your own policy even if you aren't comfortable publishing it to the world. tia, Mike
Re: Strange IPSEC traffic
- On Nov 13, 2023, at 9:43 AM, Maurice Brown maur...@pwnship.com wrote: Hi, > A new attack was published against SSH and the paper authors are theorizing > that > the attack is possible against IPSEC due to flaws in the CPU that are > exploitable via brute force. For those interested, here is the paper: https://eprint.iacr.org/2023/1711.pdf It's written for SSH, but the authors theorize it will work for IPSec as well. Thanks, Sabri
Re: Am I the only one who thinks this is disconcerting?
On 11/8/23 2:23 PM, Bryan Fields wrote: On 11/8/23 2:25 PM, o...@delong.com wrote: Seems irresponsible to me that a root-server (or other critical DNS provider) would engage in a peering war to the exclusion of workable DNS. I've brought this up before and the root servers are not really an IANA function IIRC. There's not much governance over them, other than what's on root-servers.org. I think a case could be made that C is in violation of the polices on that page and RFC 7720 section 3. Basically none of the root servers want to change this and thus it's never going to change. DNS will fail and select another to talk to, and things will still work. At what point does HE just host a second C root and announce the same IPv6s? Might irritate Cogent, but its not more "bad" than Cogent failing to uphold the requirements for running a root server. Matt
Re: The rise and fall of the 90's telecom bubble
Dave Taht's question about all the redundant fiber that was put down in the telecom bubble is a very interesting one. It would be nice if some folks on the list could provide some solid information, even if only for one large carrier. My impression, from communications with various folks, is that much of that fiber from around 2000 was never lit. The reason is that better fiber came on the market. However, what was used (at least in some cases, again, this is something I would love to get real data on) was that some of the empty conduits that were put down then were used to shoot the new generations of fiber through. (It was quite common for carriers to put down 4 conduits, and only pull fiber through one of them, leaving the other 3 for later use.) Concerning the Doug O'Laughlin post that Dave cites, it is very good. For more on the myth of "Internet doubling every 100 days," my paper "Bubbles, gullibility, and other challenges for economics, psychology, sociology, and information sciences" published in First Monday in Sept. 2010, https://firstmonday.org/ojs/index.php/fm/article/view/3142/2603 Participants of this list were very helpful in providing information for that paper. (Some of the correspondence is in the list archives, most was off-line.) But O'Laughlin is too hard on Global Crossing, for example, when he says it "was essentially a fundraising scheme looking for a problem." Global Crossing had a real business plan, it was the first transatlantic cable that was not built by consortia of incumbent telcos, and it planned to take advantage of the rising demand for transmission by offering capacity to new players, who would otherwise be gouged by incumbents. (It did get into accounting shenanigans later on, as competition arose, but that was later.) What is most interesting is that their business plan was based on an assumption of demand about doubling each year (which is what was taking place), not doubling every 100 days. (This I learned when I was consulted on some of the litigation after the telecom crash, but by now the information is publicly available.) What killed them is that their assumption that it would be difficult for others to get the (special undersea) fiber, the cable-laying ships, the permits, ..., turned out to be wrong, and so a slew of competitors, inspired by the myth of astronomical growth rates, came on the scene. (Global Crossing's expansion into terrestrial fiber networks was also a major contributor.) One of the astounding observations is that while Global Crossing was assuming 100% annual growth rate in traffic, the industry as a whole (as well as the press, the FCC, and so on) were talking of 1,000% growth rates. And the only observer that I was able to find who noted this in print was George Gilder, who drew the wrong conclusion from this! (Details are in the paper cited above.) Andrew P.S. Some interesting materials from telecom bubble era are available at https://www-users.cse.umn.edu/~odlyzko/isources/index.html On Sun, 12 Nov 2023, Dave Taht wrote: Aside from me pinning the start of the bubble closer to 1992 when commercial activity was allowed, and M&A for ISPs at insane valuations per subscriber by 1995 (I had co-founded an ISP in 93, but try as I might I cannot remember if it peaked at 50 or 60x1 by 1996 (?) and crashed by 97 (?)), this was a whacking good read, seems accurate, and moves to comparing it across that to the present day AI bubble. https://www.fabricatedknowledge.com/p/lessons-from-history-the-rise-and In the end we sold (my ISP, founded 93) icanect for 3 cents on the dollar in 99, and I lost my shirt (not for the first time) on it, only to move into embedded Linux (Montavista) after the enormous pop redhat's IPO had had in 99. The company I was part of slightly prior (Mediaplex) went public December 12, 1999 and cracked 100/share, only to crash by march, 2000 to half the IPO price (around $7 as I recall), wiping out everyone that had not vested yet. I lost my shirt again on that and Montavista too and decided I would avoid VCs henceforth. I am always interested in anecdotal reports of personal events in this increasingly murky past, and in trying to fact check the above link. So much fiber got laid by 2000 that it is often claimed that it was at least a decade before it was used up, (the article says only 2.7% was in use by 2002) and I have always wondered how much dark, broken, inaccessible fiber remains that nobody knows where it even is anymore due to many lost databases. I hear horror stories... The article also focuses solely on the us sector, and I am wondering what it looked like worldwide. I believed in the 90s we were seeing major productivity gains. The present expansion of the internet in my mind should not be much associated with "productivity gains", as, imho, reducing the general population to two thumbs and a 4 inch screen strikes me as an enormous step backwards. (I have a bad habit of cross po
Re: Strange IPSEC traffic
A new attack was published against SSH and the paper authors are theorizing that the attack is possible against IPSEC due to flaws in the CPU that are exploitable via brute force. On Mon, Nov 13, 2023 at 9:42 AM Adrian Minta wrote: > On 11/13/23 19:10, Shawn L via NANOG wrote: > > Is anyone else seeing a lot of 'strange' IPSEC traffic? We started seeing > logs of IPSEC with invalid spi on Friday. We're seeing it on pretty much > all of our PE routers, none of which are setup to do anything VPN related. > Most are just routing local customer traffic. > > > > decaps: rec'd IPSEC packet has invalid spi for destaddr=X.X.X.X, prot=50, > spi=0x9D2D(2636972032), srcaddr=211.112.195.167, input > interface=TenGigabitEthernet0/0/11 > > > > decaps: rec'd IPSEC packet has invalid spi for destaddr=Y.Y.Y.Y, prot=50, > spi=0x1469(342425600), srcaddr=74.116.56.244, input > interface=TenGigabitEthernet0/0/5 > > > > The destination address is always one of our customer's ip addresses. The > source seems to be all over the place, mostly Russia, Korea, China or south > east asia. It's not really impacting anything at the moment, just rather > annoying. > > > > Thanks > > > > Shawn > > > Hi Shawn, > > we saw a lot of syslog messages like these and the targets are cisco > devices, some of witch, according to the data sheets, are not even capable > of ipsec. > > Cisco is punting some ESP traffic to control plane on ios and ios-xe > devices, regardless of the configuration. > > Last week somebody on the internet started a campaign to scan and perhaps > to exploit some zero day ipsec vulnerabilities. > > > This is the list of ip addresses we saw: https://pastebin.com/vrLRai9Q > > > > -- > Best regards, > Adrian Minta > > > >
RE: Strange IPSEC traffic
I can confirm we started seeing this on Nov 9th at 19:10 UTC across all markets from a variety of sources. If you want to filter it with ingress ACLs they need to include subnet base and broadcast addresses in addition to interface address, so a router at 192.168.1.1/30 with a customer potentially running IPSEC at 192.168.1.2 would require all this to silence the log messages: access-list 100 deny esp any host 192.168.1.0 access-list 100 deny esp any host 192.168.1.1 access-list 100 deny esp any host 192.168.1.3 access-list 100 permit ip any any I started with an ACL only on the interface address and then noticed I was still getting logs on base/broadcast addresses. Could be recon for the IKEv2 vulnerability in this: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-ravpn-auth-8LyfCkeC https://blogs.cisco.com/security/akira-ransomware-targeting-vpns-without-multi-factor-authentication Or zero day. Even though the devices they are hitting are not configured for IPSEC we are filtering it anyway (and for good measure " no crypto isakmp enable"). Mike
Re: Strange IPSEC traffic
On 11/13/23 19:10, Shawn L via NANOG wrote: Is anyone else seeing a lot of 'strange' IPSEC traffic? We started seeing logs of IPSEC with invalid spi on Friday. We're seeing it on pretty much all of our PE routers, none of which are setup to do anything VPN related. Most are just routing local customer traffic. decaps: rec'd IPSEC packet has invalid spi for destaddr=X.X.X.X, prot=50, spi=0x9D2D(2636972032), srcaddr=211.112.195.167, input interface=TenGigabitEthernet0/0/11 decaps: rec'd IPSEC packet has invalid spi for destaddr=Y.Y.Y.Y, prot=50, spi=0x1469(342425600), srcaddr=74.116.56.244, input interface=TenGigabitEthernet0/0/5 The destination address is always one of our customer's ip addresses. The source seems to be all over the place, mostly Russia, Korea, China or south east asia. It's not really impacting anything at the moment, just rather annoying. Thanks Shawn Hi Shawn, we saw a lot of syslog messages like these and the targets are cisco devices, some of witch, according to the data sheets, are not even capable of ipsec. Cisco is punting some ESP traffic to control plane on ios and ios-xe devices, regardless of the configuration. Last week somebody on the internet started a campaign to scan and perhaps to exploit some zero day ipsec vulnerabilities. This is the list of ip addresses we saw: https://pastebin.com/vrLRai9Q -- Best regards, Adrian Minta
Strange IPSEC traffic
Is anyone else seeing a lot of 'strange' IPSEC traffic? We started seeing logs of IPSEC with invalid spi on Friday. We're seeing it on pretty much all of our PE routers, none of which are setup to do anything VPN related. Most are just routing local customer traffic. decaps: rec'd IPSEC packet has invalid spi for destaddr=X.X.X.X, prot=50, spi=0x9D2D(2636972032), srcaddr=211.112.195.167, input interface=TenGigabitEthernet0/0/11 decaps: rec'd IPSEC packet has invalid spi for destaddr=Y.Y.Y.Y, prot=50, spi=0x1469(342425600), srcaddr=74.116.56.244, input interface=TenGigabitEthernet0/0/5 The destination address is always one of our customer's ip addresses. The source seems to be all over the place, mostly Russia, Korea, China or south east asia. It's not really impacting anything at the moment, just rather annoying. Thanks Shawn
Re: BGP-iSec: Improved Security of Internet Routing Against Post-ROV Attacks
Dear Amir,
On Fri, Nov 10, 2023 at 06:02:48PM -0500, Amir Herzberg wrote:
> We will present our new work, titled: `BGP-iSec: Improved Security of
> Internet Routing Against Post-ROV Attacks', in NDSS'24.
>
> If you're interested in security of Internet routing (BGP), and want a
> copy, see URL below, drop me a message/email - or see us in the
> conference - or just read the final version.
>
> Available from:
> https://www.researchgate.net/publication/375553362_BGP-iSec_Improved_Security_of_Internet_Routing_Against_Post-ROV_Attacks
Thanks for freely sharing a copy! This allowed me to jot down some
initial thoughts.
* It appears that BGP-iSec requires a deployment flag day per Autonomous
System, rather than doing security upgrades "one EBGP session at a
time" (a deployment model both RPKI-ROV and BGPsec support).
This lack of "per EBGP session"-granularity doesn't make for a
feasible or viable deployment story in the global Internet routing
system - as quite some Autonomous Systems are composed of thousands of
routers which cannot be made to do the same thing at the same moment
for logistical and various other reasons. What BGP-iSec promotes as a
'feature' ("Mandatory Signatures for Announcement Integrity") - may
turn out to be its biggest impediment towards deployment in the real
world.
* As noted in RFC 7132 [0], Google's [1], Fastly's [2] response to
the FCC "inquiry into internet routing vulnerabilities" which your
paper cites; BGPsec was consciously not designed to address route
leaks, as leaks are not precluded by the specification for BGP and
might be the result of a local policy that is not publicly disclosed.
To me the sentence "Even under full adoption, BGPsec does not prevent
route leaks" reads contentious, because of an implicit assertion that
BGPsec was intended to address route leaks.
To me the above reads as "Even under full adoption of IPv6, world
hunger will not be achieved". E.g. seems a false equivalence is drawn.
* It appears BGP-iSec took some inspiration from ASPA, but instead of
signalling the list of providers out-of-band (which ASPA does via the
RPKI publication system); BGP-iSec proposed an in-band signal in the
form of 'UP' messages encapsulated inside BGP Path Attributes. Again,
this suggests that BGP-iSec requires a flag day for all EBGP routers
in a given Autonomous System; whereas deployment of the ASPA signal
happens via a singular place (the RIR RPKI web portal), and in order
to publish an ASPA object, no changes have to be executed on the
Autonomous System's EBGP routers.
* The bold assertion made by the BGP-iSec authors that BGPSec offers
"meagre benefits in partial adoption" to me seems a subjective one.
Consider when two BGPSec-capable networks interconnect, both parties
immediately benefit from having secured that interconnection point.
For example, if this happens to be the interconnection between two
major cloud providers, the advantages are massive and can positively
benefit billions of indirect constituents. Similarly, in the past I've
argued that only the biggest networks in the world need to do RPKI-ROV
for all of the Internet to take benefit from that deployment action by
a single small group. Comparing RPKI-ROV & BGPSec is apples and
oranges; but the point stands that in an Internet with increased
centralization we have to rethink what exactly the consequences are of
so-called 'partial deployments' of security features.
I enjoyed reading the BGP-iSec paper and certainly view and appreciate
it as an interesting perspective on the routing security problem space;
but I think for very good reasons AS_PATH integrity (BGPsec) and AS_PATH
route leaks (OPEN Policy, OTC, ASPA) are addressed as independent
technology extensions to the routing stack.
Sometimes, trying to kill two or three birds with one stone
inadvertently introduces significant cost in unexpected places,
presenting surprising barriers to deployment.
Kind regards,
Job
[0]: https://datatracker.ietf.org/doc/html/rfc7132
[1]: https://www.fcc.gov/ecfs/document/10411283450/1
[2]:
https://sobornost.net/~job/fastly-fcc-noi-secure-internet-routing-reply-comments-20220510-201259363-pdf.pdf
