BGP-iSec: Improved Security of Internet Routing Against Post-ROV Attacks

Tue Nov 21 01:03:25 UTC 2023

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 at 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 at 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 at 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 at gmail.com>
>>> *发送时间:* 2023-11-11 07:02:48 (星期六)
>>> *收件人:* NANOG <nanog at 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_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
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20231120/5890a1b1/attachment.html>