Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243

Snijders, Job

doi:10.17487/rfc8093

Cited by 4 publications

(4 citation statements)

References 1 publication

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The number identifying this attribute is configurable in our implementation. Our tests running DISCO ( §VII) use the 0xFF attribute which is reserved for experimental use to avoid interference with another standardized or squatted attribute types (see [56], [55]) during experiments. We acknowledge the need for standardizing the use of this BGP attribute type before DISCO can be widely adopted.…”

Section: Methodsmentioning

confidence: 99%

“…Routers need not understand these (optional) attributes but are still expected to forward them onwards to other networks (transitive); hence they provide a useful mechanism for extending BGP [48]. In practice, however, BGP implementations might violate the protocol's specification and filter unknown optional transitive attributes (as indeed happened during the standardization of BGP large communities [55]). We describe below how we evaluate the propagation of DISCO's new public key BGP attribute and provide evidence that such a new BGP attribute would reliably propagate to the global Internet.…”

Section: A Compatibility With Today's Internetmentioning

confidence: 99%

See 1 more Smart Citation

DISCO: Sidestepping RPKI's Deployment Barriers

Hlaváček

Cunha

Gilad

et al. 2020

Proceedings 2020 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

BGP is a gaping security hole in today's Internet, as evidenced by numerous Internet outages and blackouts, repeated traffic hijacking, and surveillance incidents. To protect against prefix hijacking, the Resource Public Key Infrastructure (RPKI) has been standardized. Yet, despite Herculean efforts, ubiquitous deployment of the RPKI remains distant, due to RPKI's manual and error-prone certification process. We argue that deploying origin authentication at scale requires substituting the standard requirement of certifying legal ownership of IP address blocks with the goal of certifying de facto ownership. We show that settling for de facto ownership is sufficient for protecting against hazardous prefix hijacking and can be accomplished without requiring any changes to today's routing infrastructure. We present DISCO, a readily deployable system that automatically certifies de facto ownership and generates the appropriate BGPpath-filtering rules at routers. We evaluate DISCO's security and deployability via live experiments on the Internet using a prototype implementation of DISCO and through simulations on empirically-derived datasets. To facilitate the reproducibility of our results, we open source our prototype, simulator, and measurement analysis code [30]. We present Decentralized Infrastructure for Securing and Certifying Origins. DISCO automatically certifies de facto

show abstract

Section: Methodsmentioning

confidence: 99%

Section: A Compatibility With Today's Internetmentioning

confidence: 99%

DISCO: Sidestepping RPKI's Deployment Barriers

Hlaváček

Cunha

Gilad

et al. 2020

Proceedings 2020 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

show abstract

“…We confirm that Tier-1 ASes typically cannot be poisoned (Section 8.6.3.1). We also see that filters designed to prevent route leaks [255] also interfere with poisoning.…”

Section: Effects Of Choice Of Anycast Sitesmentioning

confidence: 83%

“…We find that many ISPs, especially Tier-1 ASes, filter out AS paths that poison any Tier-1 AS. Tier-1 ASes deploy these filters to block BGP announcements from customers that contain other Tier-1 ASes in the path to prevent route leaks [255,184]. This filtering often makes path poisoning ineffective to control traffic.…”

Section: Poisoning Coveragementioning

confidence: 99%

Anycast in the Age of Hypergiants : Towards Tools and Techniques for the other 99% of ASes

Bertholdo¹

View full text Add to dashboard Cite

ISPs, DNS-operators en operators van nationale onderzoeksnetwerken over de toenemende centralisatie van DNS-resolvers. Deze discussies leidden ons ertoe om een gefedereerd model voor anycast-netwerken tussen ISPs en DNS-operators voor te stellen. Daarbij hebben we de belangrijkste eisen aan zo'n gefedereerd model geïdentificeerd en een onderzoeksagenda opgesteld die gericht is op het opbouwen van een anycast-federatie voor DNS-resolvers.Door deze bijdragen bevorderen we de wereldwijde adoptie van anycast. Door de instapkosten verbonden aan infrastructuur te verlagen en het beheer te vereenvoudigen, kunnen er nieuwe aanbieders van anycast-diensten ontstaan. Op termijn zou dit mogelijk de huidige centralisatietrend van DNS kunnen keren.

show abstract