Rough Guide to IETF 95: Internet Infrastructure Resilience

This post has been seen 222 times.

This issue of the ISOC Rough Guide to IETF 95 includes not only issues related to the control plane (routing), but also to the data forwarding plane – specifically DDoS attacks. There is interesting and important work underway at IETF 95 in Buenos Aires next week that can help addressing problems in both areas.

The Secure Inter-Domain Routing (SIDR, http://datatracker.ietf.org/wg/sidr/) WG is focusing on securing inter-domain routing. The overall architecture is based on a Resource PKI (RPKI), which adds an authentication framework to BGP and is an important component of BGP security extensions – BGPSEC, also developed in SIDR WG. This is a key technology for improving trust in the global routing infrastructure.

If you look at the agenda, quite a few new proposals are brought to the table and will be discussed in Buenos Aires. Remarkably, most of them are related to the RPKI and Origin Validation, its operational and deployment aspects, which is a good indicator of the maturing process of this technology.

For quite some time the RIR engineers operating apexes of the RPKI hierarchy have been raising concerns about fragility of the system to potential mistakes of “over-claiming.” This is a case when a subordinate certificate “over-claims” resources compared to its parent, which leads to invalidation of the whole branch beneath. The closer to the top of the RPKI hierarchy such mistakes happen, the bigger the impact – some ISPs can lose their routing completely (assuming other folks validate, of course). And the probability of such mistakes is unfortunately non-zero, especially taking into account the inter-RIR address transfers.

A proposal “RPKI Validation Reconsidered” ( http://tools.ietf.org/html/draft-ietf-sidr-rpki-validation-reconsidered) tried to address this issue, but proposed quite fundamental changes to the PKI validation process that raised strong opposition in SIDR.

A new draft “RPKI Multiple ‘All Resources’ Trust Anchors Applicability Statement” (https://tools.ietf.org/html/draft-rir-rpki-allres-ta-app-statement-00) attempts to address this problem, but from a different angle. It suggests that each RIR will move from a Trust Anchor that reflects their current holdings to one that reflects all holdings (e.g. 0/0) so that over-claiming can not occur at an RIR level when dealing with transfers from one RIR to another. Interesting solution – I am sure it will generate some discussion at the microphone!

In order to use information published in RPKI repositories, Relying Parties (RP) need to retrieve and validate the content of certificates, CRLs, and other RPKI signed objects. To validate a particular object, one must ensure that all certificates in the certificate chain up to the Trust Anchor (TA) are valid. Therefore, the validation of a certificate tree is usually performed top-down, starting from the TA certificate and descending down the certificate
chain, validating every encountered certificate and its products.

A draft “RPKI Certificate Tree Validation by a Relying Party Tool (https://tools.ietf.org/html/draft-ietf-sidr-rpki-tree-validation-00) describes how a Relying Party tool could discover RPKI objects to download, build certificate path, and validate RPKI objects, independently from what repository access protocol is used. The draft documents the process used by the RIPE NCC RPKI Validator implementation, but if there is interest it may be a good starting point of a generic validation document. I think that work can lead to more coherent and robust implementations of the validators.

A draft “Signaling RPKI Validation Results from a Route-Server to Peers”
( https://tools.ietf.org/html/draft-kklf-sidr-route-server-rpki-light-00) proposes how RPKI can be effectively used in an IXP environment, enhancing the functionality of a route server.

This all indicates to me that practical RPKI is getting more momentum.

We talked before about a so-called “route-leak.” Simply speaking, this term describes an otherwise valid announcement that nevertheless violated the intended propagation scope. For example, a multi-homed customer “leaks” an announcement from one upstream provider to another one. Because it is a policy violation, neither OV nor BGPSEC can detect or mitigate such “attack.” Seems like a significant “hole” that needs to be fixed.

Comments

comments

You might also like More from author

Show Buttons
Hide Buttons