Re: BGP-iSec: Improved Security of Internet Routing Against Post-ROV Attacks
Tom, thanks for the feedback! We will try to avoid giving the impression that BGP-iSec is a working solution or to oversell it otherwise; sometimes, when one writes about a design, such `selling-speach' crawls in without invitation or intention :) So, I've rephrased "relatively easy to implement" to something which would hopefully not be misleading, and added a bit in conclusions and intro to try to clarify that more research is needed, pointing out several directions. We'll try to find more places where we it may be desirable to clarify this; if you (or others) have more specific examples, that would be appreciated. Thanks again, Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/cybersecurity On Mon, Nov 20, 2023 at 12:41 PM Tom Beecher wrote: > Amir- > > I have to take some issue with one comment you made in response to Job. > > BGP-iSec, at this point, is just an academic study studying some new ideas >> and evaluating their impact in specific configurations, under specific >> assumptions etc.; hopefully, this may provide some help to the community in >> improving BGP security. >> > > When reviewing the paper , it feels as if BGP-iSec is being presented as a > working solution, not just ideas and theoretical analysis. Care should be > taken not to oversell the status of a thing; that just leads to confusion > and issues later. > > Also, as an aside, when most network engineers read statements that > something is "relatively easy to implement", large red lights start going > off in our brains; If we had $1 for every time we heard that and it turned > out to be false, we'd all pretty much be retired. :) > > > > > > > > > On Mon, Nov 20, 2023 at 10:45 AM Amir Herzberg > wrote: > >> Lancheng, thanks for your comment. >> >> About ProConi (and ASPA): so, we're aware it's more challenging than ASPA >> and have evaluated the effort required - it actually doesn't seem too bad, >> although that doesn't mean that it'll be cost effective to use it. But as >> I've mentioned in an earlier email to this list, Joel Halpern (cc:ed) has >> alerted us to an even larger problem with ProConi; the proconi list of a >> given AS may become incorrect due to certain changes in AS relationships, >> leading to possible false-positives for possibly significant time. This is >> obviously very problematic and we are editing this part of the paper to >> reflect this risk. Probably, this mechanism should not be deployed; >> luckily, we obtained good results also with the other defenses against >> leakage in the paper, for the practical case of non-eavesdropping >> adversary. In any case we see the work as the opening point, or another >> step, toward more effective defenses against path manipulations and >> intentional route leaks. More work should be done. >> >> We look forward to meeting you in NDSS; I haven't yet seen list of >> accepted papers, and it'll be great if you can share your paper. But if >> not, then we'll see it in the conference :) >> >> best, Amir >> -- >> Amir Herzberg >> >> Comcast professor of Security Innovations, Computer Science and >> Engineering, University of Connecticut >> Homepage: https://sites.google.com/site/amirherzberg/home >> `Applied Introduction to Cryptography' textbook and lectures: >> https://sites.google.com/site/amirherzberg/cybersecurity >> >> >> >> >> On Mon, Nov 20, 2023 at 5:30 AM Lancheng Qin >> wrote: >> >>> Hi Amir, >>> >>> >>> >>> I really enjoy reading this paper, and I’m interested in your design of >>> preventing attribute manipulations and route leaks. >>> >>> >>> >>> I think BGP-iSec is useful under a Global Attacker. But I have some >>> concerns about using ProConIP-list under a Full Attacker (in Sec. III-B). >>> Using ProConIP-list requires the origin AS clearly knows its provider cone, >>> which is challenging in practice. Although we can use CAIDA topology to >>> infer the provider cone of an AS, some provider-customer relationships may >>> not be discovered by CAIDA topology or other existing AS relationship >>> inference algorithms. If the ProConIP-list is not accurate or complete >>> (i.e., covering all BGP-iSec-adopting ASes in the provider cone), it may >>> cause legitimate BGP announcements to be dropped. Compared to publishi
Re: BGP-iSec: Improved Security of Internet Routing Against Post-ROV Attacks
Lancheng, thanks for your comment. About ProConi (and ASPA): so, we're aware it's more challenging than ASPA and have evaluated the effort required - it actually doesn't seem too bad, although that doesn't mean that it'll be cost effective to use it. But as I've mentioned in an earlier email to this list, Joel Halpern (cc:ed) has alerted us to an even larger problem with ProConi; the proconi list of a given AS may become incorrect due to certain changes in AS relationships, leading to possible false-positives for possibly significant time. This is obviously very problematic and we are editing this part of the paper to reflect this risk. Probably, this mechanism should not be deployed; luckily, we obtained good results also with the other defenses against leakage in the paper, for the practical case of non-eavesdropping adversary. In any case we see the work as the opening point, or another step, toward more effective defenses against path manipulations and intentional route leaks. More work should be done. We look forward to meeting you in NDSS; I haven't yet seen list of accepted papers, and it'll be great if you can share your paper. But if not, then we'll see it in the conference :) best, Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/cybersecurity On Mon, Nov 20, 2023 at 5:30 AM Lancheng Qin wrote: > Hi Amir, > > > > I really enjoy reading this paper, and I’m interested in your design of > preventing attribute manipulations and route leaks. > > > > I think BGP-iSec is useful under a Global Attacker. But I have some > concerns about using ProConIP-list under a Full Attacker (in Sec. III-B). > Using ProConIP-list requires the origin AS clearly knows its provider cone, > which is challenging in practice. Although we can use CAIDA topology to > infer the provider cone of an AS, some provider-customer relationships may > not be discovered by CAIDA topology or other existing AS relationship > inference algorithms. If the ProConIP-list is not accurate or complete > (i.e., covering all BGP-iSec-adopting ASes in the provider cone), it may > cause legitimate BGP announcements to be dropped. Compared to publishing > the whole provider cone, ASPA requires an AS to publish its provider ASes, > which is easier and more feasible. Can we use BGP-iSec and ASPA together? > Would > that be more beneficial? > > > > BTW, I will also present my new work on routing security in NDSS’2024. > Looking forward to discussing more with you in San Diego:) > > > > Best, > > Lancheng Qin > > > > > > -原始邮件- > *发件人:* "Amir Herzberg" > *发送时间:* 2023-11-11 07:02:48 (星期六) > *收件人:* NANOG > *主题:* BGP-iSec: Improved Security of Internet Routing Against Post-ROV > Attacks > > Hi NANOGers, > > > 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 > -- > Amir Herzberg > > Comcast professor of Security Innovations, Computer Science and > Engineering, University of Connecticut > Homepage: https://sites.google.com/site/amirherzberg/home > `Applied Introduction to Cryptography' textbook and lectures: > https://sites.google.com/site/amirherzberg/cybersecurity > > >
Re: [External] announcing IPs by scrubbing service to help with DDoS attacks and ROAs
Tom, thanks. I'm an academic researcher, no a network operator, sorry for the confusion, I should have been clearer. The practice you described indeed shouldn't requite ROA. I didn't even consider it, probably since I've been working so much on prefix hijacks, and this prefix would result in increased vulnerability to prefix hijacks. But if there's only a DDoS attack on the prefix and it's not being hijacked at the same time, then I think this practice may be fine - which would make such `emergency ROA' unnecessary. So that's very very useful feedback, thanks a lot!! Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/cybersecurity On Fri, Nov 17, 2023 at 12:09 AM Tom Krenn wrote: > It has been a few years, but I recall advertising my routes to the > scrubbing center via a tunnel and just prepending to my other peers when in > mitigation. This was pre-RPKI days, but my ASN was still originating the > route. So, I would assume no change in ROA would be needed in that > scenario. Are you allowing them to originate your routes or are they just > another hop in your as-path? > > > > Tom Krenn > > Network Architect > > Enterprise Architecture - Information Technology > > [image: Hennepin County logo] > > > > > > *From:* NANOG *On Behalf > Of *Amir Herzberg > *Sent:* Thursday, November 16, 2023 19:58 > *To:* NANOG > *Subject:* [External] announcing IPs by scrubbing service to help with > DDoS attacks and ROAs > > > > *CAUTION:* This email was sent from outside of Hennepin County. Unless > you recognize the sender and know the content, do not click links or open > attachments. > > Hi, do people use scrubbing services, when under DDoS attack, by having > the scrubbing service announce the attacked IP prefix(es)? > > > > If so, and you have a ROA for these prefixes, do you authorize the > scrubbing AS (by issuing ROA or otherwise), and if so, do you do it in > advance or only when you need the scrubbing service to announce your > prefix? > > > > To clarify: we have a possible method to allow such `emergency ROAs' but > I'm not convinced if we have a solution to a real problem - or if we just > found a cute crypto solution and will end up writing it for a non-real > problem. I prefer not to waste our time on presenting cute solutions to > non-real problems :) > > > > So thanks for your help! Use your judgement if to respond on list or off > list. > > > > Many thanks, Amir > > -- > > Amir Herzberg > > > > Comcast professor of Security Innovations, Computer Science and > Engineering, University of Connecticut > > Homepage: https://sites.google.com/site/amirherzberg/home > > `Applied Introduction to Cryptography' textbook and lectures: > https://sites.google.com/site/amirherzberg/cybersecurity > > > > > > > *Disclaimer:* If you are not the intended recipient of this message, > please immediately notify the sender of the transmission error and then > promptly permanently delete this message from your computer system. >
announcing IPs by scrubbing service to help with DDoS attacks and ROAs
Hi, do people use scrubbing services, when under DDoS attack, by having the scrubbing service announce the attacked IP prefix(es)? If so, and you have a ROA for these prefixes, do you authorize the scrubbing AS (by issuing ROA or otherwise), and if so, do you do it in advance or only when you need the scrubbing service to announce your prefix? To clarify: we have a possible method to allow such `emergency ROAs' but I'm not convinced if we have a solution to a real problem - or if we just found a cute crypto solution and will end up writing it for a non-real problem. I prefer not to waste our time on presenting cute solutions to non-real problems :) So thanks for your help! Use your judgement if to respond on list or off list. Many thanks, Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/cybersecurity
Re: BGP-iSec: Improved Security of Internet Routing Against Post-ROV Attacks
omething.
> 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;
I definitely agree with this last statement. RPKI-ROV does not
automatically downgrade once an announcement exits an island of deploying
ASes.
> 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.
>
But that's exactly what we try to do by using simulations to measure the
impact.
>
> I enjoyed reading the BGP-iSec paper and certainly view and appreciate
> it as an interesting perspective on the routing security problem space;
>
Thanks!
> 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.
>
I'm not arguing against separation. OTOH, our results show that OTC becomes
effective even against intentional attack, if protected by the same
integrity mechanisms we use to protect the AS-path.
>
> Sometimes, trying to kill two or three birds with one stone
> inadvertently introduces significant cost in unexpected places,
> presenting surprising barriers to deployment.
>
True. And deployment and standardization are very important and
challenging. BGP-iSec, at this point, is just an academic study studying
some new ideas and evaluating their impact in specific configurations,
under specific assumptions etc.; hopefully, this may provide some help to
the community in improving BGP security.
--
Amir Herzberg
Comcast professor of Security Innovations, Computer Science and
Engineering, University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography' textbook and lectures:
https://sites.google.com/site/amirherzberg/cybersecurity
On Mon, Nov 13, 2023 at 12:06 PM Job Snijders wrote:
> 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 p
BGP-iSec: Improved Security of Internet Routing Against Post-ROV Attacks
Hi NANOGers, 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 -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/cybersecurity
Re: swedish dns zone enumerator
Randy, thanks for sharing, I didn't know this is actually done. Any idea if they use something clever or just exhaustive search? thanks Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/cybersecurity On Tue, Oct 31, 2023 at 6:49 PM Randy Bush wrote: > i have blocked a zone enumerator, though i guess they will be a > whack-a-mole > > others have reported them as well > > /home/randy> sudo tcpdump -pni vtnet0 -c 10 port 53 and net 193.235.141 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on vtnet0, link-type EN10MB (Ethernet), capture size 262144 bytes > 22:42:39.516849 IP 193.235.141.90.32768 > 666.42.7.11.53: 14 NS? > 33j4h.org.al. (30) > 22:42:39.517640 IP 193.235.141.17.32768 > 666.42.7.11.53: 14 NS? > 33m6d.xn--mgbayh7gpa. (38) > 22:42:39.519169 IP 193.235.141.17.32768 > 666.42.7.11.53: 14 NS? 33lxd.tn. > (26) > 22:42:39.520064 IP 193.235.141.171.32768 > 666.42.7.11.53: 14 NS? 33md6.jo. > (26) > 22:42:39.521081 IP 193.235.141.247.32768 > 666.42.7.11.53: 14 NS? 33lxd.lb. > (26) > 22:42:39.523981 IP 193.235.141.162.32768 > 666.42.7.11.53: 14 NS? 33pd2.az. > (26) > 22:42:39.525043 IP 193.235.141.60.32768 > 666.42.7.11.53: 14 NS? > 33nc5.com.al. (30) > 22:42:39.526185 IP 193.235.141.209.32768 > 666.42.7.11.53: 14 NS? 33nc5.sz. > (26) > 22:42:39.527931 IP 193.235.141.150.32768 > 666.42.7.11.53: 14 NS? > 33q5p.com.al. (30) > 22:42:39.529516 IP 193.235.141.210.32768 > 666.42.7.11.53: 14 NS? > 33qbq.com.al. (30) > 10 packets captured > 124 packets received by filter > 0 packets dropped by kernel > > inetnum:193.235.141.0 - 193.235.141.255 > netname:domaincrawler-hosting > descr: domaincrawler hosting > org:ORG-ABUS1196-RIPE > country:SE > admin-c:VIJE1-RIPE > tech-c: VIJE1-RIPE > status: ASSIGNED PA > notify: c+1...@resilans.se > mnt-by: RESILANS-MNT > mnt-routes: ETTNET-LIR > created:2008-04-03T11:21:00Z > last-modified: 2017-04-10T12:47:06Z > source: RIPE > > randy >
Re: RPKI unknown for superprefixes of existing ROA ?
I agree that a good, sensible defense would be to simply announce your entire address block, e.g., in the example, your entire /22 (with a ROA to your ASN), and filter the traffic to the unused prefixes. Basically, I guess, it means that the AS 0 solution shouldn't be used, at least not usually. I wonder if anyone is using it , in fact. It would be nice to know if someone has the data handy. Thanks! Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/cybersecurity On Sun, Oct 22, 2023 at 1:50 PM Tom Beecher wrote: > Look again, Tom. This is an attack vector using a LESS specific route. The >> /22 gets discarded, but a covering /0-/21 would not. >> > > Yes. And reliant on the operator doing something exceptionally not smart > to begin with. Relying on an AS0 ROA alone and not actually announcing the > covering prefix as well isn't a good thing to do. > > On Sun, Oct 22, 2023 at 1:39 PM Owen DeLong wrote: > >> Look again, Tom. This is an attack vector using a LESS specific route. >> The /22 gets discarded, but a covering /0-/21 would not. >> >> Owen >> >> On Oct 22, 2023, at 10:06, Tom Beecher wrote: >> >> >> >>> And is it your belief that this addresses the described attack vector? >>> AFAICT, it does not. >>> >> >> Quoting myself : >> >> WITH the assertion that all routers in the routing domain are RPKI >>> enabled, and discarding RPKI INVALIDs. >>> >> >> In the mixed RPKI / non-RPKI environment of today's internet, no it >> doesn't. This does not mean that RPKI is deficient, or the AS 0 ROA doesn't >> work as intended, as was stated. >> >> >> >> On Sun, Oct 22, 2023 at 12:57 PM William Herrin wrote: >> >>> On Sun, Oct 22, 2023 at 9:38 AM Tom Beecher wrote: >>> >> He's saying that someone could come along and advertise 0.0.0.0/1 and >>> >> 128.0.0.0/1 and by doing so they'd hijack every unrouted address >>> block >>> >> regardless of the block's ROA. >>> >> >>> >> RPKI is unable to address this attack vector. >>> > >>> > >>> > https://www.rfc-editor.org/rfc/rfc6483 >>> > >>> > Section 4 >>> >> >>> >> >>> >> A ROA with a subject of AS 0 (AS 0 ROA) is an attestation by the >>> >> holder of a prefix that the prefix described in the ROA, and any more >>> >> specific prefix, should not be used in a routing context. >>> >>> And is it your belief that this addresses the described attack vector? >>> AFAICT, it does not. >>> >>> Regards, >>> Bill Herrin >>> >>> >>> -- >>> William Herrin >>> b...@herrin.us >>> https://bill.herrin.us/ >>> >>
Re: RPKI unknown for superprefixes of existing ROA ?
Bill, thanks! You explained the issue much better than me. Yes, the problem is that, in my example, the operator was allocated 1.2.4/22 but the attacker is announcing 1.2.0/20, which is larger than the allocation, so the operator cannot issue ROA for it (or covering it). Of course, the RIR _could_ do it (but I don't think they do, right?). So this `superprefix hijack' may succeed in spite of all the ROAs that the operator could publish. I'm not saying this is much of a concern, as I never heard of such attacks in the wild, but I guess it _could_ happen in the future. So my question is only: > So: would it be conceivable that operators will block such 1.2.0/20 - > since it's too large a prefix without ROA and in particular includes > sub-prefixes with ROA, esp. ROA to AS 0? > (note: I mentioned two possible rules for such blocking: overly large `unknown' prefixes and super-prefixes of AS 0 ROAs - but either could be applied or even their conjunction) tks, Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/cybersecurity On Sat, Oct 21, 2023 at 4:52 PM William Herrin wrote: > On Sat, Oct 21, 2023 at 11:47 AM Mark Tinka wrote: > > The question is - who gets to decide how much space is "too large"? > > I thought Amir's point was that if an announced route is larger than > the RIR allocation then unless you're intentionally expecting it, it's > invalid. > > Because there's no alignment with the RIR allocation, it's not > possible to express this invalidity in RPKI. > > Regards, > Bill Herrin > > > > -- > William Herrin > b...@herrin.us > https://bill.herrin.us/ >
RPKI unknown for superprefixes of existing ROA ?
Hi Owen, Randy, Job and other NANOGers, I surely agree with you all that we shouldn't expect discarding of ROA-unknown `anytime soon' (or ever?). But I have a question: what about discarding ROA-unknowns for very large prefixes (say, /12), or for superprefixes of prefixes with announced ROAs? Or at least, for superprefixes of prefixes with ROA to AS 0? For motivation, consider the `superprefix hijack attack'. Operator has prefix 1.2.4/22, but announce only 1.2.5/24 and 1.2.6/24, with appropriate ROAs. To avoid abuse of 1.2.4/24 and 1.2.7/24, they also make a ROA for 1.2.4/22 with AS 0. Attacker now announces 1.2.0/20, and uses IPs in 1.2.4/24 and 1.2.7/24 to send spam etc.. We introduced this threat and analyzed it in our ROV++ paper, btw (NDSS'21 I think - available online too of course). So: would it be conceivable that operators will block such 1.2.0/20 - since it's too large a prefix without ROA and in particular includes sub-prefixes with ROA, esp. ROA to AS 0? -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/cybersecurity On Thu, Oct 19, 2023 at 2:49 PM Owen DeLong via NANOG wrote: > A question for network operators out there that implement ROV… > > Is anyone rejecting RPKI unknown routes at this time? > > I know that it’s popular to reject RPKI invalid (a ROA exists, but doesn’t > match the route), but I’m wondering if anyone is currently or has any > plans to start rejecting routes which don’t have a matching ROA at all? > > Thanks, > > Owen > >
Re: ROV concern for hyper-specific prefixes (renamed from `Re: Smaller than a /24 for BGP?')
Tom, thanks. I forget to mention the problem of this case ( AS 10 creates an ROA for X.X.X.X/24 , maxLength 28). Security-wise, this may actually be the worst solution: - An attacker can abuse this ROA to perform origin-hijack of the /28 subprefix, just like the origin hijack if AS 10 publishes ROA for the /28 - The max-length also allows similar origin-hijack of `intermediate prefixes' (e.g., /25), which may be allowed by ASes which will not allow /28, so there may be an even higher chance for the attacker to succeed in attracting traffic. Of course, this is basically what is discussed in the `maxlength considered harmful' paper and RFC (RFC 9319), nothing really new here. Best, Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/cybersecurity On Mon, Jan 30, 2023 at 9:39 AM Tom Beecher wrote: > - If origin makes a ROA only for covering prefix (say /24) then the /28 >> announcement would be considered invalid by ROV and (even more likely) >> dropped. Also you get more instances of `invalid' announcements, making >> adoption of ROVs and ROAs harder. >> > > AS 10 creates an ROA for X.X.X.X/24 , maxLength 28. This means AS10 can > announce any /28 in that /24, and any validator should return valid. (This > ignores if the longer than /24s would be accepted by policy or not. ) > > On Mon, Jan 30, 2023 at 9:19 AM Amir Herzberg > wrote: > >> Thanks to Lars for this interesting input and results (which I wasn't >> familiar with). >> >> I want to mention another concern with the possible use of hyper-specific >> IP prefixes, i.e., longer than /24, which I haven't seen discussed in the >> thread (maybe I missed it?). Namely, if you allow say /28 announcements, >> then what would be the impact of ROV? Seems this can cause few problems: >> >> - If origin, say AS 10, makes a ROA for the /28, this would allow an >> attacker, e.g., AS 666, to do origin-hijack (announce path 666-10 to the >> /28), and attract traffic for the /28 from anybody accepting /28 >> announcements (that didn't receive the legit announcement). Plus, of >> course, you get more overhead in ROA distribution and validation. >> >> - If origin makes a ROA only for covering prefix (say /24) then the /28 >> announcement would be considered invalid by ROV and (even more likely) >> dropped. Also you get more instances of `invalid' announcements, making >> adoption of ROVs and ROAs harder. >> >> Just a thought... Amir >> -- >> Amir Herzberg >> >> Comcast professor of Security Innovations, Computer Science and >> Engineering, University of Connecticut >> Homepage: https://sites.google.com/site/amirherzberg/home >> `Applied Introduction to Cryptography' textbook and lectures: >> https://sites.google.com/site/amirherzberg/cybersecurity >> >> >> >> >> On Wed, Jan 25, 2023 at 1:17 PM Lars Prehn wrote: >> >>> We performed some high-level analyses on these hyper-specific prefixes >>> about a year ago and pushed some insights into a blog post [1] and a paper >>> [2]. >>> >>> While not many ASes redistribute these prefixes, some accept and use >>> them for their internal routing (e.g., NTT's IPv4 filtering policy [3]). >>> Rob already pointed out that this is often sufficient for many traffic >>> engineering tasks. In the remaining scenarios, announcing a covering /24 >>> and hyper-specific prefixes may result in some traffic engineering, even if >>> the predictability of the routing impact is closer to path prepending than >>> usual more-specific announcements. In contrast to John's claim, some >>> transit ASes explicitly enabled redistributions of up to /28s for their >>> customers upon request (at least, they told us so during interviews). >>> >>> Accepting and globally redistributing all hyper-specifics increases the >>> routing table size by >100K routes (according to what route collectors >>> see). There are also about 2-4 de-aggregation events every year in which >>> some origin (accidentally) leaks some large number of hyper-specifics to >>> its neighbours for a short time. >>> >>> Best regards, >>> Lars >>> >>> [1] >>> https://blog.apnic.net/2022/09/01/measuring-hyper-specific-prefixes-in-the-wild/ >>> [2] https://dl.acm.org/doi/pdf/10.1145/3544912.3544916 >>> [3] https://www.gin.ntt.net/support-center/policies-procedur
ROV concern for hyper-specific prefixes (renamed from `Re: Smaller than a /24 for BGP?')
Thanks to Lars for this interesting input and results (which I wasn't familiar with). I want to mention another concern with the possible use of hyper-specific IP prefixes, i.e., longer than /24, which I haven't seen discussed in the thread (maybe I missed it?). Namely, if you allow say /28 announcements, then what would be the impact of ROV? Seems this can cause few problems: - If origin, say AS 10, makes a ROA for the /28, this would allow an attacker, e.g., AS 666, to do origin-hijack (announce path 666-10 to the /28), and attract traffic for the /28 from anybody accepting /28 announcements (that didn't receive the legit announcement). Plus, of course, you get more overhead in ROA distribution and validation. - If origin makes a ROA only for covering prefix (say /24) then the /28 announcement would be considered invalid by ROV and (even more likely) dropped. Also you get more instances of `invalid' announcements, making adoption of ROVs and ROAs harder. Just a thought... Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/cybersecurity On Wed, Jan 25, 2023 at 1:17 PM Lars Prehn wrote: > We performed some high-level analyses on these hyper-specific prefixes > about a year ago and pushed some insights into a blog post [1] and a paper > [2]. > > While not many ASes redistribute these prefixes, some accept and use them > for their internal routing (e.g., NTT's IPv4 filtering policy [3]). Rob > already pointed out that this is often sufficient for many traffic > engineering tasks. In the remaining scenarios, announcing a covering /24 > and hyper-specific prefixes may result in some traffic engineering, even if > the predictability of the routing impact is closer to path prepending than > usual more-specific announcements. In contrast to John's claim, some > transit ASes explicitly enabled redistributions of up to /28s for their > customers upon request (at least, they told us so during interviews). > > Accepting and globally redistributing all hyper-specifics increases the > routing table size by >100K routes (according to what route collectors > see). There are also about 2-4 de-aggregation events every year in which > some origin (accidentally) leaks some large number of hyper-specifics to > its neighbours for a short time. > > Best regards, > Lars > > [1] > https://blog.apnic.net/2022/09/01/measuring-hyper-specific-prefixes-in-the-wild/ > [2] https://dl.acm.org/doi/pdf/10.1145/3544912.3544916 > [3] https://www.gin.ntt.net/support-center/policies-procedures/routing/ > > > On 25.01.23 05:12, Forrest Christian (List Account) wrote: > > I have two thoughts in relation to this: > > 1) It's amazing how many threads end up ending in the (correct) summary > that making an even minor global change to the way the internet works > and/or is configured to enable some potentially useful feature isn't likely > to happen. > > 2) I'd really like to be able to tag a BGP announcement with "only use > this announcement as an absolute last resort" so I don't have to break my > prefixes in half in those cases where I have a backup path that needs to > only be used as a last resort. (Today each prefix I have to do this with > results in 3 prefixes in the table where one would do). > > And yes. I know #2 is precluded from actually ever happening because of > #1. The irony is not lost on me. > > > On Tue, Jan 24, 2023, 7:54 PM John Levine wrote: > >> It appears that Chris J. Ruschmann said: >> >-=-=-=-=-=- >> >How do you plan on getting rid of all the filters that don’t accept >> anything less than a /24? >> > >> >In all seriousness If I have these, I’d imagine everyone else does too. >> >> Right. Since the Internet has no settlements, there is no way to >> persuade a network of whom you are not a customer to accept your >> announcements if they don't want to, and even for the largest >> networks, that is 99% of the other networks in the world. So no, >> they're not going to accept your /25 no matter how deeply you believe >> that they should. >> >> I'm kind of surprised that we haven't seen pushback against sloppily >> disaggregated announcements. It is my impression that the route table >> would be appreciably smaller if a few networks combined adjacent a >> bunch of /24's into larger blocks. >> >> R's, >> John >> >
Question re prevention of enumeration with DNSSEC (NSEC3, etc.)
Hi NANOGers, I have a small question re DNSSEC `proof of non-existence' records: NSEC, NSEC3 and the (dead?) NSEC5 proposal. NSEC3 was motivated as a method to prevent Zone enumeration, then Berenstein showed its defense is pretty weak. RFC7129 (White Lies) prevents this enumeration attack but requires online signing with the zone's key, which introduces another vulnerability and, of course, overhead of online-signing. NSEC5 was proposed to prevent enumeration without online signing, so arguably more secure than RFC7129, but has comparable online overhead and appears `dead'; the I-D expired (last update July'17). Note that NSEC3 also supports `opt-out', which reduces overhead for adoptions in domains with many non-adopting ASes, and I believe is not supported by NSEC. Questions: - Do you find zone enumeration a real concern? - Do you think the white-lies countermeasure is sufficient and fine, or do you have security and/or performance concern (or just think it's pointless)? - and the final question... would you think an alternative to NSEC5 which will be more efficient and simpler would be of potential practical importance, or just a nice academic `exercise'? I'm really unsure about these questions - esp. the last one - and your feedback may help me decide on the importance of this line of research. Just fun or of possible practical importance? thanks and peace, Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook <https://sites.google.com/site/amirherzberg/applied-crypto-textbook>
Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times
Hi Matthew and NANOG, I don't want to defend prepending 255 times, and can understand filtering of extra-prepended-announcements, but I think Matthew may not be correct here: > Anyone that is prepending to do traffic engineering is > doing *differential* prepending; that is, a longer number > of prepends along one path, with a shorter set of prepends > along a different path. > > So, dropping the inbound announcement with 255 prepends > merely means your router will look for the advertisement with > a shorter number of prepends on it. > Right. But let's consider the (typical) case where someone is prepending for traffic engineering. Now, if you're not very near to the origin of the prepended announcement, and still received it (and not the shorter alternative), then it is quite likely that you received it since the alternate path failed - and the backup path was announced, instead (by upstreams of the origin). So your router is quite likely not to receive the shorter announcement. After all, if your router received both short and long announcements (from same relationship, e.g., both from providers), then your router would probably select the shorter path anyway, without need to filter out the long one, right? So, filtering announcements with many prepends may cause you to lose connectivity to these networks. Of course, you may not mind losing connectivity to Kazakhstan :) ... best, Amir > > > -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook <https://sites.google.com/site/amirherzberg/applied-crypto-textbook> On Fri, Mar 25, 2022 at 8:19 PM Matthew Petach wrote: > > > On Fri, Mar 25, 2022 at 2:59 PM Adam Thompson > wrote: > >> Tom, how exactly does someone “ride the 0/0” train in the DFZ? >> > > It's not so much "ride the 0/0 train" as much as it is > "treat excessive prepends as network-unreachable" > > Think of prepends beyond say 10 prepends as a way > to signal "infinite" distance--essentially, "unreachable" > for that prefix along that path. > > Anyone that is prepending to do traffic engineering is > doing *differential* prepending; that is, a longer number > of prepends along one path, with a shorter set of prepends > along a different path. > > So, dropping the inbound announcement with 255 prepends > merely means your router will look for the advertisement with > a shorter number of prepends on it. > > If you're only announcing one path for your prefix, and it is > prepended 255 times, you're fundamentally not understanding > how BGP works, and the only way to get a clue-by-four might > be to discover you've made your prefix invisible to a significant > portion of the internet. > > >> >> >> I’m connected to both commercial internet and NREN, and >> unfortunately-long paths are not uncommon in this scenario, in order to do >> traffic steering. If there’s another solution that affects global >> *inbound* traffic distributions, I’d love to hear about it (and so would >> a lot of my peers in edu). >> >> >> >> If there were a usable way to “dump” the excessively-long path only as >> long as a better path was already known by at least one edge router, that >> might be workable, but you’d have to keep track of it somewhere to >> reinstall it if the primary route went away… at which point you may as well >> have not dropped it in the first place. >> >> > You dump the excessively-long path based on the assumption that > the only reason for a long set of prepends out one path is to shift > traffic > away from that path to one that you're advertising out with a *shorter* > set of prepends. > > The router doesn't need to 'look' for or 'keep track' of the different > path; the human makes the decision that any sane BGP speaker > would only prepend 255 times on a path if there was a shorter > as-path advertisement they wanted people to use instead. > > So, drop the excessively long prepended path, and make use > of the 'should be in the table somewhere' advertisement of the > prefix with fewer prepends. > > Easy-peasy. > > >> >> >> -Adam >> >> >>
off-topic: net-sec presentations (routing, DNS, and DoS)
Hi NANOGers, I've updated my DoS presentation - will begin teaching this topic tomorrow. It's in my website, together with the other network-security presentations I gave this term, mainly DNS and routing security; there are few more topics I'll cover this term, to be added soon. And, of course, there's also my `applied intro to crypto' and related presentations. Anybody interested and/or willing to provide constructive feedback is always welcome - and feedback (even less constructive :) ) is highly appreciated. However, please send me directly, this is off-topic enough and nanog isn't the forum to discuss. Unless there's something you really think of interest to the entire community, of course. Peace (hopefully, in Ukraine too), Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook <https://sites.google.com/site/amirherzberg/applied-crypto-textbook>
off-topic: applied crypto textbook - SSL/TLS chapter (and more)
Hi friends, if you don't mind an off-topic message... I've just updated my draft `Applied Introduction to Cryptography' textbook, available at: https://sites.google.com/site/amirherzberg/applied-crypto-textbook <https://sites.google.com/site/amirherzberg/applied-crypto-textbook> Mainly , I've extended the SSL/TLS chapter, it's roughly done now, covering the different versions and several important attacks. Enjoy, send comments, etc.; and if you think I shouldn't have sent such off-topic message - accept my apologies, I indeed wasn't sure, and tell me off-list to avoid additionally bothering the list, I promise that I'll respect this feedback. best, Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home
Re: Need for historical prefix blacklist (`rogue' prefixes) information
I am very grateful for the help I received from several people (mostly off list, which is great to avoid spamming the list). In particular, +Giotsas, Vasileios , introduced by Joe Provo, provided a wonderful RIPE resource which provides convenient API to data from (at least) UCEprotect and SpamHaus, perfectly meeting out current needs: https://stat.ripe.net/docs/data_api#blocklist. Let me also use this email to briefly comment on two points from Matthew Walster's posts; and Matthew, I really come at peace, I have a lot of respect for you and your work, but we can also disagree on some things, right? So: 1. Matthew's email basically seemed to imply intentional hijacks are not a concern (rare/non-existent?). Few measurement works seem to show the contrary; I esp. recommend the `Profiling BGP serial hijackers' paper from IMC'19 by a team of excellent researchers. 2. A bit off-topic, Matthew's response to Dora Crisan seem to imply BGP eavesdropping for eventual cryptanalysis, possibly using Quantum computing, isn't a concern. On the one hand, I agree that Quantum computing seems still quite far from ability to break state-of-art PKC, and it may long till it becomes practical (if ever). OTOH, it may also not take that long; also, `conventional' cryptanalysis may still happen, e.g., see Schnorr's recent paper, ia.cr/2021/232, which claimed to `destroy' RSA [withdrawn later, so apparently even Schnorr can err - that's part of science - but this doesn't mean next effort won't succeed or that some TLA (three lettered adversaries) didn't succeed already]. TLAs may have other motivations for eavesdropping, like collecting meta-data. Now, I am sure many customers and providers may not care about security against such TLAs, but I think it is legitimate for some people to be concerned. Best, Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook <https://sites.google.com/site/amirherzberg/applied-crypto-textbook> On Thu, Oct 28, 2021 at 7:48 PM Amir Herzberg wrote: > Hi NANOGers, for our research on ROV (and ROV++, our extension, NDSS'21), > we need access to historical data of blacklisted prefixes (due to spam, > DDoS, other), as well as suspect-hijacks list (beyond BGPstream which we > already have). > > Basically we want to measure if the overlap (and non-overlap) btw such > `suspect' prefixes and ROV-Invalid prefixes. > > Any help would be appreciated. I'm not sure the list would be interested > so I recommend you respond to me privately; if there are useful responses, > I could post a summary to the list after few days (of collecting responses, > if any). > > thanks and regards... Amir > -- > Amir Herzberg > > Comcast professor of Security Innovations, Computer Science and > Engineering, University of Connecticut > Homepage: https://sites.google.com/site/amirherzberg/home > `Applied Introduction to Cryptography' textbook and lectures: > https://sites.google.com/site/amirherzberg/applied-crypto-textbook > <https://sites.google.com/site/amirherzberg/applied-crypto-textbook> > > >
Re: Need for historical prefix blacklist (`rogue' prefixes) information
recommend you respond to me privately; if there are useful responses, >> I could post a summary to the list after few days (of collecting responses, >> if any). >> > > I would strongly encourage engaging with the IETF ( > https://datatracker.ietf.org/wg/sidrops/about/ et al) who are much more > likely to be able to point you in the right direction. > Thanks - I agree, it'll be good idea to ask there (too). Best, Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook <https://sites.google.com/site/amirherzberg/applied-crypto-textbook> On Fri, Oct 29, 2021 at 8:13 AM Matthew Walster wrote: > Hi, > > On Fri, 29 Oct 2021 at 00:48, Amir Herzberg wrote: > >> Hi NANOGers, for our research on ROV (and ROV++, our extension, NDSS'21), >> we need access to historical data of blacklisted prefixes (due to spam, >> DDoS, other), as well as suspect-hijacks list (beyond BGPstream which we >> already have). >> > > I read your paper. I note "ROV provides disappointing security benefits". > I think we all know that ROV provides very little in the way of security > from deliberate hijack without the protection of BGPsec as you later point > out in your paper. > > What you seem to have failed to understand is that most traffic hijacks > on the internet are not malicious in nature, they are "fat finger" > incidents where someone has accidentally announced something they did not > intend to, either because of faulty software (the infamous "BGP optimizer") > or someone leaking internal "blocks" such as the Pakistan/YouTube incident > -- certifying the origin of a prefix allows you to mitigate most of this as > the origin AS will change. Anyone seen deliberately causing hijacks is > likely to be depeered very quickly -- commercial pressure rather than > technical. > > Likewise, the core purpose of ROV is not to secure the entire address > space. It is (as I understand it) to prevent *your* address space from > being stolen, and to prevent your network from being affected by false > advertisements. The superprefix attacks you mention are pretty much > theoretical only at this time, because of the maximum prefix length > attribute and the nature of peering in that networks either tend to be > adjacent (therefore very low AS Path) or via transit (and most transit > providers deploy ROV validation). It's true that traffic could be re-routed > if the longer prefixes are not advertised to all parties, but that would > also come under the AS Path length case. > > Hijacking a prefix is not useful unless you can do something with it, > either to hand out to customers (in which case, the prefix is going to be > sufficiently ignored around the internet that it's not practically useful) > or to engage in denial of service activities in which case there are far > easier measures to use. > > >> Any help would be appreciated. I'm not sure the list would be interested >> so I recommend you respond to me privately; if there are useful responses, >> I could post a summary to the list after few days (of collecting responses, >> if any). >> > > I would strongly encourage engaging with the IETF ( > https://datatracker.ietf.org/wg/sidrops/about/ et al) who are much more > likely to be able to point you in the right direction. > > Matthew Walster >
Need for historical prefix blacklist (`rogue' prefixes) information
Hi NANOGers, for our research on ROV (and ROV++, our extension, NDSS'21), we need access to historical data of blacklisted prefixes (due to spam, DDoS, other), as well as suspect-hijacks list (beyond BGPstream which we already have). Basically we want to measure if the overlap (and non-overlap) btw such `suspect' prefixes and ROV-Invalid prefixes. Any help would be appreciated. I'm not sure the list would be interested so I recommend you respond to me privately; if there are useful responses, I could post a summary to the list after few days (of collecting responses, if any). thanks and regards... Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook <https://sites.google.com/site/amirherzberg/applied-crypto-textbook>
Re: uPRF strict more
Randy, great question. I'm teaching that it's very rarely, if ever, used (due to high potential for benign loss); it's always great to be either confirmed or corrected... So if anyone replies just to Randy - pls cc me too (or, Randy, if you could sum up and send to list or me - thanks!) Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook <https://sites.google.com/site/amirherzberg/applied-crypto-textbook> On Tue, Sep 28, 2021 at 8:50 PM Randy Bush wrote: > do folk use uPRF strict mode? i always worried about the multi-homed > customer sending packets out the other way which loop back to me; see > RFC 8704 §2.2 > > do vendors implement the complexity of 8704; and, if so, do operators > use it? > > clue bat please > > randy >
Re: Reminder: Never connect a generator to home wiring without transfer switch
> > In theory, Jay is correct, but assuming that theory will always work in > practice is, in this case, how linemen end up dead. We're all well aware of > never assuming theory = practice, but admittedly the stakes tend to be a > little lower in our world. > right. my grandpa was a high-voltage/wattage engineer. He always said, `an engineer can make an error, but only once'. Luckily, we can make many errors :) -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook <https://sites.google.com/site/amirherzberg/applied-crypto-textbook> On Wed, Aug 25, 2021 at 1:55 PM Matt Erculiani wrote: > In theory, Jay is correct, but assuming that theory will always work in > practice is, in this case, how linemen end up dead. We're all well aware of > never assuming theory = practice, but admittedly the stakes tend to be a > little lower in our world. > > Ensuring that a generator physically cannot backfeed is just one layer of > protection against the already very high risk of the job of a lineman. Then > there is, of course, checking for the presence of voltage before starting > work, but it's possible for a generator to start AFTER this check. > > Another layer of protection is grounding all conductors prior to beginning > work, so that if power does come back (via the grid or a backfeed) A: The > lineman and bucket is not the best path to ground and B: The source is > tripped. > > Reading through that forum post, it sounds like that particular contractor > had a reputation for lacking proper safety precautions, so one or more > safety layers may have been removed, making the risk/impact of any single > mistake much greater than it should be. > > -Matt > > On Wed, Aug 25, 2021 at 11:25 AM Mel Beckman wrote: > >> Jay, >> >> No, because transformers work in both directions :) >> >> Plus, to the previous commenter that talked about “suicide cords”: >> they’’re more correctly termed “homicide cords”: >> >> “ The lineman killed yesterday was working for Pike Electric and picked >> up a line that was connected to someones house that hooked up a generator >> and did not disconnect from the distribution system. The linemans name was >> Ronnie Adams, age unknown. He had two children and a wife. As far as I know >> he was from Louisiana. They are trying to set up a fund for his family, but >> nothing I have heard of yet. I will let yall know more as I hear of it. I >> wish they would really teach folks the proper connection of generators, >> this was a really tragic and preventable accident. Stay Safe and think >> about it before you do it.” >> >> https://powerlineman.com/lforum/showthread.php?711-Storm-Death >> >> -mel >> >> On Aug 25, 2021, at 10:12 AM, Jay Hennigan wrote: >> >> On 8/25/21 07:04, Mark Tinka wrote: >> >> On 8/25/21 15:59, Ethan O'Toole wrote: >> >> >> How would this not load the generator or inverter into oblivion? >> >> Not sure I understand your question. Say again, please. >> >> >> If you fail to isolate your generator from the incoming utility feed so >> that you're back-feeding the utility and the power is out for your >> neighborhood or the whole city, would not the load of trying to light up >> the whole town completely overwhelm your little generator to the point that >> it fails, stalls, or trips its own output breaker? >> >> -- >> Jay Hennigan - j...@west.net >> Network Engineering - CCIE #7880 >> 503 897-8550 - WB6RDV >> >> > > -- > Matt Erculiani > ERCUL-ARIN >
Re: "Tactical" /24 announcements
Tom, I also referred to the same text from 7454! But Baldur is right: the text does NOT clearly state that announcement more specific than /24 should be filtered. If you allow different operators to filter at different lengths, you can get disconnections. We never like to standards to be fixed to some number, but this seems necessary (to me). -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook <https://sites.google.com/site/amirherzberg/applied-crypto-textbook> On Fri, Aug 13, 2021 at 5:05 PM Tom Beecher wrote: > I think that the NANOG (or in general, operators) community may do well to >> state the `/24 rule' clearly in a BCP, preferably an RFC. >> > > https://datatracker.ietf.org/doc/html/rfc7454 > > 6.1.3 <https://datatracker.ietf.org/doc/html/rfc7454#section-6.1.3>. >> Prefixes That Are Too Specific >> Most ISPs will not accept advertisements beyond a certain level of >> specificity (and in return, they do not announce prefixes they >> consider to be too specific). That acceptable specificity is decided >> for each peering between the two BGP peers. Some ISP communities >> have tried to document acceptable specificity. This document does >> not make any judgement on what the best approach is, it just notes >> that there are existing practices on the Internet and recommends that >> the reader refer to them. As an example, the RIPE community has >> documented that, at the time of writing of this document, IPv4 >> prefixes longer than /24 and IPv6 prefixes longer than /48 are >> generally neither announced nor accepted in the Internet [20 >> <https://datatracker.ietf.org/doc/html/rfc7454#ref-20>] [21 >> <https://datatracker.ietf.org/doc/html/rfc7454#ref-21>]. >>These values may change in the future. > > > On Fri, Aug 13, 2021 at 4:54 PM Amir Herzberg > wrote: > >> On Fri, Aug 13, 2021 at 12:50 PM Baldur Norddahl < >> baldur.nordd...@gmail.com> wrote: >> >>> >>> On Fri, Aug 13, 2021 at 3:54 AM Amir Herzberg >>> wrote: >>> >>>> On Thu, Aug 12, 2021 at 4:32 PM Baldur Norddahl < >>>> baldur.nordd...@gmail.com> wrote: >>>> >>>>> >>>>> >>>>> On Thu, Aug 12, 2021 at 7:39 PM Amir Herzberg >>>>> wrote: >>>>> >>>>>> Bill, I beg to respectfully differ, knowing that I'm just a >>>>>> researcher and working `for real' like you guys, so pls take no offence. >>>>>> >>>>>> I don't think A would be right to filter these packets to 10.0.1.0/24; >>>>>> A has announced 10.0.0.0/16 so should route to that (entire) prefix, >>>>>> or A is misleading its peers. >>>>>> >>>>> >>>>> You are right that it is wrong but it happens. Some years back I tried >>>>> a setup where we wanted to reduce the size of the routing table. We >>>>> dropped >>>>> everything but routes received from peers and added a default to one of >>>>> our >>>>> IP transit providers. This should have been ok because either we had a >>>>> route to a peer or the packet would go to someone who had the full routing >>>>> table, yes? >>>>> >>>> >>>> Baldur, thanks, but, sorry, this isn't the same, or I miss something. >>>> >>> >>> I think it is exactly the same? Our peer is advertising a prefix for >>> which they will not route all addresses covered. Is that route not then a >>> lie? Should they not have exploded the prefix so they could avoid covering >>> the part of the prefix they will not accept traffic to? (ps: not arguing >>> they should!) >>> >> >> I think it isn't the same. This scenario, of an AS selling part of its IP >> block, e.g., 10.0.1.0/24, and continuing to announce the block, e.g., >> 10.0.0.0/16, is the classical example used (e.g. by me) to explain the >> `most specific' rule. Due to `most specific', it is considered, imho, legit >> to continue to announce 10.0.0.0/16; if 10.0.1.0/24 is reachable, >> traffic will route to it anyway due to `more specific', so no problem; and >> if 10.0.1.0/24 isn't reachable, then anyway no harm done... >> >> By dropping a legit 10.0.1.0/24 announcement, you may - and in the cited >>
Re: "Tactical" /24 announcements
On Fri, Aug 13, 2021 at 12:50 PM Baldur Norddahl wrote: > > On Fri, Aug 13, 2021 at 3:54 AM Amir Herzberg > wrote: > >> On Thu, Aug 12, 2021 at 4:32 PM Baldur Norddahl < >> baldur.nordd...@gmail.com> wrote: >> >>> >>> >>> On Thu, Aug 12, 2021 at 7:39 PM Amir Herzberg >>> wrote: >>> >>>> Bill, I beg to respectfully differ, knowing that I'm just a researcher >>>> and working `for real' like you guys, so pls take no offence. >>>> >>>> I don't think A would be right to filter these packets to 10.0.1.0/24; >>>> A has announced 10.0.0.0/16 so should route to that (entire) prefix, >>>> or A is misleading its peers. >>>> >>> >>> You are right that it is wrong but it happens. Some years back I tried a >>> setup where we wanted to reduce the size of the routing table. We dropped >>> everything but routes received from peers and added a default to one of our >>> IP transit providers. This should have been ok because either we had a >>> route to a peer or the packet would go to someone who had the full routing >>> table, yes? >>> >> >> Baldur, thanks, but, sorry, this isn't the same, or I miss something. >> > > I think it is exactly the same? Our peer is advertising a prefix for which > they will not route all addresses covered. Is that route not then a lie? > Should they not have exploded the prefix so they could avoid covering the > part of the prefix they will not accept traffic to? (ps: not arguing they > should!) > I think it isn't the same. This scenario, of an AS selling part of its IP block, e.g., 10.0.1.0/24, and continuing to announce the block, e.g., 10.0.0.0/16, is the classical example used (e.g. by me) to explain the `most specific' rule. Due to `most specific', it is considered, imho, legit to continue to announce 10.0.0.0/16; if 10.0.1.0/24 is reachable, traffic will route to it anyway due to `more specific', so no problem; and if 10.0.1.0/24 isn't reachable, then anyway no harm done... By dropping a legit 10.0.1.0/24 announcement, you may - and in the cited example, did - break connectivity, imho. And quite unnecessarily, too. > > >> If I get you right, you dropped all announcements from _providers_ except >> making one provider your default gateway (essentially, 0.0.0.0/0). But >> this is very different from what I understood from what Bill wrote. Your >> change could (and, from what you say next, did) cause a problem if one of >> these announcements you dropped from providers was a legit subprefix of a >> prefix announced by one of your peers, causing you to route to the peer >> traffic whose destination is in the subprefix. >> > > Your understanding is correct. But this is just the way we ended up in > that situation. Does not change the fact that we got a route from a peer > that we believed we could use, but turns out part of that announcement was > a lie. > Was not a lie, as I explained. > > Consider that everyone filters received routes. The most common is to > filter at the /24 level but nowhere is there a RFC stating that /24 is > anything special. > Oh that's a point I was quite annoyed with for years - who said one should drop prefixes longer than /24 ??? And I searched for it, and indeed found no RFC. But I did find it mentioned in some BCPs! Unfortunately and stupidly, I didn't save these sources, but I did a quick google now and found https://nsrc.org/workshops/2018/linx103-bgp/networking/peering-ixp/en/presentations/05-BGP-BCP.pdf But that was years ago, and indeed, I also found mention in RFC 7454: > 6.1.3 <https://www.rfc-editor.org/rfc/rfc7454.html#section-6.1.3>. Prefixes > That Are Too Specific > >Most ISPs will not accept advertisements beyond a certain level of >specificity (and in return, they do not announce prefixes they >consider to be too specific). That acceptable specificity is decided >for each peering between the two BGP peers. Some ISP communities >have tried to document acceptable specificity. This document does >not make any judgement on what the best approach is, it just notes >that there are existing practices on the Internet and recommends that >the reader refer to them. As an example, the RIPE community has >documented that, at the time of writing of this document, IPv4 >prefixes longer than /24 and IPv6 prefixes longer than /48 are >generally neither announced nor accepted in the Internet [20 > <https://www.rfc-editor.org/rfc/rfc7454.html#ref-20>] [21 > <https://www.rfc-editor.org/rfc/rfc7454.html#ref-21>]. >These values may change in the future. > > I also did
Re: "Tactical" /24 announcements
On Thu, Aug 12, 2021 at 4:32 PM Baldur Norddahl wrote: > > > On Thu, Aug 12, 2021 at 7:39 PM Amir Herzberg > wrote: > >> Bill, I beg to respectfully differ, knowing that I'm just a researcher >> and working `for real' like you guys, so pls take no offence. >> >> I don't think A would be right to filter these packets to 10.0.1.0/24; A >> has announced 10.0.0.0/16 so should route to that (entire) prefix, or A >> is misleading its peers. >> > > You are right that it is wrong but it happens. Some years back I tried a > setup where we wanted to reduce the size of the routing table. We dropped > everything but routes received from peers and added a default to one of our > IP transit providers. This should have been ok because either we had a > route to a peer or the packet would go to someone who had the full routing > table, yes? > Baldur, thanks, but, sorry, this isn't the same, or I miss something. If I get you right, you dropped all announcements from _providers_ except making one provider your default gateway (essentially, 0.0.0.0/0). But this is very different from what I understood from what Bill wrote. Your change could (and, from what you say next, did) cause a problem if one of these announcements you dropped from providers was a legit subprefix of a prefix announced by one of your peers, causing you to route to the peer traffic whose destination is in the subprefix. But let me be concrete using what you wrote: > > So we got complaints. One was a company who would advertise a /20 on a > peering with us. But somewhere else far away they had a site from where > they would announce a /24 from the same prefix. With no internal routing > between the peering site with the /20 to the other site with the /24. We > therefore lost the ability to communicate with that /24. > exactly; but this is since you incorrectly dropped the subprefix announcement which you evidently received from one of your providers. If this analysis is correct, you could have solved the problem - reducing the FIB while avoiding such loss of connectivity - if you retained (only) the announcements from your providers which were to subprefixes of announcements you got from your peers. A bit of scripting required, of course... I'm sure you can do it 100 times faster and better than me :) > > You see variants of this. For example a large telco has a /16 from which > they many years ago allocated a /24 to a multihomed customer. This customer > left but took their /24 with them. This fact will seldom make the large > telco split up their /16. They will keep it as a /16 but will no longer > route to that /24. The question is also if we really would want a large > telco to explode a large subnet due to this case. > No way, agreed! But, as I explained, it's also unnecessary; I mean, that's exactly why we do `most specific' routing. Just don't kill the subprefix announcement! btw... yes, this is a possible issue with ROV, when sometimes there's a ROA for a prefix (say /16) but no roa to a (legitimately announced) subprefix (e.g. /20). We show such case in our 2015 ROV paper, and also measured how many such issues exist; it appears their number is much reduced now, based on more recent measurements. (ah and here, our ROV++ doesn't help; in fact, it would disconnection even more likely than with ROV, since ROV protection against subprefix hijacks is rather weak). Regards, -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook <https://sites.google.com/site/amirherzberg/applied-crypto-textbook> >
Re: "Tactical" /24 announcements
On Thu, Aug 12, 2021 at 1:22 PM William Herrin wrote: > On Thu, Aug 12, 2021 at 9:41 AM Hank Nussbacher > wrote: > > On 12/08/2021 17:59, William Herrin wrote: > > > If you prune the routes from the Routing Information Base instead, for > > > any widely accepted size (i.e. /24 or shorter netmask) you break the > > > Internet. > > > > How does this break the Internet? I would think it would just result in > > sub-optimal routing (provided there is a covering larger prefix) but > > everything should continue to work. Clue me in, please. > > A originates 10.0.0.0/16 to paid transit C > B originates 10.0.1.0/24 also to paid transit C > C offers both routes to D. D discards 10.0.1.0/24 from the RIB based > on same-next-hop > You peer with A and D. You receive only 10.0.0.0/16 since A doesn't > originate 10.0.1.0/24 and D has discarded it. > You send packets for 10.0.1.0/24 to A (the shortest path for > 10.0.0.0/16), stealing A's paid transit to C to get to B. Unless A filters C-bound packets purportedly from 10.0.1.0/24. B > doesn't currently transit for A so from B's perspective that's not an > allowed path. In which case, your path to 10.0.1.0/24 is black holed. > Bill, I beg to respectfully differ, knowing that I'm just a researcher and working `for real' like you guys, so pls take no offence. I don't think A would be right to filter these packets to 10.0.1.0/24; A has announced 10.0.0.0/16 so should route to that (entire) prefix, or A is misleading its peers. If A doesn't, though, then B receives a packet from A to 10.0.1.0/24. Unless B is filtering based on the specific IP prefixes of A - which seems to me unlikely - then B has no way to know that this packet is from `you' rather than from A itself (or a customer of A). So B will carry this traffic, imho. So A is just paying for the traffic since it announced the prefix. Such situations, to best of my knowledge, actually happen on the Internet when a subprefix is filtered for different reasons. We observed it happens with ROV , in our ROV++ simulations, but I'll refrain from attaching the URL again so not to be `plugging' that paper (and since I'm lazy to look it up hhh) have great day and I'll be happy to learn if I'm wrong. Amir
Re: "Tactical" /24 announcements
On Thu, Aug 12, 2021 at 12:43 PM Hank Nussbacher wrote: > On 12/08/2021 17:59, William Herrin wrote: > > > If you prune the routes from the Routing Information Base instead, for > > any widely accepted size (i.e. /24 or shorter netmask) you break the > > Internet. > > How does this break the Internet? I would think it would just result in > sub-optimal routing (provided there is a covering larger prefix) but > everything should continue to work. Clue me in, please. > Hi Hank, I think you're right, it could result in sub-optimal routing and in particular, in your AS not being used for these subprefixes (the traffic will go instead to a competing provider who sent the subprefix), hence, as you said, sub-optimal routing. I think some people (maybe Bill included) may consider the resulting harm to routing to be sufficiently severe to consider this `breaking'. It becomes a judgement call, I guess. Cheers, Amir > > -Hank > >
Re: "Tactical" /24 announcements
Bill said, > > Is this seen as route table pollution, or a necessary evil in today's > world? > > Pollution. And it won't save you from a hijack either, since your > adversary's /24 routes will compete and win for at least part of the > Internet. > I agree, of course, that moving to announce every /24 would pollute the net. Note that if you use ROAs, you'll also have to make corresponding /24 ROAs, and I don't know if this won't have problematic impact also on the RPKI infrastructure. Not good. But: - assuming the /24 will have proper ROA, and ROV is reasonably deployed, this _would_ protect most of the traffic sent to the /24 from a hijacker announcing /24 (and even more if hijack is of shorter prefix, of course). - As long as ROV isn't _very_ widely deployed, it would often fail to protect against the hijack without such measure (competing /24), so this will remain necessary (if you wish to prevent hijack). We've done some relevant simulations, as well as proposed a simple extension to ROV, called ROV++, which protects against such sub-prefix hijacks without requiring competing /24 announcement, and effective already with modest adoption (of ROV++) by BGP routers. (Should also be assisted by mixed ROV / ROV++ adoption but we didn't do these simulations yet.) See at: https://www.ndss-symposium.org/ndss-paper/rov-improved-deployable-defense-against-bgp-hijacking/ tl; dr : ROV++ routers would blackhole subprefix traffic rather than send it on a route which would be hijacked (i.e., if the route is to a neighbor AS that announced legit prefix _and_ hijacked subprefix). Simple. [and no, I'm not happy with the resulting disconnections. but it's better than hijack imho] best, Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook <https://sites.google.com/site/amirherzberg/applied-crypto-textbook> On Mon, Aug 9, 2021 at 12:10 PM William Herrin wrote: > On Mon, Aug 9, 2021 at 8:48 AM Billy Croan > wrote: > > How does the community feel about using /24 originations in BGP as a > > tactical advantage against potential bgp hijackers? > > How many routers out there today would be affected if everyone did this? > > Hi Billy, > > I did some math on this years ago and it worked out to about 8.5 > million IPv4 routes. That's 10 times the current table size, more than > any big-iron router can handle today. If everybody did it, it'd crash > the Internet. > > > Is this seen as route table pollution, or a necessary evil in today's > world? > > Pollution. And it won't save you from a hijack either, since your > adversary's /24 routes will compete and win for at least part of the > Internet. > > > Are there any big networks that drop or penalize announcements like this? > > Not in an automated way. Which is bad news for you if you do this > because it means getting folks to -undo- the restrictions they > manually enforce on your specific address space is nearly impossible. > > Regards, > Bill Herrin > > -- > William Herrin > b...@herrin.us > https://bill.herrin.us/ >
Re: ROV++: Improved Deployable Defense against BGP Hijacking
ealistic measurement. I must admit - just didn't think of it. Stupid... Cecilia sent us a list and although it's just by email, we'll use it to do additional evaluation, Real Soon Now :) best, Amir -- Amir Herzberg Comcast professor of Security Innovations, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook <https://sites.google.com/site/amirherzberg/applied-crypto-textbook> On Wed, Dec 9, 2020 at 1:42 PM Lars Prehn wrote: > Hi Amir, > > Neither providing an abstract nor the high-level takeaways of your work is > a rather blunt way to promote your paper. I have a bunch of comments and > questions, but I'm only a student so take them with a grain of salt. > > Regarding ROV++ v1: Let's modify your example in Figure 2a slightly such > that AS 666 announces 1.2.3/24 also via AS 86. Further, let's say AS 88 > also uses ROV++ v1. Now, let's replay your example from the paper. AS 78 > still sees the same announcements you describe, and you recommend using a > different, previously less-preferred route for 1.2/16. Yet, all routes > available to AS 78 ultimately run into the same hijack behavior (which is > not visible from AS 78's routing table alone). In a nutshell, your > recommendation did not affect the outcome for 1.2.3/24---the traffic still > goes towards the hijacker---but you effectively moved all the remaining > traffic inside 1.2/16 from an optimal route to a sub-optimal one. Your > approach not only may have no effects on the fate of the attacked traffic, > but it may also mess with previously unaffected traffic. > > Regarding ROV++ v2: A simple sub-prefix hijack would still not yield a > "valid" during your ROV. The moment you propagate such a route, you reject > the entire idea of ROV. I understand that you drop the traffic, but your > proposal still feels like a step backward. However, I'm not an expert on > this---I might just be wrong. > > Regarding goals: I think that you only meet your first design goal since > your definition of 'harm' is very restricted. The moment you add more > dimensions, e.g., QoS degradation for previously unaffected traffic, this > goal is no longer met. > > Regarding your evaluation: Which of CAIDA's serials do you use? Serial-1 > is known to miss a significant fraction of peering links, while Serial-2 > contains potentially non-existing links (as they are inferred using > heuristics). Since coverage and validity of links varies drastically > between serials (and for serial-2 even between snapshots), it is unclear to > which degree your topology reflects reality. I like that you assumed the > basic Gao-Rexford Model for the best-path decision process. Yet, you > ignored that various networks deploy things like prefix-aggregation, > peer-locking, or more-specifics (referring to /25 .. /30 IPv4 prefixes) > filters. Further, I do not get why you randomly picked ROV-deploying > networks. I am sure people like Job Snijders or Cecilia Testart could have > provided you an up-to-date list of ASes that currently deploy ROV. It is > not clear to me why it is useful to look at scenarios in which those > networks potentially no longer deploy ROV. > > Those are at least my thoughts. I hope they initiate some discussion. > Best regards, > Lars > On 09.12.20 09:04, Amir Herzberg wrote: > > Hi, the paper: > ROV++: Improved Deployable Defense against BGP Hijacking > will be presented in the NDSS'21 conference. > > The paper is available in: > > https://www.researchgate.net/publication/346777643_ROV_Improved_Deployable_Defense_against_BGP_Hijacking > > Feedback, by discussion here or by direct email to me, is welcome, thanks. > > btw, I keep most publications there (researchgate), incl. the drafts of > `foundations of cybersecurity' ; the 1st part (mostly applied crypto) is in > pretty advanced stage, feedback is also very welcome. URL in sig. > -- > Amir Herzberg > > Comcast professor of Security Innovations, University of Connecticut > > Homepage: https://sites.google.com/site/amirherzberg/home > > Foundations of Cyber-Security (part I: applied crypto, part II: > network-security): > https://www.researchgate.net/project/Foundations-of-Cyber-Security > > >
Re: ROV++: Improved Deployable Defense against BGP Hijacking
Lars, peace, and thanks for your comments. The reason that I didn't include the abstract is that this list , to my understanding, is mostly for operational issues and discussions btwl operators, and I didn't want to annoy subscribers by excessive text on an academic paper. For the same reason, I'm hesitant in responding to such technical questions on this list, unless people are really interested in us doing this here; maybe we should do such discussion off list? [I also have a bit of crazy schedule in rest of this week and next, so I may be unable to response promptly as I normally do; btw part of it is for giving tutorial on PKI and participating in the CANS conference, if anybody interested, it's free ; not that I understand why I agreed to do it :) Cheers, Amir -- Amir Herzberg Comcast professor of Security Innovations, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home Foundations of Cyber-Security (part I: applied crypto, part II: network-security): https://www.researchgate.net/project/Foundations-of-Cyber-Security On Wed, Dec 9, 2020 at 1:42 PM Lars Prehn wrote: > Hi Amir, > > Neither providing an abstract nor the high-level takeaways of your work is > a rather blunt way to promote your paper. I have a bunch of comments and > questions, but I'm only a student so take them with a grain of salt. > > Regarding ROV++ v1: Let's modify your example in Figure 2a slightly such > that AS 666 announces 1.2.3/24 also via AS 86. Further, let's say AS 88 > also uses ROV++ v1. Now, let's replay your example from the paper. AS 78 > still sees the same announcements you describe, and you recommend using a > different, previously less-preferred route for 1.2/16. Yet, all routes > available to AS 78 ultimately run into the same hijack behavior (which is > not visible from AS 78's routing table alone). In a nutshell, your > recommendation did not affect the outcome for 1.2.3/24---the traffic still > goes towards the hijacker---but you effectively moved all the remaining > traffic inside 1.2/16 from an optimal route to a sub-optimal one. Your > approach not only may have no effects on the fate of the attacked traffic, > but it may also mess with previously unaffected traffic. > > Regarding ROV++ v2: A simple sub-prefix hijack would still not yield a > "valid" during your ROV. The moment you propagate such a route, you reject > the entire idea of ROV. I understand that you drop the traffic, but your > proposal still feels like a step backward. However, I'm not an expert on > this---I might just be wrong. > > Regarding goals: I think that you only meet your first design goal since > your definition of 'harm' is very restricted. The moment you add more > dimensions, e.g., QoS degradation for previously unaffected traffic, this > goal is no longer met. > > Regarding your evaluation: Which of CAIDA's serials do you use? Serial-1 > is known to miss a significant fraction of peering links, while Serial-2 > contains potentially non-existing links (as they are inferred using > heuristics). Since coverage and validity of links varies drastically > between serials (and for serial-2 even between snapshots), it is unclear to > which degree your topology reflects reality. I like that you assumed the > basic Gao-Rexford Model for the best-path decision process. Yet, you > ignored that various networks deploy things like prefix-aggregation, > peer-locking, or more-specifics (referring to /25 .. /30 IPv4 prefixes) > filters. Further, I do not get why you randomly picked ROV-deploying > networks. I am sure people like Job Snijders or Cecilia Testart could have > provided you an up-to-date list of ASes that currently deploy ROV. It is > not clear to me why it is useful to look at scenarios in which those > networks potentially no longer deploy ROV. > > Those are at least my thoughts. I hope they initiate some discussion. > Best regards, > Lars > On 09.12.20 09:04, Amir Herzberg wrote: > > Hi, the paper: > ROV++: Improved Deployable Defense against BGP Hijacking > will be presented in the NDSS'21 conference. > > The paper is available in: > > https://www.researchgate.net/publication/346777643_ROV_Improved_Deployable_Defense_against_BGP_Hijacking > > Feedback, by discussion here or by direct email to me, is welcome, thanks. > > btw, I keep most publications there (researchgate), incl. the drafts of > `foundations of cybersecurity' ; the 1st part (mostly applied crypto) is in > pretty advanced stage, feedback is also very welcome. URL in sig. > -- > Amir Herzberg > > Comcast professor of Security Innovations, University of Connecticut > > Homepage: https://sites.google.com/site/amirherzberg/home > > Foundations of Cyber-Security (part I: applied crypto, part II: > network-security): > https://www.researchgate.net/project/Foundations-of-Cyber-Security > > >
ROV++: Improved Deployable Defense against BGP Hijacking
Hi, the paper: ROV++: Improved Deployable Defense against BGP Hijacking will be presented in the NDSS'21 conference. The paper is available in: https://www.researchgate.net/publication/346777643_ROV_Improved_Deployable_Defense_against_BGP_Hijacking Feedback, by discussion here or by direct email to me, is welcome, thanks. btw, I keep most publications there (researchgate), incl. the drafts of `foundations of cybersecurity' ; the 1st part (mostly applied crypto) is in pretty advanced stage, feedback is also very welcome. URL in sig. -- Amir Herzberg Comcast professor of Security Innovations, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home Foundations of Cyber-Security (part I: applied crypto, part II: network-security): https://www.researchgate.net/project/Foundations-of-Cyber-Security
Re: "Is BGP safe yet?" test
Randy said, > > > From a practical standpoint, this doesn't actually tell the whole truth > > indeed. route origin validation, while a good thing, does not make > bgp safe from attack. this marketing fantasy is being propagated; > but is BS. > > origin validation was designed to reduce the massive number of problems > cause by fat figured configuration errors by operators. it will not > even get all of those; but it will greatly improve things. > > but it provides almost zero protection against malicious attack. the > attacker merely has to prepend (in the formal, not cisco display) the > 'correct' origin AS to their malicious announcement. > Randy, I agree of course, that supporting ROV is far from sufficient to ensure BGP security. However, I disagree that this is `zero protection' since the effectiveness of the attack may be much reduced when the attacker has to prepend. Note also that if one combines ASPA, the protection would be even better. The simulation results in our SIGCOMM'2016 give some idea of these benefits (imprecise, of course). I _think_ Randy will agree; but then again, Randy loves to surprise , so ... maybe not. -- Amir Herzberg Comcast professor of Security Innovations, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home Foundations of Cyber-Security (part I: applied crypto, part II: network-security): https://www.researchgate.net/project/Foundations-of-Cyber-Security On Mon, Apr 20, 2020 at 3:10 PM Randy Bush wrote: > > From a practical standpoint, this doesn't actually tell the whole truth > > indeed. route origin validation, while a good thing, does not make > bgp safe from attack. this marketing fantasy is being propagated; > but is BS. > > origin validation was designed to reduce the massive number of problems > cause by fat figured configuration errors by operators. it will not > even get all of those; but it will greatly improve things. > > but it provides almost zero protection against malicious attack. the > attacker merely has to prepend (in the formal, not cisco display) the > 'correct' origin AS to their malicious announcement. > > randy >
Re: backtracking forged packets?
Bill said: To be clear: the majority of the addresses at my end are not > associated with live hosts. There's nothing there to respond. > I forgot to ask/mention , but that's actually a common scenario. Of course in that case your router is _supposed_ to respond with ICMP host unreachable which would have similar impact to RST (but I bet it doesn't - which spec says to do it, many routers are not configured to do this). So attackers may idd have identified your address block as a good set of IP addresses to spoof when they attack different servers. It may help , if you configure your router to send ICMP unreachable (or RST, but that may be harder/less efficient, I think). Initially, this will cause the victim servers to stop re-sending you the syn/ack, so you'll feel some relief, and also you'll reduce the attack on these servers, which is A Good Deed. Eventually, hopefully, this may cause attackers to remove your IP prefix from their list of IP addresses which work well as spoofed source, but this will probably take quite a while. Sorry... > > My surprise about the lack of RSTs is the lack of RSTs from the remote > servers back to the addresses which have been spoofed. If the attacker > was hitting random ports on those hosts, I'd expect to see some RSTs. > yes, but I bet attacker is not hitting random ports, attacker is hitting real servers in TCP listen. (sorry don't have time to netflow... have tons of work to do) -- Amir Herzberg Comcast professor of Security Innovations, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home Foundations of Cyber-Security (part I: applied crypto, part II: network-security): https://www.researchgate.net/project/Foundations-of-Cyber-Security On Sun, Mar 15, 2020 at 12:50 PM William Herrin wrote: > On Sun, Mar 15, 2020 at 9:07 AM Amir Herzberg > wrote: > > Not sending RST could even result in you receiving ICMP unreachable - > esp. indicating filtering as you received - since server admins may have > installed a filter against your prefix (to deal with such abuse). So, I > wonder, it is possible that your network/FW/provider already filter the RST > responses so they don't reach the (victim) servers? > > Hi Amir, > > To be clear: the majority of the addresses at my end are not > associated with live hosts. There's nothing there to respond. > > My surprise about the lack of RSTs is the lack of RSTs from the remote > servers back to the addresses which have been spoofed. If the attacker > was hitting random ports on those hosts, I'd expect to see some RSTs. > > If you happen to have decent netflow, try looking for packets sourced > from 199.33.224.0/24. You'll find a legitimate route in your tables > ending at AS11875 but today, at least, there are no legitimate packets > sourced from that address block. > > Regards, > Bill > > > -- > William Herrin > b...@herrin.us > https://bill.herrin.us/ >
Re: backtracking forged packets?
Bill: I agree with Damian that you should try to ensure responding with RST to SYN/ACK; in fact, attackers are sometimes (often?) _looking_ for networks that do not send RST in response to unsolicited SYN/ACK, to spoof their addresses in syn-flooding and other attacks (eg., syn-ack) against victim servers. Not sending RST could even result in you receiving ICMP unreachable - esp. indicating filtering as you received - since server admins may have installed a filter against your prefix (to deal with such abuse). So, I wonder, it is possible that your network/FW/provider already filter the RST responses so they don't reach the (victim) servers? BTW, I'm covering these issues in my DoS lecture as part of the Net-Sec course (see URL below). The foils are available (although not yet latest version, will upload `soon' :) ), the text of the net-sec (2nd) part - not so much, it may take me quite a while to make this (2nd) part useable. -- Amir Herzberg Comcast professor of Security Innovations, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home Foundations of Cyber-Security (part I: applied crypto, part II: network-security): https://www.researchgate.net/project/Foundations-of-Cyber-Security On Sat, Mar 14, 2020 at 7:51 PM Damian Menscher via NANOG wrote: > I don't recommend filtering the SYN-ACK packets. That's what Octolus did, > and the result was leaving half-open SYN_RECV connections on all the nodes > used for reflection. That has two downsides: > > - the reflectors will retry the SYN-ACK (several times), which increases > your PPS load (amplifying the attack) > - the providers may notice the large number of SYN_RECV connections from > your network and put you on a blacklist > > I don't want to leave you with the impression that it's hopeless... these > attacks aren't impossible to stop --- it just requires convincing the > transit providers to care. > > Damian > > On Sat, Mar 14, 2020 at 1:31 PM Jean | ddostest.me via NANOG < > nanog@nanog.org> wrote: > >> Hi Bill, >> >> thanks for sharing the data. Indeed, I can't offer you a way to backtrack >> the spoofed packets. >> >> Anyway, I'm not sure what could you do legally as there is a very high >> chance that these people are not in the USA and the CFAA won't apply to >> them. >> >> Here is what I would do if I was in your situation. >> >> Since these packets are spoof and malformed, I would block all SYN/ACK >> based on the length. >> >> Depending on your hardware, it's very easy to inspect *only the SYN/ACK >> by length* if you have modern hardware. On linux/unix, it's also very >> straightforward. I'm not sure for windows though. >> >> Here is the details of the analysis: >> >> Today, all the SYN and SYN/ACK includes a minimum of options like MSS, >> WS, SACK, NOP (Only a spacer, sometimes 2) and extended TS. There might be >> others, but let's use the basic one. >> >> In your case, there are none. There is only MSS and the SYN length is 44 >> bytes. These are spoof packets maybe generated by either TCP-AMP like >> reported earlier. >> >> I would try to block all SYN/ACK coming toward your network with a length >> of 44 bytes or lower. But, this is weird because it should be 54 bytes. >> Maybe there is some offloading of some sort in your gear. >> >> Now depending on your hardware, it could work or it could kill your >> router as it will punt the cpu. I guess you have some modern gear. >> >> What I do when I am not sure about the length, I start to accept and log >> at 60 bytes, then 58, 56, 54... 44 until I catch the gremlins. >> >> Once you found the sweet spot, you drop all SYN/ACK toward your /23 lower >> than X bytes. It won't kill or block anything legitimate if you do it >> properly. :) >> >> What will happen is that you will not reply to these spoof SYN/ACK with a >> RST and still allowing RST for legit SYN and SYN/ACK. Akamai and your >> service providers will be happy and should not penalize you. >> >> I'm pretty sure that it will help you as it did for me in the past. >> >> Let me know if it's not clear and/or which part is foggy and I'll try to >> give more details and better explanation. >> >> Regards, >> >> Jean St-Laurent >> On 2020-03-14 11:46, William Herrin wrote: >> >> On Sat, Mar 14, 2020 at 4:02 AM Jean | ddostest.me via >> NANOG wrote: >> >> can you post some forged packets please? You can send them offlist if >> you prefer. >> >> Hi Jean, >> >> Here are a couple examples (PDT this morning): >> >> 08:22:43.413250
Re: a bit off-topic: ManTra'20 CFP
The first ACM SIGCOMM Workshop on Traffic Manipulation (ManTra’20) will be co-located with the ACM SIGCOMM conference and will be held at Columbia University, New York City, USA, Aug. 10-14, 2020 . I think it may be of interest to some of the NANOG community, to participate and/or submit; you may see some familiar (academic, mostly) names in the PC. There is not much time until the submission deadline of April 10. URL: https://conferences.sigcomm.org/sigcomm/2020/workshop-mantra.html Cheers, Amir Herzberg Comcast professor of Security Innovations, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home Foundations of Cyber-Security (part I: applied crypto, part II: network-security): https://www.researchgate.net/project/Foundations-of-Cyber-Security
Re: TCP-AMP DDoS Attack - Fake abuse reports problem
hhh well Damian, Ok, I guess a free service has some costs :) More seriously, did you try to follow up and explain how dropping your RST packets may be exactly the reason for the attacker to abuse your IP space for the attack? Also, you may ask the provider of the victim to block SYN packets from your IP range (assuming the victim isn't some service that your clients will want to access). If all fails then all failed. -- Amir Herzberg Comcast professor of Security Innovations, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home Foundations of Cyber-Security (part I: applied crypto, part II: network-security): https://www.researchgate.net/project/Foundations-of-Cyber-Security On Thu, Feb 20, 2020 at 11:21 PM Damian Menscher wrote: > Amir: you're exactly correct -- but since you asked, here's their answer > from the last time I suggested they respond with RSTs: > https://seclists.org/nanog/2020/Jan/612 > > Damian > > On Thu, Feb 20, 2020 at 5:36 PM Amir Herzberg > wrote: > >> If I read your description correctly: >> >> - Attacker sends spoofed TCP SYN from your IP address(es) and different >> src ports, to some TCP servers (e.g. port 80) >> - TCP servers respond with SYN/ACK ; many servers resend the SYN/ACK >> hence amplification . >> - *** your system does not respond *** >> - Servers may think you're doing SYN-Flood against them, since connection >> remains in SYN_RCVD, and hence complain. In fact, we don't really know what >> is the goal of the attackers; they may in fact be trying to do SYN-Flood >> against these servers, and you're just a secondary victim and not the even >> the target, that's also possible. >> >> Anyway, is this the case? >> >> If it is... may I ask, do you (or why don't you) respond to the >> unsolicited SYN/ACK with RST as per the RFC? >> >> I suspect you don't, maybe due to these packets being dropped by FW/NAT, >> that's quite common. But as you should understand by now from my text, this >> (non-standard) behavior is NOT recommended. The problem may disappear if >> you reconfigure your FW/NAT (or host) to respond with RST to unsolicited >> SYN/ACK. >> >> As I explained above, if my conjectures are true, then OVH as well as the >> remote servers may have a valid reason to consider you either as the >> attacker or as an (unknowning, perhaps) accomplice. >> >> I may be wrong - sorry if so - and would appreciate, in any case, if you >> can confirm or clarify, thanks. >> >> -- >> Amir Herzberg >> >> Comcast professor of Security Innovations, University of Connecticut >> >> Homepage: https://sites.google.com/site/amirherzberg/home >> >> Foundations of Cyber-Security (part I: applied crypto, part II: >> network-security): >> https://www.researchgate.net/project/Foundations-of-Cyber-Security >> >> >> >> On Thu, Feb 20, 2020 at 5:23 PM Octolus Development >> wrote: >> >>> A very old attack method called TCP-AMP ( https://pastebin.com/jYhWdgHn ) >>> has been getting really popular recently. >>> >>> I've been a victim of it multiple times on many of my IP's and every >>> time it happens - My IP's end up getting blacklisted in major big >>> databases. We also receive tons of abuse reports for "Port Scanning". >>> >>> Example of the reports we're getting: >>> tcp: 51.81.XX.XX:19342 -> 209.208.XX.XX:80 (SYN_RECV) >>> tcp: 51.81.XX.XX:14066 -> 209.208.XX.XX:80 (SYN_RECV) >>> >>> OVH are threatening to kick us off their network, because we are victims >>> of this attack. And requesting us to do something about it, despite the >>> fact that there is nothing you can do when you are being victim of an DDoS >>> Attack. >>> >>> Anyone else had any problems with these kind of attacks? >>> >>> The attack basically works like this; >>> - The attacker scans the internet for TCP Services, i.e port 80. >>> - The attacker then sends spoofed requests from our IP to these TCP >>> Services, which makes the remote service attempt to connect to us to >>> initiate the handshake.. This clearly fails. >>> ... Which ends up with hundreds of request to these services, reporting >>> us for "port flood". >>> >>> >>>
Re: TCP-AMP DDoS Attack - Fake abuse reports problem
If I read your description correctly: - Attacker sends spoofed TCP SYN from your IP address(es) and different src ports, to some TCP servers (e.g. port 80) - TCP servers respond with SYN/ACK ; many servers resend the SYN/ACK hence amplification . - *** your system does not respond *** - Servers may think you're doing SYN-Flood against them, since connection remains in SYN_RCVD, and hence complain. In fact, we don't really know what is the goal of the attackers; they may in fact be trying to do SYN-Flood against these servers, and you're just a secondary victim and not the even the target, that's also possible. Anyway, is this the case? If it is... may I ask, do you (or why don't you) respond to the unsolicited SYN/ACK with RST as per the RFC? I suspect you don't, maybe due to these packets being dropped by FW/NAT, that's quite common. But as you should understand by now from my text, this (non-standard) behavior is NOT recommended. The problem may disappear if you reconfigure your FW/NAT (or host) to respond with RST to unsolicited SYN/ACK. As I explained above, if my conjectures are true, then OVH as well as the remote servers may have a valid reason to consider you either as the attacker or as an (unknowning, perhaps) accomplice. I may be wrong - sorry if so - and would appreciate, in any case, if you can confirm or clarify, thanks. -- Amir Herzberg Comcast professor of Security Innovations, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home Foundations of Cyber-Security (part I: applied crypto, part II: network-security): https://www.researchgate.net/project/Foundations-of-Cyber-Security On Thu, Feb 20, 2020 at 5:23 PM Octolus Development wrote: > A very old attack method called TCP-AMP ( https://pastebin.com/jYhWdgHn ) > has been getting really popular recently. > > I've been a victim of it multiple times on many of my IP's and every time > it happens - My IP's end up getting blacklisted in major big databases. We > also receive tons of abuse reports for "Port Scanning". > > Example of the reports we're getting: > tcp: 51.81.XX.XX:19342 -> 209.208.XX.XX:80 (SYN_RECV) > tcp: 51.81.XX.XX:14066 -> 209.208.XX.XX:80 (SYN_RECV) > > OVH are threatening to kick us off their network, because we are victims > of this attack. And requesting us to do something about it, despite the > fact that there is nothing you can do when you are being victim of an DDoS > Attack. > > Anyone else had any problems with these kind of attacks? > > The attack basically works like this; > - The attacker scans the internet for TCP Services, i.e port 80. > - The attacker then sends spoofed requests from our IP to these TCP > Services, which makes the remote service attempt to connect to us to > initiate the handshake.. This clearly fails. > ... Which ends up with hundreds of request to these services, reporting us > for "port flood". > > >
Re: Why are IPsec SAs unidirectional
Bart asked, > Does someone know why these IPsec SAs are unidirectional? Usually the > RFC describes some reasoning behind certain design decisions. However, I > can't seem to find a justification other than "It's by design". On the > Internet however, I read that the two SA requirement is chosen from a > security perspective; If the key material of one of the SAs leaks, only > one way of the traffic can be inspected by a third party. The problem > with this reasoning is that I can't seem to find an additional source > claiming the same thing. Therefore, I'm not sure whether it's true. > I like this question :) so I apologize for a lengthy response. Or, let's give you a tl;dr version: for key separation and refresh, mainly for security considerations. So: - The _keys_ used in both directions should (preferably) be different, for security. You mentioned one reason, i.e., that the if one of them leaks, the other one will remain secure; I guess that's true, although one may wonder about the scenarios in which only one of the two leaks, as they are used in same devices. A more relevant reason imho is that it may be easier to expose one of the two keys using cryptanalysis, e..g, since attacker can control the plaintext (chosen-plaintext) or can know the plaintext (known-plaintext). Yes, we all know that these are not the common attacks, still, IPsec is designed to defeat these too... - As Brandon mentioned, the SPIs in the two directions differ. No, that's _not_ a mistake. By keeping these different, we allow each party to choose the SPI of traffic sent to it (that's how it works). This can be used for (1) efficiency - use predefined array of SPIs (think HW), (2) security - choose SPI randomly, defeating spoofed packets sent as part of DoS attack against IPsec tunnel (by off-path attacker). - And then there's key management. When refreshing a key, or more precisely, changing a key due to exceeding max usage amount/period, we typically negotiate a new key and SPI. Once we got the `ack' from the remote peer (with the new SPI), we can start using the new key, while our peer may still be using an old key to send traffic to us (in fact we have the flexibility of not changing both keys together, e.g., if changing based on amount of traffic). BTW, I was actually around in the initial design, but I can't claim to remember the process well enough to say these were exactly the reasons for this at the time; but these are the reasons I'm aware of (and I'll love to learn if there are more or if any of these are incorrect). -- Amir On Sun, Feb 16, 2020 at 5:30 PM Brandon Martin wrote: > On 2/15/20 1:17 PM, Bart Hermans wrote: > > Does someone know why these IPsec SAs are unidirectional? > > My take on it: > > * IP, on which IPSec is directly built, is not a bidirectional protocol. > It is unidirection and fire-and-forget. There's no assumption made > that the source address specified in a given packet is even reachable > from the destination address (much to the chagrin of many network > operators), though it's supposed to be the case that it is. Making SAs > bidirectional would therefore represent something of a layering > inversion which the IP suite has been surprisingly careful to avoid. > > * While many protocols built on top of IP, including ISAKMP are > bidirectional, not all are, so having unidirectional SAs is potentially > useful especially in the case of e.g. multicast as another poster > pointed out. > > * ISAKMP is not the only way to key IPSec SAs. It's a fairly complex > protocol and is separate from the base IPSec specifications. Someone > could come up with another, possibly better way to do it. You can also > key them manually. Again, projecting the nature of ISAKMP onto IPSec > would be a layering violation and might inhibit future use cases of the > latter. > > * An IPSec SA itself is quite simple. Making it unidirectional is > in-line with that notion and appears to have few consequences. > > * An IPSec SPD is also unidirectional (one could argue that this is a > mistake, but see all the above), and an SA follows directly from an SPD. > -- > Brandon Martin >
Re: Dual Homed BGP
Dear Job and NANOG, Just wondering, wouldn't any of you guys consider using full tables in this case, for the ability to detect and avoid prefix hijacks (using RPKI/ROV or other means)? Of course, I'm focused on security, and I know this is often not a high priority for a real network manager who has many other considerations; just want to know. Thanks. -- Amir On Fri, Jan 24, 2020 at 12:27 PM Job Snijders wrote: > Dear Brian, > > On Fri, 24 Jan 2020 at 17:40, Brian wrote: > >> Hello all. I am having a hard time trying to articulate why a Dual Home >> ISP should have full tables. My understanding has always been that full >> tables when dual homed allow much more control. Especially in helping to >> prevent Async routes. >> > > The advantage of receiving full routing tables from both providers is that > in cases where one of the two providers is not yet fully converged, your > routers will use the other provider for those missing destinations. This > may happen during maintenance or router boot-up in your upstream’s network. > > Another advantage of receiving full routes is that you can manipulate > LOCAL_PREF per destination, or compose routing policy based on per-route > attributes such as BGP communities your upstreams set. It can happen that a > provider is great for 99% of destinations, except a few - without full > tables such granular traffic-engineering can be cumbersome. > > Virtually all internet routing is asymmetric, I wouldn’t consider that an > issue. > > Am I crazy? >> > > I dropped out of university, never completed my psychology studies, I fear > I am unqualified to answer this question. ;-) > > Kind regards, > > Job >
Re: Data on latency and loss-rates during congestion DDoS attacks
I have no idea who was the reviewer (academic or industry or whatever). However, he didn't actually object to the assertion that latency increases with congestion; he only raised the question of the which latency values would be typical/reasonable for a congestion DoS attack. Notice also that the relevant parameter is end-to-end latency (or RTT), not the per-device latency. And surely, there can be wide variety here (that's why we do experiments under different values and plot graphs). The question is, what is the most important range to focus on (when measuring and comparing different protocols). Anyway, thanks for the comments; if anyone has such data they can share, that'll be great and appreciated. -- Amir On Sun, Jan 26, 2020 at 7:17 AM Saku Ytti wrote: > On Sun, 26 Jan 2020 at 13:11, Etienne-Victor Depasquale > wrote: > > > " he/she doubts that delays increase significantly under network > congestion since he/she thinks that the additional queuing is something > mostly in small routers such as home routers (and maybe like the routers > used in our emulation testbed) " > > > > Wow, this is the first time I've found an academic challenging the > increase of delay in routers under network congestion. > > I don't know if context implies reviewer was academic. Whilethe common > case remains that latencies per link jump from low microseconds to > tens of milliseconds during congestion of BB interface, there are also > a lot of deployments using devices (trident, tomahawk) with minimal > buffering not allowing even millisecond of buffering during > congestion. Reviewer may have thought of those devices when they > answered, but I agree that answer would be generally wrong. > > > -- > ++ytti >
Re: Data on latency and loss-rates during congestion DDoS attacks
Hi Damian, thanks, that's right; actually in high-latency and 10% loss, you get _much_ better performance than either TCP or Quic. However, these are not as common scenarios as clogging due to DDoS... So we still want to find relevant data, to know which ranges of latency and loss make sense. Guys: if you can share data but only privately, please do :) thanks! Amir -- Amir On Sat, Jan 25, 2020 at 12:38 PM Damian Menscher wrote: > Getting (and releasing) numbers from DDoS attacks will be challenging for > most, but I think your research could apply to more than just DDoS. There > are often cases where one might want to work from an environment which has > very poor networking. As an extreme example, in 2007 I got online from an > internet cafe in Paramaribo. But, as I told a friend at the time, "latency > is about 1s and packet loss around 10%". It would be great if forward > error correction could have improved that experience. > > Damian > > On Fri, Jan 24, 2020 at 7:27 PM Amir Herzberg > wrote: > >> Damian, thanks! >> >> That's actually roughly the range of losses we focused on; but it was >> based on my rough feeling for reasonable loss rates (as well as on >> experiments where we caused losses in emulated environments), and a >> reviewer - justifiably - asked if we can base our values on realistic >> values. So I would love to have real value, I'm sure some people have these >> measured (I'm actually quite sure I've seed such values, but the challenge >> is recalling where and finding it...). >> >> Also, latency values (under congestion) would be appreciated. Also here, >> we used a range of values, I think the highest was 1sec, since we believe >> that under congestion delays goes up considerably since many queues fill up >> [and again I seem to recall values around this range]. But here the >> reviewer even challenged us and said he/she doubts that delays increase >> significantly under network congestion since he/she thinks that the >> additional queuing is something mostly in small routers such as home >> routers (and maybe like the routers used in our emulation testbed). So I'll >> love to have some real data to know for sure. >> >> Apart from knowing these things for this specific paper, I should know >> them in a well-founded way anyway, as I'm doing rearch on and teaching >> net-sec (incl. quite a lot on DoS) :) >> >> -- >> Amir >> >> >> >> On Fri, Jan 24, 2020 at 5:31 PM Damian Menscher >> wrote: >> >>> I suggest testing with a broad variety of values, as losses as low as 5% >>> can be annoying, but losses at 50% or more are not uncommon. >>> >>> Damian >>> >>> On Fri, Jan 24, 2020 at 4:41 AM Amir Herzberg >>> wrote: >>> >>>> Dear NANOG, >>>> >>>> One of my ongoing research works is about a transport protocol that >>>> ensures (critical) communication in spite of DDoS congestion attack (which >>>> cannot be circumvented), by (careful) use of Forward Error Correction. Yes, >>>> obviously, this has to be done and used carefully since the FEC clearly >>>> increases traffic rather than the typical congestion-control approach of >>>> reducing it, I'm well aware of it; but some applications are critical (and >>>> often low-bandwidth) so such tool is important. >>>> >>>> I am looking for data on loss rate and congestion of DDoS attacks to >>>> make sure we use right parameters. Any chance you have such data and can >>>> share? >>>> >>>> Many thanks! >>>> -- >>>> Amir Herzberg >>>> Comcast chair of security innovation, University of Connecticut >>>> Foundations of cybersecurity >>>> <https://www.researchgate.net/publication/323243320_Introduction_to_Cyber-Security_Part_I_Applied_Cryptography_Lecture_notes_and_exercises>, >>>> part >>>> I (see also part II and presentations): >>>> https://www.researchgate.net/publication/323243320_Introduction_to_Cyber-Security_Part_I_Applied_Cryptography_Lecture_notes_and_exercises >>>> <https://www.researchgate.net/project/Lecture-notes-on-Introduction-to-Cyber-Security> >>>> >>>> >>>>
Re: Data on latency and loss-rates during congestion DDoS attacks
On Sat, Jan 25, 2020 at 2:12 AM Saku Ytti wrote: > On Sat, 25 Jan 2020 at 05:30, Amir Herzberg wrote: > > DDoS is very very cheap, if there is a single global egress for given > interface then the DDoS traffic can easily be 100 times the egress > capacity (1GE egress, 100GE DDoS). Thanks. However, my question is about statistics of attacks actually seen `in the wild' - and not just the `worst' but also more common attacks. Furthermore, I'm asking about the _outcome_ of the congestion - mainly, loss-rates and latency - and not about the _amount_ of DDoS traffic. DDoS traffic often gets lost itself in different intermediate routers, so its ultimate impact is not trivial to estimate. > I'm very skeptical if FEC will > help, I think this is case of cat and mouse hmm, I don't think so; it is more a matter of justification, and also, obviously, amount of over-capacity - which is still, obviously, a basic thing anybody concerned about congestion would worry about. Let me be extreme and simplify... Suppose idd attacker can send 100 times the capacity of a (say, single) router, resulting in 99% loss rate. Then FEC should work - but, of course, with high overhead, let's even simplify and say it requires 100 times redundancy (although it's actually not as bad as that). Still, this can be Ok if I have 100 times overcapacity - which for many critical applications, is not even a big deal, as crazy as it sounds (and is) for general applications. > , based on data you see now > it may seem reasonable, but now is only result of minimum viable ddos, > which is trivial to increase should need occur. I still think evaluation should preferably compare to attacks reported in reality, with potential additional analysis of projections of potential attacks. > Similarly DDoS attacks > are excessive dumb often, like dumb UDP ports which are easy drop, but > should we solve protection well for these, it's trivial to make it > proper HTTPS TCP SYN. > hmm, tcp-syn is already a different story (and we have pretty good defenses against it and many other attacks on the end host). I do work on some of these attacks (and defenses) too but in this specific case I'm focusing on bandwidth-DoS attacks (network congestion). I'm further focusing in this work on a defense which may involves a transport (end to end) protocol, of course I'm aware of network-based defenses, it's just not focus of this work (think of customer with no ability to `fix' the network service). > > Backbone device interface can add hundreds of milliseconds during > congestion, but more commonly we're talking about tens of milliseconds > during congestion and low microseconds to high nanoseconds outside > congestion. > Backbone device buffer space is highly googlable, BRCM > trident/tomahawk styte boxes have very little, but they are more > intended for DC/LAN scenarios, than WAN. Nokia FP, Huawei Solar, > EZchip, Cisco nPower, Cisco Silicon One, Juniper Trio, Juniper > Paradise, Broadcom Jericho all will buffer high tens of milliseconds > to low hundreds. > Thanks again, but I'm not looking for data on particular devices; the latency during congestion attacks may be impacted by multiple devices along the path. So again my interest is mainly in measured values under real attacks. tks! Amir > > -- > ++ytti >
Re: Data on latency and loss-rates during congestion DDoS attacks
Damian, thanks! That's actually roughly the range of losses we focused on; but it was based on my rough feeling for reasonable loss rates (as well as on experiments where we caused losses in emulated environments), and a reviewer - justifiably - asked if we can base our values on realistic values. So I would love to have real value, I'm sure some people have these measured (I'm actually quite sure I've seed such values, but the challenge is recalling where and finding it...). Also, latency values (under congestion) would be appreciated. Also here, we used a range of values, I think the highest was 1sec, since we believe that under congestion delays goes up considerably since many queues fill up [and again I seem to recall values around this range]. But here the reviewer even challenged us and said he/she doubts that delays increase significantly under network congestion since he/she thinks that the additional queuing is something mostly in small routers such as home routers (and maybe like the routers used in our emulation testbed). So I'll love to have some real data to know for sure. Apart from knowing these things for this specific paper, I should know them in a well-founded way anyway, as I'm doing rearch on and teaching net-sec (incl. quite a lot on DoS) :) -- Amir On Fri, Jan 24, 2020 at 5:31 PM Damian Menscher wrote: > I suggest testing with a broad variety of values, as losses as low as 5% > can be annoying, but losses at 50% or more are not uncommon. > > Damian > > On Fri, Jan 24, 2020 at 4:41 AM Amir Herzberg > wrote: > >> Dear NANOG, >> >> One of my ongoing research works is about a transport protocol that >> ensures (critical) communication in spite of DDoS congestion attack (which >> cannot be circumvented), by (careful) use of Forward Error Correction. Yes, >> obviously, this has to be done and used carefully since the FEC clearly >> increases traffic rather than the typical congestion-control approach of >> reducing it, I'm well aware of it; but some applications are critical (and >> often low-bandwidth) so such tool is important. >> >> I am looking for data on loss rate and congestion of DDoS attacks to make >> sure we use right parameters. Any chance you have such data and can share? >> >> Many thanks! >> -- >> Amir Herzberg >> Comcast chair of security innovation, University of Connecticut >> Foundations of cybersecurity >> <https://www.researchgate.net/publication/323243320_Introduction_to_Cyber-Security_Part_I_Applied_Cryptography_Lecture_notes_and_exercises>, >> part >> I (see also part II and presentations): >> https://www.researchgate.net/publication/323243320_Introduction_to_Cyber-Security_Part_I_Applied_Cryptography_Lecture_notes_and_exercises >> <https://www.researchgate.net/project/Lecture-notes-on-Introduction-to-Cyber-Security> >> >> >>
Data on latency and loss-rates during congestion DDoS attacks
Dear NANOG, One of my ongoing research works is about a transport protocol that ensures (critical) communication in spite of DDoS congestion attack (which cannot be circumvented), by (careful) use of Forward Error Correction. Yes, obviously, this has to be done and used carefully since the FEC clearly increases traffic rather than the typical congestion-control approach of reducing it, I'm well aware of it; but some applications are critical (and often low-bandwidth) so such tool is important. I am looking for data on loss rate and congestion of DDoS attacks to make sure we use right parameters. Any chance you have such data and can share? Many thanks! -- Amir Herzberg Comcast chair of security innovation, University of Connecticut Foundations of cybersecurity <https://www.researchgate.net/publication/323243320_Introduction_to_Cyber-Security_Part_I_Applied_Cryptography_Lecture_notes_and_exercises>, part I (see also part II and presentations): https://www.researchgate.net/publication/323243320_Introduction_to_Cyber-Security_Part_I_Applied_Cryptography_Lecture_notes_and_exercises <https://www.researchgate.net/project/Lecture-notes-on-Introduction-to-Cyber-Security>
Re: Reflection DDoS last week (was: syn flood attacks from NL-based netblocks)
Töma, thanks for this interesting update. The best defense against this
type of DDoS attacks seems idd to be relaying to
sufficiently-large-bandwidth cloud/CDN, and filtering TCP traffic (received
not from the relay). Such relaying should be done well - smart attacks may
still be possible for `naive' relaying.
--
Amir
On Wed, Aug 21, 2019 at 3:46 PM Töma Gavrichenkov wrote:
> Peace,
>
> Here's to confirm that the pattern reported before in NANOG was indeed a
> reflection DDoS attack. On Sunday, it also hit our customer, here's the
> report:
>
>
> https://www.prnewswire.com/news-releases/root-cause-analysis-and-incident-report-on-the-august-ddos-attack-300905405.html
>
> tl;dr: basically that was a rather massive reflected SYN/ACK carpet
> bombing against several datacenter prefixes (no particular target was
> identified).
>
> --
> Töma
>
> On Sat, Aug 17, 2019, 1:06 AM Jim Shankland wrote:
>
>> Greetings,
>>
>> I'm seeing slow-motion (a few per second, per IP/port pair) syn flood
>> attacks ostensibly originating from 3 NL-based IP blocks: 88.208.0.0/18
>> , 5.11.80.0/21, and 78.140.128.0/18 ("ostensibly" because ... syn flood,
>> and BCP 38 not yet fully adopted).
>>
>> Why is this syn flood different from all other syn floods? Well ...
>>
>> 1. Rate seems too slow to do any actual damage (is anybody really
>> bothered by a few bad SYN packets per second per service, at this
>> point?); but
>>
>> 2. IPs/port combinations with actual open services are being targeted
>> (I'm seeing ports 22, 443, and 53, just at a glance, to specific IPs
>> with those services running), implying somebody checked for open
>> services first;
>>
>> 3. I'm seeing this in at least 2 locations, to addresses in different,
>> completely unrelated ASes, implying it may be pretty widespread.
>>
>> Is anybody else seeing the same thing? Any thoughts on what's going on?
>> Or should I just be ignoring this and getting on with the weekend?
>>
>> Jim
>>
>
Re: syn flood attacks from NL-based netblocks
The number of TCP syn-ack amplifiers is large. It may suffice to allow
clogging a provider or IX, using low load per amplifier, as described. Such
low load is likely to be undetected by most operators, and even when
detected (e.g. by Jim), only few (e.g. Mike) will have sufficient
motivation to block it - esp. considering that there blocking it would
often be non-trivial, in Mike's case, the amplifiers were DNS servers and
sounds like he simply blocked packets to unallowed networks (good practice
for DNS anyway - although I wonder why not block the incoming requests
instead). Notice that one annoying aspect of these attacks is that tcp
congestion control isn't relevant.
The current packets could be part of a research experiment about this
threat, or the instrumentation part of preparing such attack. I would not
rule out research, since it isn't trivial to know if the attack can be
really viable to clog a provider or IX; in fact finding this out in an
ethical way appears a non-trivial challenge, I'll give it some thought
(ideas welcome). Also I wonder what would be good _defenses_ against such
attack. Of course one way would be to prevent spoofed-IP packets, but that
goal has proved quite difficult...
--
Amir Herzberg
Comcast professor for security innovation
Dept. of Computer Science and Engineering, University of Connecticut
On Sat, Aug 17, 2019 at 11:03 PM Mike wrote:
> On 8/16/19 3:04 PM, Jim Shankland wrote:
> > Greetings,
> >
> > I'm seeing slow-motion (a few per second, per IP/port pair) syn flood
> > attacks ostensibly originating from 3 NL-based IP blocks:
> > 88.208.0.0/18 , 5.11.80.0/21, and 78.140.128.0/18 ("ostensibly"
> > because ... syn flood, and BCP 38 not yet fully adopted).
> >
> > Why is this syn flood different from all other syn floods? Well ...
> >
> > 1. Rate seems too slow to do any actual damage (is anybody really
> > bothered by a few bad SYN packets per second per service, at this
> > point?); but
> >
> > 2. IPs/port combinations with actual open services are being targeted
> > (I'm seeing ports 22, 443, and 53, just at a glance, to specific IPs
> > with those services running), implying somebody checked for open
> > services first;
> >
> > 3. I'm seeing this in at least 2 locations, to addresses in different,
> > completely unrelated ASes, implying it may be pretty widespread.
> >
> > Is anybody else seeing the same thing? Any thoughts on what's going
> > on? Or should I just be ignoring this and getting on with the weekend?
> >
> > Jim
> >
> >
> >
> >
>
> I am seeing this against my recursive revolvers - one syn in, and many
> syn-ack's back with no connection obviously. Low rate to be sure, but
> what was surprising to me was that my revolvers (PowerDNS) definitely
> have an allowed-networks ACL which specifies my permitted client
> addresses, and I thought this would effectively filter any inbound
> queries. But it looks like this ACL is applied only AFTER connection
> setup. Maybe I have been blind this entire time thinking I wouldn't
> respond to any packets sent to my resolver from non-allowed-networks
> addresses. But anyways just a good data-point for anyone else to check
> your revolvers too and consider the TCP case may behave as mine do. I
> fixed it by implementing a revised iptables firewall which definitely
> corrects the issue and drops outright all packets to
> non-allowed-networks addresses, thank you ipset...
>
> Mike-
>
>
Re: syn flood attacks from NL-based netblocks
Damian, sure, that's what I meant - it's possible, but only _if_ Jim's
machines actually respond with multiple SYN-ACK packets. Which I _think_
Jim probably would have noticed. Or maybe not ?
btw, some TCP amplifications can be quite severe, if anyone wants I can
send the citation to a nice paper exploring this issue.
BR...
--
Amir Herzberg
Comcast professor for security innovation
Dept. of Computer Science and Engineering, University of Connecticut
On Sat, Aug 17, 2019 at 6:56 PM Damian Menscher wrote:
> On Sat, Aug 17, 2019 at 3:36 PM Amir Herzberg
> wrote:
>
>> Hmm, I doubt this is the output of TCP amplification since Jim reported
>> it as SYN spoofing, i.e., SYN packets, not SYN-ACK packets (as for typical
>> TCP amplification). Unless the given _hosts_ respond with multiple SYN-ACKs
>> in which case these may be experiments by an attacker to measure if these
>> IP:ports could be abused as TCP amplifiers.
>>
>
> Clarifying for those unfamiliar with this attack:
> - Attacker is sending SYN packets spoofed "from" NL to Jim (and others)
> - Jim (and others) have applications listening on those ports and
> respond with SYN-ACK packets to the victim in NL
> - When the victim (NL) fails to complete the handshake (which they
> didn't initiate!) Jim (and others) sends another SYN-ACK
>
> So they're not probing to see if Jim (and others) are abusable as TCP
> amplifiers... they've already determined they can be abused and are using
> those machines to conduct an actual attack against victims in NL.
>
> Damian
>
> On Sat, Aug 17, 2019 at 6:18 PM Damian Menscher via NANOG
>> wrote:
>>
>>> On Fri, Aug 16, 2019 at 3:05 PM Jim Shankland
>>> wrote:
>>>
>>>> I'm seeing slow-motion (a few per second, per IP/port pair) syn flood
>>>> attacks ostensibly originating from 3 NL-based IP blocks: 88.208.0.0/18
>>>> , 5.11.80.0/21, and 78.140.128.0/18 ("ostensibly" because ... syn
>>>> flood,
>>>> and BCP 38 not yet fully adopted).
>>>>
>>>> Is anybody else seeing the same thing? Any thoughts on what's going on?
>>>> Or should I just be ignoring this and getting on with the weekend?
>>>>
>>>
>>> This appears to be a TCP amplification attack. Similar to UDP
>>> amplification (DNS, NTP, etc) you can get some amplification by sending a
>>> SYN packet with a spoofed source, and watching your victims receive
>>> multiple SYN-ACK retries. It's a fairly weak form of attack (as the
>>> amplification factor is small), but if the victim's gear is vulnerable to
>>> high packet rates it may be effective.
>>>
>>> The victim (or law enforcement) could identify the true source of the
>>> attack by asking transit providers to check their netflow to see where it
>>> enters their networks.
>>>
>>> Damian
>>>
>>
Re: syn flood attacks from NL-based netblocks
Hmm, I doubt this is the output of TCP amplification since Jim reported it
as SYN spoofing, i.e., SYN packets, not SYN-ACK packets (as for typical TCP
amplification). Unless the given _hosts_ respond with multiple SYN-ACKs in
which case these may be experiments by an attacker to measure if these
IP:ports could be abused as TCP amplifiers.
But, at least if these IP:ports do not amplify, I suspect it's more likely
that, as Töma wrote, this is simply result of some learning-experiment by
students (or by wanna-be hackers).
Yes, such (unethical, unprofessional) experimentation happens, and can be
easily confused with some clever new attack... which is a pity since we
always like to learn of new attacks!
Of course one (i.e., Jim) could try to trace back and find the source
(likely spoofer) but it seems quite likely to be some students or script
kiddies, which may be underwhelming...
--
Amir
On Sat, Aug 17, 2019 at 6:18 PM Damian Menscher via NANOG
wrote:
> On Fri, Aug 16, 2019 at 3:05 PM Jim Shankland wrote:
>
>> I'm seeing slow-motion (a few per second, per IP/port pair) syn flood
>> attacks ostensibly originating from 3 NL-based IP blocks: 88.208.0.0/18
>> , 5.11.80.0/21, and 78.140.128.0/18 ("ostensibly" because ... syn flood,
>> and BCP 38 not yet fully adopted).
>>
>> Is anybody else seeing the same thing? Any thoughts on what's going on?
>> Or should I just be ignoring this and getting on with the weekend?
>>
>
> This appears to be a TCP amplification attack. Similar to UDP
> amplification (DNS, NTP, etc) you can get some amplification by sending a
> SYN packet with a spoofed source, and watching your victims receive
> multiple SYN-ACK retries. It's a fairly weak form of attack (as the
> amplification factor is small), but if the victim's gear is vulnerable to
> high packet rates it may be effective.
>
> The victim (or law enforcement) could identify the true source of the
> attack by asking transit providers to check their netflow to see where it
> enters their networks.
>
> Damian
>
Re: BGP prefix filter list
This discussion is very interesting, I didn't know about this problem, it has implications to our work on routing security, thanks! On Sat, May 18, 2019 at 11:37 AM Alejandro Acosta < alejandroacostaal...@gmail.com> wrote: > >If you learn, let's say, up to /22 (v4), and someone hijacks one /21 > you will learn the legitimate prefix and the hijacked prefix. Now, the > owner of the legitimate prefix wants to defends their routes announcing > /23 or /24, of course those prefixes won't be learnt if they are filtered. > I wonder if this really is a consideration to avoid filtering small prefixes (e.g. /24): - attackers are quite likely to do sub-prefix hijacks (or say a specific /24), so I'm not sure this `hits' defenders more than it `hits' attackers - I think we're talking only/mostly about small providers here, right? as larger providers probably will not have such problems of tables exceeding router resources.I expect such small providers normally connect thru several tier-2 or so providers... if these upper-tier providers get hijacked, the fact you've prevented this at the stub/multihome ISP may not help much - we showed how this happens with ROV in our NDSS paper on it: https://www.ndss-symposium.org/ndss2017/ndss-2017-programme/are-we-there-yet-rpkis-deployment-and-security/ Amir Herzberg Comcast professor for security innovation Dept. of Computer Science and Engineering, University of Connecticut Foundations of Cybersecurity: https://www.researchgate.net/project/Lecture-notes-on-Introduction-to-Cyber-Security Homepage: https://sites.google.com/site/amirherzberg/home
IEEE CNS (co-located w/ NANOG) and lectures/notes on cyber-sec, routing
Hi NANOG, two activities I'm involved in which may be of some interest/use to some of you: 1. IEEE CNS - Wash. DC, June 10-12 (yes, co-located with NANOG'76 - unfortunately, completely uncoordinated, and being TPC co-chair for CNS, this lack of coordination is frustrating and hard to justify). But maybe some of us will find ways to benefit from the co-location anyway (e.g., drop by to some CNS session, e.g., the session on Internet Infrastructure security - June 10 afternoon). Or organize joint dinner of interested people... or something. 2. While already announcing stuff let me mention that I'm working on pretty extensive text and set of lectures on `foundations of cyber-security' with emphasis on the network-security and crypto aspects. Part I is crypto and much of it is already usable, part II is on network security and currently mainly contains questions/exercises (a fair number and quite challenging). But lectures (pptx) are already available on most topics, incl. routing security. Hope some of you may find these of some use; feedback welcome (probably by private mail would be better). Best, Amir -- Amir Herzberg Comcast professor for security innovation Dept. of Computer Science and Engineering, University of Connecticut Foundations of Cybersecurity: https://www.researchgate.net/project/Lecture-notes-on-Introduction-to-Cyber-Security Homepage: https://sites.google.com/site/amirherzberg/home
Process for deploying new BGP attributes (experimentally or otherwise)
Following our recent attempts to experiment with potential use of BGP attributes, I would like to understand better the desired process for using new BGP attributes. As mentioned earlier, we investigate currently one usage of BGP attributes for improving BGP security - specifically, adoption of RPKI. I also have some future ideas on other ways BGP attributes may be useful to improve BGP security; and surely other applications, security or otherwise, may exist. So I think we need an acceptable process to do it. Indeed, while we aborted that experiment, I doubt that the right conclusion is that one should simply never use a new BGP attribute... And I even hope that the community would want us to complete our research, to see if the particular approach we evaluate may indeed be beneficial. I think that these sentiments were also expressed by many members of this community. So: - Is there some document discussing the desired (best practice) process? [if not, maybe such document should be written?] - We used unassigned attribute. Should one always assign an attribute before using it? That's a possibility, but has some `costs' - and may yet fail to prevent problems to some non-conforming networks. - Is there an agreed-upon list of the forums and mailing lists on which one should warn in advance about such planned announcements, and the details that should be included? Thanks, Amir -- Amir Herzberg Comcast professor for security innovation Dept. of Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home Publications and projects: https://www.researchgate.net/profile/Amir_Herzberg/contributions <https://www.researchgate.net/profile/Amir_Herzberg/publications> Lecture notes in intro to cyber: https://www.researchgate.net/project/Lecture-notes-on-Introduction-to-Cyber-Security
