Job, many thanks for this detailed feedback! I copy Nanog on my response below, since you sent there, but maybe we could move future emails off list to avoid spamming people not into this subject. * 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).

Thanks for this important comment; indeed, if something like BGP-iSec would be adopted as a standard, then such `flad day' requirement should indeed be avoided. One simple option would be to allow an adopting AS X to include in its relevant RPKI entry, a specific `enforcement time' T_E. Only after this time would another adopting AS, say AS Y, drop announcements with origin AS X but without a valid signature. AS X will select the enforcement time T_E to be sufficient in the future (upon deploying) to ensure that all of its routers will already be deployed at that time. But we don't view BGP-iSec as a proposal for adoption; we expect few improvements in future work, in particular, improvements to its efficiency (which is currently comparable to, and even somewhat higher than, that of BGPsec, i.e., quite high). And additional evaluation is also very important (esp. from experts like you, Job - thanks!) and may lead to changes. For example, we may do an fix to the design soon to address an important comment from Joel Halpern (thanks Joel!).

* 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.

That's correct. But, again, BGP-iSec is an academic paper, not a proposed standard. In practically all papers on BGP security, we adopt the valley-free routing model which basically forbids leaks. If this is modified to a standard, I'm sure this issue can be addressed, similarly to how it is dealt with in the OTC RFC.

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.

Good point, we should clarify this indeed, thanks!

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.

I admit that sometimes it appears to me that full adoption of IPv6 will indeed occur only after we solve world hunger.

* 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.

Actually, I think we became aware of ASPA only after that part of the design :)

Again, this suggests that BGP-iSec requires a flag day for all EBGP routers in a given Autonomous System;

Here you're wrong. There is no problem if different EBGP routers adopt the UP mechanism at different times; the mechanism will be implemented only for announcements which passed via an adopting router, that's all, no harm.

* The bold assertion made by the BGP-iSec authors that BGPSec offers "meagre benefits in partial adoption" to me seems a subjective one.

You're right, we should clarify that we merely referred to the reductions in hijack rates in simulations of the defense (under different adoption percentages). Our expression was too extreme and may give wrong impression; thanks for pointing this out.

Consider when two BGPSec-capable networks interconnect, both parties immediately benefit from having secured that interconnection point. For example, if this happens to be the interconnection between two major cloud providers, the advantages are massive and can positively benefit billions of indirect constituents.

Let's say that these large cloud ASes, say AS A an AS Z have a direct connection (BGP peering) and both adopt BGPsec. What benefit do you see (to billions of entities)? In particular, do you think this prevents a attacker from hijacking traffic sent from A to Z? I'm not sure. Consider AS 666 who is a customer of AS A, and let 1.2.3/24 be a prefix of cloud/AS Z. Now, AS 666 may send an announcement with origin Z and path 666-Z to AS A; this may be unsigned (without even receiving announcement of 1.2.3/24 from Z) or even signed (if Z received the announcement from Z - e.g., when 666 is a customer of Z). I think that in both cases, A ends up sending the traffic via 666. So, can you clarify the benefits? I may miss something.

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 <job@fastly.com> 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_Securit...

Thanks for freely sharing a copy! This allowed me to jot down some initial thoughts.

* It appears that BGP-iSec requires a deployment flag day per Autonomous System, rather than doing security upgrades "one EBGP session at a time" (a deployment model both RPKI-ROV and BGPsec support). This lack of "per EBGP session"-granularity doesn't make for a feasible or viable deployment story in the global Internet routing system - as quite some Autonomous Systems are composed of thousands of routers which cannot be made to do the same thing at the same moment for logistical and various other reasons. What BGP-iSec promotes as a 'feature' ("Mandatory Signatures for Announcement Integrity") - may turn out to be its biggest impediment towards deployment in the real world.

* As noted in RFC 7132 [0], Google's [1], Fastly's [2] response to the FCC "inquiry into internet routing vulnerabilities" which your paper cites; BGPsec was consciously not designed to address route leaks, as leaks are not precluded by the specification for BGP and might be the result of a local policy that is not publicly disclosed. To me the sentence "Even under full adoption, BGPsec does not prevent route leaks" reads contentious, because of an implicit assertion that BGPsec was intended to address route leaks. To me the above reads as "Even under full adoption of IPv6, world hunger will not be achieved". E.g. seems a false equivalence is drawn.

* It appears BGP-iSec took some inspiration from ASPA, but instead of signalling the list of providers out-of-band (which ASPA does via the RPKI publication system); BGP-iSec proposed an in-band signal in the form of 'UP' messages encapsulated inside BGP Path Attributes. Again, this suggests that BGP-iSec requires a flag day for all EBGP routers in a given Autonomous System; whereas deployment of the ASPA signal happens via a singular place (the RIR RPKI web portal), and in order to publish an ASPA object, no changes have to be executed on the Autonomous System's EBGP routers.

* The bold assertion made by the BGP-iSec authors that BGPSec offers "meagre benefits in partial adoption" to me seems a subjective one. Consider when two BGPSec-capable networks interconnect, both parties immediately benefit from having secured that interconnection point. For example, if this happens to be the interconnection between two major cloud providers, the advantages are massive and can positively benefit billions of indirect constituents. Similarly, in the past I've argued that only the biggest networks in the world need to do RPKI-ROV for all of the Internet to take benefit from that deployment action by a single small group. Comparing RPKI-ROV & BGPSec is apples and oranges; but the point stands that in an Internet with increased centralization we have to rethink what exactly the consequences are of so-called 'partial deployments' of security features.

I enjoyed reading the BGP-iSec paper and certainly view and appreciate it as an interesting perspective on the routing security problem space; but I think for very good reasons AS_PATH integrity (BGPsec) and AS_PATH route leaks (OPEN Policy, OTC, ASPA) are addressed as independent technology extensions to the routing stack.

Sometimes, trying to kill two or three birds with one stone inadvertently introduces significant cost in unexpected places, presenting surprising barriers to deployment.

Kind regards,

Job

[0]: https://datatracker.ietf.org/doc/html/rfc7132 [1]: https://www.fcc.gov/ecfs/document/104112834502222/1 [2]: https://sobornost.net/~job/fastly-fcc-noi-secure-internet-routing-reply-comm...

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 <qlc19@mails.tsinghua.edu.cn> 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" <amir.lists@gmail.com> *发送时间:* 2023-11-11 07:02:48 (星期六) *收件人:* NANOG <nanog@nanog.org> *主题:* 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_Securit... -- 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

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 <beecher@beecher.cc> 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 <amir.lists@gmail.com> 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 <qlc19@mails.tsinghua.edu.cn> 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" <amir.lists@gmail.com> *发送时间:* 2023-11-11 07:02:48 (星期六) *收件人:* NANOG <nanog@nanog.org> *主题:* 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_Securit... -- 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