Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP

Kumari, Warren

doi:10.17487/rfc6472

“…BGP also allows proxy aggregation, where some other AS can combine routes to adjacent prefixes in some circumstances. It would be possible to support proxy aggregation in the case of identical AS paths, with additional computational cost (but we do not propose to deal with the rare and deprecated attribute [21]). The MTT could include aggregates as well as ordinary prefixes.…”

Section: Discussionmentioning

confidence: 99%

Private and Verifiable Interdomain Routing Decisions

Zhao

¹

,

Zhou

²

,

Gurney

³

et al. 2016

IEEE/ACM Trans. Networking

View full text Add to dashboard Cite

Existing secure interdomain routing protocols can verify validity properties about individual routes, such as whether they correspond to a real network path. It is often useful to verify more complex properties relating to the route decision procedure -for example, whether the chosen route was the best one available, or whether it was consistent with the network's peering agreements. However, this is difficult to do without knowing a network's routing policy and full routing state, which are not normally disclosed.In this paper, we show how a network can allow its peers to verify a number of nontrivial properties of its interdomain routing decisions without revealing any additional information. If all the properties hold, the peers learn nothing beyond what the interdomain routing protocol already reveals; if a property does not hold, at least one peer can detect this and prove the violation. We present SPIDeR, a practical system that applies this approach to the Border Gateway Protocol, and we report results from an experimental evaluation to demonstrate that SPIDeR has a reasonable overhead.

show abstract

“…BGP also allows proxy aggregation, where some other AS can combine routes to adjacent prefixes in some circumstances. It would be possible to support proxy aggregation in the case of identical AS paths, with additional computational cost (but we do not propose to deal with the rare and deprecated AS_SET attribute [18]). The MTT could include aggregates as well as ordinary prefixes.…”

Section: Discussionmentioning

confidence: 99%

Private and verifiable interdomain routing decisions

Zhao

¹

,

Zhou

²

,

Gurney

³

et al. 2012

SIGCOMM Comput. Commun. Rev.

View full text Add to dashboard Cite

Existing secure interdomain routing protocols can verify validity properties about individual routes, such as whether they correspond to a real network path. It is often useful to verify more complex properties relating to the route decision procedure -for example, whether the chosen route was the best one available, or whether it was consistent with the network's peering agreements. However, this is difficult to do without knowing a network's routing policy and full routing state, which are not normally disclosed.In this paper, we show how a network can allow its peers to verify a number of nontrivial properties of its interdomain routing decisions without revealing any additional information. If all the properties hold, the peers learn nothing beyond what the interdomain routing protocol already reveals; if a property does not hold, at least one peer can detect this and prove the violation. We present SPIDeR, a practical system that applies this approach to the Border Gateway Protocol, and we report results from an experimental evaluation to demonstrate that SPIDeR has a reasonable overhead.

show abstract

“…For each IP address of a domain name, we extract all covering prefixes and derive the origin AS from the AS path (i.e., the right most ASN in the AS path). Note that entries with an AS_SET are excluded from our study as this leads to an ambiguity of the attribute, which is why the function is deprecated with the deployment of RPKI [16].…”

Section: Preliminary Methodologymentioning

confidence: 99%

RiPKI

Wählisch

¹

,

Schmidt

²

,

Schmidt

³

et al. 2015

Proceedings of the 14th ACM Workshop on Hot Topics in Networks

View full text Add to dashboard Cite

Web content delivery is one of the most important services on the Internet. Access to websites is typically secured via TLS. However, this security model does not account for prefix hijacking on the network layer, which may lead to traffic blackholing or transparent interception. Thus, to achieve comprehensive security and service availability, additional protective mechanisms are necessary such as the RPKI, a recently deployed Resource Public Key Infrastructure to prevent hijacking of traffic by networks. This paper argues two positions. First, that modern web hosting practices make route protection challenging due to the propensity to spread servers across many different networks, often with unpredictable client redirection strategies; and, second, that we need a better understanding why protection mechanisms are not deployed. To initiate this, we empirically explore the relationship between web hosting infrastructure and RPKI deployment. Perversely, we find that less popular websites are more likely to be secured than the prominent sites. Worryingly, we find many large-scale CDNs do not support RPKI, thus making their customers vulnerable. This leads us to explore business reasons why operators are hesitant to deploy RPKI, which may help to guide future research on improving Internet security.

show abstract

Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP

Cited by 10 publications

References 1 publication

Private and Verifiable Interdomain Routing Decisions

Private and Verifiable Interdomain Routing Decisions

Private and verifiable interdomain routing decisions

RiPKI

Contact Info

Product

Resources

About