Dear Amir,
On Fri, Nov 10, 2023 at 06:02:48PM -0500, Amir Herzberg wrote:
> We will present our new work, titled: `BGP-iSec: Improved Security of
> Internet Routing Against Post-ROV Attacks', in NDSS'24.
>
> If you're interested in security of Internet routing (BGP), and want a
> copy, see URL below, drop me a message/email - or see us in the
> conference - or just read the final version.
>
> Available from:
> https://www.researchgate.net/publication/375553362_BGP-iSec_Improved_Security_of_Internet_Routing_Against_Post-ROV_Attacks
Thanks for freely sharing a copy! This allowed me to jot down some
initial thoughts.
* It appears that BGP-iSec requires a deployment flag day per Autonomous
System, rather than doing security upgrades "one EBGP session at a
time" (a deployment model both RPKI-ROV and BGPsec support).
This lack of "per EBGP session"-granularity doesn't make for a
feasible or viable deployment story in the global Internet routing
system - as quite some Autonomous Systems are composed of thousands of
routers which cannot be made to do the same thing at the same moment
for logistical and various other reasons. What BGP-iSec promotes as a
'feature' ("Mandatory Signatures for Announcement Integrity") - may
turn out to be its biggest impediment towards deployment in the real
world.
* As noted in RFC 7132 [0], Google's [1], Fastly's [2] response to
the FCC "inquiry into internet routing vulnerabilities" which your
paper cites; BGPsec was consciously not designed to address route
leaks, as leaks are not precluded by the specification for BGP and
might be the result of a local policy that is not publicly disclosed.
To me the sentence "Even under full adoption, BGPsec does not prevent
route leaks" reads contentious, because of an implicit assertion that
BGPsec was intended to address route leaks.
To me the above reads as "Even under full adoption of IPv6, world
hunger will not be achieved". E.g. seems a false equivalence is drawn.
* It appears BGP-iSec took some inspiration from ASPA, but instead of
signalling the list of providers out-of-band (which ASPA does via the
RPKI publication system); BGP-iSec proposed an in-band signal in the
form of 'UP' messages encapsulated inside BGP Path Attributes. Again,
this suggests that BGP-iSec requires a flag day for all EBGP routers
in a given Autonomous System; whereas deployment of the ASPA signal
happens via a singular place (the RIR RPKI web portal), and in order
to publish an ASPA object, no changes have to be executed on the
Autonomous System's EBGP routers.
* The bold assertion made by the BGP-iSec authors that BGPSec offers
"meagre benefits in partial adoption" to me seems a subjective one.
Consider when two BGPSec-capable networks interconnect, both parties
immediately benefit from having secured that interconnection point.
For example, if this happens to be the interconnection between two
major cloud providers, the advantages are massive and can positively
benefit billions of indirect constituents. Similarly, in the past I've
argued that only the biggest networks in the world need to do RPKI-ROV
for all of the Internet to take benefit from that deployment action by
a single small group. Comparing RPKI-ROV & BGPSec is apples and
oranges; but the point stands that in an Internet with increased
centralization we have to rethink what exactly the consequences are of
so-called 'partial deployments' of security features.
I enjoyed reading the BGP-iSec paper and certainly view and appreciate
it as an interesting perspective on the routing security problem space;
but I think for very good reasons AS_PATH integrity (BGPsec) and AS_PATH
route leaks (OPEN Policy, OTC, ASPA) are addressed as independent
technology extensions to the routing stack.
Sometimes, trying to kill two or three birds with one stone
inadvertently introduces significant cost in unexpected places,
presenting surprising barriers to deployment.
Kind regards,
Job
[0]: https://datatracker.ietf.org/doc/html/rfc7132
[1]: https://www.fcc.gov/ecfs/document/104112834502222/1
[2]:
https://sobornost.net/~job/fastly-fcc-noi-secure-internet-routing-reply-comments-20220510-201259363-pdf.pdf
